Live data from Hacker News

Chisel: A Modern Hardware Design Language

github.com

31–40 of 78 posts

Re: Chisel: A Modern Hardware Design Language

#31
post #18

Earlier quoted context omitted.

Have you looked at/used Bluespec SystemVerilog? If so, any comments based on your experience? https://github.com/B-Lang-org/bsc

Yes, I actually built two CPUs in it (one a derivative of the other) for my PhD over a decade ago. That experience helped shape my view on new HDLs. As a specific example Bluespec has this system of rules that define hardware behaviour. From a high level it's a very nice system describing the behaviour you want and the constraints and the compiler works out the details. In practice you have to think about the details…

Thanks; just the kind of response I was hoping for! Is the problem an inability to express real world design constraints in a high level HDL?

Re: Chisel: A Modern Hardware Design Language

#32
post #16
post #7

I've played with this and while I much prefer it to verilog (and even migen) it is still too implicit for me. Most of my time spent building VGA toy was wasted debugging wrong counter wrapping and similar. I would like to try out something where the register width and operation semantics (wrap, extend, saturate) have to be always explicit. Maybe it would turn out to be too annoying?

> I would like to try out something where the register width and operation semantics (wrap, extend, saturate) have to be always explicit. Try VHDL. It’s Ada heritage gives it that explicit feel.

I come from a VHDL background and I think this is why Chisel always looked weird to me.

Re: Chisel: A Modern Hardware Design Language

#33

I've said as much before but I find the issue with alternative HDLs Vs SystemVerilog is they concentrate on fixing annoying and frustrating things but don't address the really hard issues in hardware design and can actually make them harder. For example SystemVerilog has no real typing which sucks, so a typical thing to do is to build a massively improved type system for a new HDL. However in my experience good use o…

Disclaimer: I work on Chisel and CIRCT, and these opinions are my own. These are good points, and I think Chisel is actually improving in these areas recently. Chisel is now built on top of the CIRCT[1] compiler infrastructure, which uses MLIR[2] and allows capturing much more information than just RTL in the intermediate representations of the design. This has several benefits. Regarding the problem of converting fr…

Thank you for this write up.

Re: Chisel: A Modern Hardware Design Language

#34

I've said as much before but I find the issue with alternative HDLs Vs SystemVerilog is they concentrate on fixing annoying and frustrating things but don't address the really hard issues in hardware design and can actually make them harder. For example SystemVerilog has no real typing which sucks, so a typical thing to do is to build a massively improved type system for a new HDL. However in my experience good use o…

> For example SystemVerilog has no real typing which sucks, so a typical thing to do is to build a massively improved type system for a new HDL. However in my experience good use of verilog style guides and decent linting tools solves most of the problem

This is why I prefer VHDL. It's strongly typed. I worked at an EDA company on an HLS tool that generated HDL (Verilog, VHDL and SystemC). Customers would report linting problems with the generated Verilog. Since backend code generation was what I worked on I got to fix them. We had almost 0 problems with the generated VHDL mostly due to strong typing. But lots of issues with the generated Verilog that needed fixing.

> Another typical improvement you'll find in an alternative HDL is vastly improved parameterization and generics

Another area where VHDL was already there. SystemVerilog makes some improvements over Verilog.

Re: Chisel: A Modern Hardware Design Language

#35
post #3

Everytime I look at the examples, coming from a verilog background, it's strange to see the clock and reset are all implicit rather than explicit. The blinking led for example, while readable the link between the generated verilog with clock and reset is not clear. How are multi clock domains and Async CDCs handled? I've never used chisel so maybe this all is well managed, but not being explicit about the clock domai…

There's potentially a steep learning for Chisel especially if you're not coming from a Computer Science or programming language theory background.

It feels like Chisel is the result of functional programmers looking at the state of hardware design languages and being aghast at how archaic it is. Which is probably true but the value here will be helping experienced designers with no interest in learning CS theory build better chips faster. If Chisel can do that then it will win.

In my opinion the best languages have an extremely low barrier to entry. For example, C is very simple. The JavaScript development environment and tons of examples are readily available to everyone with a web browser. Python is cross-platform, has libraries for almost anything and relatively painless interoperability.

Re: Chisel: A Modern Hardware Design Language

#36
It's been like 20 years since I did anything with an FPGA, but back then you basically had to use whatever tools your vendor provided you with. Have things improved to the point where an open-source HDL is usable with a large fraction of the FPGAs available?

Re: Chisel: A Modern Hardware Design Language

#37
post #31

Earlier quoted context omitted.

Yes, I actually built two CPUs in it (one a derivative of the other) for my PhD over a decade ago. That experience helped shape my view on new HDLs. As a specific example Bluespec has this system of rules that define hardware behaviour. From a high level it's a very nice system describing the behaviour you want and the constraints and the compiler works out the details. In practice you have to think about the details…

Thanks; just the kind of response I was hoping for! Is the problem an inability to express real world design constraints in a high level HDL?

I think the inherent problem is abstraction just doesn't work in the same way as it does in software. Various things keep pulling you down to the circuit level so if you're too far above it you're going to have a hard time as you have to reason through all those abstractions you built to avoid thinking about it.

Closing timing (getting your design to pass timing analysis at a desired frequency) is a great example. Physical details like how many gates are on some path between flops, how far apart those flops are and how big the gates are (bigger gate, bigger drive, faster transitions) and what else is connected to them (more fan out more capacitance to drive, slower transitions) matter and in standard synchronous design this is pervasive across everything you do. Abstract too far from those details and closing timing becomes a nightmare.

Imagine you wrote some standard data structure in the language of your choice. Now imagine the more call sites you have for the methods that manipulate it the slower it goes everywhere every single time you call it. Imagine some tiny edge case buried deep in the logic calling it occasionally could massively slow down accesses every time from everywhere. How would that change the way you build abstractions?

Re: Chisel: A Modern Hardware Design Language

#38

I've said as much before but I find the issue with alternative HDLs Vs SystemVerilog is they concentrate on fixing annoying and frustrating things but don't address the really hard issues in hardware design and can actually make them harder. For example SystemVerilog has no real typing which sucks, so a typical thing to do is to build a massively improved type system for a new HDL. However in my experience good use o…

> For example SystemVerilog has no real typing which sucks, so a typical thing to do is to build a massively improved type system for a new HDL. However in my experience good use of verilog style guides and decent linting tools solves most of the problem This is why I prefer VHDL. It's strongly typed. I worked at an EDA company on an HLS tool that generated HDL (Verilog, VHDL and SystemC). Customers would report lint…

Yeah I should really get around to learning VHDL!

Re: Chisel: A Modern Hardware Design Language

#39
post #36

It's been like 20 years since I did anything with an FPGA, but back then you basically had to use whatever tools your vendor provided you with. Have things improved to the point where an open-source HDL is usable with a large fraction of the FPGAs available?

Mostly you still have to use their tools, Chisel just compiles to Verilog and then you use their tools for the rest of the process.

There are open source tools based on reverse engineering the bitstream for some smaller FPGAs like the Lattice family, some preliminary work on Xilinx, and one vendor actually supporting the open source toolchain (QuickLogic), but for anything serious on the major FPGA platforms, you still need to use the vendor toolchain.

Re: Chisel: A Modern Hardware Design Language

#40
post #21

One thing I really like about Verilog is explicit register widths. I want to be able to work at the individual bit level, something that Python (and even C) are not very good at. Is Chisel decent for efficiency?

C is excellent at bit-banging, miles better than Python.

Depends on what you mean by excellent. It sucks by definition since it doesn't have generics. It's efficient though which in some sense makes it excellent.
Post reply on HN