8 ms·

Chisel: A Modern Hardware Design Language

156 points by nairboon 3y ago

cmrx64 3y ago
I much prefer SpinalHDL, having used both.
- le-mark 3y ago
  This comment would have more value if the kind poster could provide some pros and cons.
  - cmrx64 3y ago
    After having evaluated the current state of Chisel 3, it seems most of the hard technical reasons to use Spinal have evaporated. However, when I was experimenting with both of them, Spinal's interface for simulation / testing was easier to use, and there were more metaprogramming features available. It may just be a matter of taste now!
- ux01 3y ago
  Are you active in the SpinalHDL community? Reason for asking is this page: https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/Foreword/index.html https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/F... has an example that says for VHDL you need to write three separate processes. FWIW, that's not true, you can write it as one: process (clk, rst, cond) begin if rising_edge(clk) then if cond = '1' then my_reg <= my_reg + 1; my_reg_with_rst <= my_reg_with_rst + 1; end if; end if; if rst = '1' then my_reg_with_rst <= x"0"; end if; my_signal <= cond; end process; Also note that isn't a VHDL thing but a synthesis thing. But I think you'll be hard pushed to find a synthesiser that won't synthesise the above code correctly. Quartus, Vivado, Diamond, Libero, and ISE will all synthesise it correctly. I expect most of those tools will also accept process (all) as well, instead of having to write out the sensitivity list explicitly.
  - ux01 3y ago
    Ah ok, copying and pasting code into the comment box doesn't retain code formatting ...
    - ur-whale 3y ago
      Yeah, this is one of the most heinous feature of HN's comment box.
  - Dolu 3y ago
    > FWIW, that's not true, you can write it as one: While technicaly you are right, i think you missed the spirit of what the doc was saying. You may write it all in a single process, but you will always have duplicated code blocks, especialy if those 3 types of hardware (ff,ff with reset, comb) share assignements with the same condition.
tails4e 3y ago
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 domain seems strange
- cmrx64 3y ago
  Their docs explain it. It’s sorta like “implicit this”. https://www.chisel-lang.org/docs/explanations/multi-clock https://www.chisel-lang.org/docs/explanations/multi-clock
  - tails4e 3y ago
    Thanks, so a single clock and reset is implicit, but clock2 (or more) is explicit.
    - seldridge 3y ago
      Yes. There's two common types of modules with different behavior here: `Module` and `RawModule`. The former has implicit clock and reset ports. The latter has no implicit clock and reset. All design can be done with the latter, just a bit more verbosely---all clock and reset ports need to be defined and anytime a construct that needs a clock or reset is used (e.g., a register), it would need to be wrapped in a `withClock`/`withReset`/`withClockAndReset`.
- chrsw 3y ago
  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.
tmitchel2 3y ago
I wish there was one in typescript, I just can't get on with python.
- woadwarrior01 3y ago
  Chisel is based on Scala, not Python.
- snitty 3y ago
  nmigen is a python based HDL.
- progbits 3y ago
  I figured this must exist and indeed: https://github.com/gateware-ts/gateware-ts https://github.com/gateware-ts/gateware-ts
- dilawar 3y ago
  myhdl is python based but I don't think it's been developed anymore.
progbits 3y ago
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?
- irdc 3y ago
  > 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.
  - OhMeadhbh 3y ago
    I come from a VHDL background and I think this is why Chisel always looked weird to me.
programjames 3y ago
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?
- glitchc 3y ago
  C is excellent at bit-banging, miles better than Python.
  - retrac 3y ago
    C is able to express efficient code for bit-banging. But it's still ugly and hard to use. Ada handles it better than any language I've seen. Types are abstract but can be given concrete realizations. A number can be defined as, for example, the range of 0 to 31. And optionally the compiler could be told to store that in bits 20 to 25 of a 32-bit word. Or non-consecutively, or out of order, or across multiple words. Just about any kind of bit reordering and packing is supported. With overflow checking and so on, too. Take away idea is you should never be using shift and and/or bitwise operations. The compiler should translate (and also check that it fits and doesn't overlap) into the low level binary representation behind the scenes for you.
  - rowanG077 3y ago
    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.
  - IshKebab 3y ago
    Actually for that Python is better than C due to its support for arbitrary precision integers. One of the few things Python got really right. It's way slower of course.
gchadwick 3y ago
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 of verilog style guides and decent linting tools solves most of the problem. You do still get bugs caused by missed typing issues but they're usually quickly caught by simple tests. It's certainly annoying to have to deal with all of this but fundamentally if it's all made easier it's not significantly improving your development time or final design quality. Another typical improvement you'll find in an alternative HDL is vastly improved parameterization and generics. Again this is great to have but mostly makes tedious and annoying tasks simpler but doesn't produce major impact. The reason for this is writing good HDL that works across a huge parameterisation space is very hard. You have to verify every part of the parameter space you're using and you need to ensure you get good power/performance/area results out of it too. To do this can require very different micro architectural decisions (e.g. single, dual and triple issue CPUs will all need to be built differently improved parameterization doesn't save you from this). Ultimately you often only want to use a small portion of the parameter space anyway so just doing it in system verilog possibly with some auto generated code using python works well enough even if it's tedious. So if the practical benefits turn out to be minor why not take all the nice quality of life improvements anyway? There's a large impact on the hard things. From a strictly design perspective these are things like clock domain crossing, power, area and frequency optimization. Here you generally need a good understanding of what the actual circuit is doing and to be able to connect tool output (e.g. the gates your synthesis tool has produced) and your HDL. Here the typical flow of HDL -> SystemVerilog -> tool output can become a big problem. The HDL to SystemVerilog step can produce very hard to read code that's hard to connect to your input HDL. This adds a new and tricky mental step when you're working with the design, first understand the circuit issue then map that to the hard to read SystemVerilog then map that to your HDL and work out what you need to change. Outside of design alone a major cost of building silicon is verification. Alternative HDLs generally don't address this at all and again can make it harder. Either you entirely simulate the HDL itself which can be fine but then you're banking on minimal bugs in that simulator and there's no bugs in the HDL -> SystemVerilog step. Alternatively you simulate the SystemVerilog directly with an existing simulator but then you've got the HDL to SystemVerilog mapping problem all over again. I think my ideal HDL at this point is a stripped down SystemVerilog with a good type system, better generative capability that crucially produces plain system verilog that's human readable (maintaining comments, signal and module names and module hierarchy as much as possible).
donatj 3y ago
Not being a hardware person, when I heard “Hardware Design Language” I was thinking more along the lines of Snow White[1] - the idea of an open source industrial design language would be pretty interesting, something along the lines of Material UI but for hardware. 1. https://en.wikipedia.org/wiki/Snow_White_design_language https://en.wikipedia.org/wiki/Snow_White_design_language
- bee_rider 3y ago
  That’s interesting! HDL’s are older than dirt and the term is pretty well embedded in the computer engineering field at this point, but it is a funny near-collision.
- nkotov 3y ago
  Are there other ones similar to this? For example, I really loved the 80s/90s Sony style.
ur-whale 3y ago
The goal is worthy, the effort is commendable, but the underlying language (Scala) is an absolute turn-off AFAIC, and I suspect I'm far from being the only one.
modulovalue 3y ago
There's a similar project at Intel: https://github.com/intel/rohd https://github.com/intel/rohd It uses Dart instead of Scala.
- mrmax99 3y ago
  Hey, I'm the lead for that! I think it addresses a lot of the problems raised in these comments about Chisel and other generator frameworks. Happy to answer questions! https://intel.github.io/rohd-website/ https://intel.github.io/rohd-website/
irdc 3y ago
I don’t understand how this improves upon VHDL, even after reading their own explanation[0]. Just why they think object orientation makes hardware design easier isn’t really explained. After a quick look at it I much prefer VHDL’s entities (though their syntax is rather too wordy for my tastes), which at least make the direction of signals clearer. The problem with libraries could have been easily solved by extending/fixing VHDL instead of going through all this effort. 0. https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages https://stackoverflow.com/questions/53007782/what-benefits-d...
- ux01 3y ago
  Doesn't VHDL have good support for libraries? VHDL packages and subfunctions can have generics (which I've not used) for library support similar to Ada. VHDL entities can also have generics (which I have used). I was wondering what was lacking and needs extending/fixing in VHDL.
- mrmax99 3y ago
  Hardware generator frameworks allow you to use a full-powered modern software language to control generation of hardware. Think about why it may be easier to implement something in Python than C. Adding capabilities to VHDL/SystemVerilog is very difficult since many vendors and tools have to implement it, and if any of them don't support it the whole feature can't be used.
physPop 3y ago
Anyone have experience that can compare this with Clash?
aidenn0 3y ago
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?
- lambda 3y ago
  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.
  - Brian_K_White 3y ago
    Thanks for the heads up about QuickLogic. hdn't heard of them yet.
BooneJS 3y ago
These languages are fun. "Look ma, no verilog!" But the underlying problem with all of these DSLs is the fact that the EDA[0] industry interoperates on verilog. Period. Worse, at some point in the design cycle, post-synthesized gate-level verilog becomes the codebase. No upstream verilog changes are allowed because it can be difficult to get a precise edit (e.g. 2-input NAND into a 2-input AOI by changing a verilog function) and you just don't have 3 weeks of runtime to go from verilog to GDSII again. Or you want to make a metal-only respin that only changes one $0.xM mask layer and requires 8 weeks of fab time instead of changing multiple metal layers including the base and needs 16 weeks and a $xM payment. Programming language design is quite rich because they used to cross-compile to C, and now they generally generate LLVM IR. It doesn't matter what the bug is in the final binary; you're not going to hex edit the binary like you would with a single metal layer of a 300mm wafer. You're just going to recompile and it generally doesn't matter if one machine instruction changes or 1M do because unlike verilog, not even GHC needs 3w to compile a program. source: I've been on chip design teams for 2 decades and finally gave up on fighting verilog. [0]: Electronic Design Automation. Synopsys, Cadence, Siemens, Ansys, etc.
- phkahler 3y ago
  Your stance seems well founded and very compelling. As an outsider to chip design ima play devils advocate and ask, what if the higher level tools reduce overall design time and eliminate a lot of those errors you end up patching in the metal layers? I fought the same battle with auto-generated C from simulink models, and really don't think that's the way to do much for production. But thats because the tool isn't good enough for general software development (can't write hello world for example) not because I worry about patching generated code.
  - sweden 3y ago
    The OP makes an interesting point but it doesn't point out the main problem with high level hardware languages: these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality. The problem is that you will end up with a hardware that is less optimized than if you were to design it in Verilog. I work at a very big semiconductor company and we did some trials with implementing the exact same hardware we had in Verilog but on an high level HDL and while development could be faster, we ended up with worse PPA (Power, Performance and Area). If you try to improve this PPA, you just end up bypassing the advantages of high level HDLs. On top of that, it raises a lot of questions on verification: are you going to do verification (testbenches) in the Chisel code or in the generated Verilog code from Chisel? If you do it in Chisel, how do you prove that Chisel didn't introduce bugs in the generated Verilog code (which is what you will end up shipping to the foundry for tape out after synthesis and place & route)? If you do it in the generated Verilog code, how do you trace the bugs back to the Chisel code? I do think that we need a new language but not for design. Verilog/System Verilog is fine for hardware design, we don't need to reinvent the wheel here. We will always end up in Verilog in our synthesis and quite frankly, we don't spend that much time writing Verilog for hardware design. Hardware design is 5 lines of code and that's it. The real cost of hardware development is the other side of the coin, which is hardware verification. If hardware design is 5 lines of code, hardware verification is 500 lines. Writing testbenches and developing hardware verification environments and flows is essentially normal programming and we are stuck in System Verilog for that, which is a very bad programming language. Using System Verilog as a programming language is so prone to unintended bugs in your testbenches and bad programming constructs. This is what we should try to improve, verification not design. We spend far too much time in hardware verification and a lot of that time is spent dealing with pitfalls from System Verilog as a programming language. I wish people would be investing more thinking here rather than trying to make hardware design friendlier for programmers.
codedokode 3y ago
I tried to use Verilog for a DIY project and found no way to control Verilog model from Python. Why is it like this? Do people really write tests directly in this awful outdated language instead of using Python? I tried to use cocotb, but this is not what I want. It runs verilog interpreter and launches Python script from it, but I want the other way: I want to create a verilog model instance and access it in Python. Also, I found that Verilog seems to have no built-in feature for modeling real delays. Let's say we have a gate, and when input signal changes, output should instantly go to "undefined" (x) state and only after a delay switch to a valid 0 or 1 value. It seems that verilog has no such type of realistic delay built-in. I found only "transport delay" and "elastic delay", both unrealistic. I had to create my own "delay gate" to simulate this (and made lot of mistakes doing this).
klysm 3y ago
Has anybody made this for factorio
throw10920 3y ago
I tried to use Chisel a few years ago, and gave up quickly because of the absolutely abysmal tooling. sbt is a nightmare.
dilawar 3y ago
Nice. BlueSpec (Haskell based) was open sourced few years ago. I wonder how it compares with BlueSpec.

156 points by nairboon 3y ago

cmrx64 3y ago

I much prefer SpinalHDL, having used both.

le-mark 3y ago
This comment would have more value if the kind poster could provide some pros and cons.
- cmrx64 3y ago
  After having evaluated the current state of Chisel 3, it seems most of the hard technical reasons to use Spinal have evaporated. However, when I was experimenting with both of them, Spinal's interface for simulation / testing was easier to use, and there were more metaprogramming features available. It may just be a matter of taste now!
ux01 3y ago
Are you active in the SpinalHDL community? Reason for asking is this page: https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/Foreword/index.html https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/F... has an example that says for VHDL you need to write three separate processes. FWIW, that's not true, you can write it as one: process (clk, rst, cond) begin if rising_edge(clk) then if cond = '1' then my_reg <= my_reg + 1; my_reg_with_rst <= my_reg_with_rst + 1; end if; end if; if rst = '1' then my_reg_with_rst <= x"0"; end if; my_signal <= cond; end process; Also note that isn't a VHDL thing but a synthesis thing. But I think you'll be hard pushed to find a synthesiser that won't synthesise the above code correctly. Quartus, Vivado, Diamond, Libero, and ISE will all synthesise it correctly. I expect most of those tools will also accept process (all) as well, instead of having to write out the sensitivity list explicitly.
- ux01 3y ago
  Ah ok, copying and pasting code into the comment box doesn't retain code formatting ...
  - ur-whale 3y ago
    Yeah, this is one of the most heinous feature of HN's comment box.
- Dolu 3y ago
  > FWIW, that's not true, you can write it as one: While technicaly you are right, i think you missed the spirit of what the doc was saying. You may write it all in a single process, but you will always have duplicated code blocks, especialy if those 3 types of hardware (ff,ff with reset, comb) share assignements with the same condition.

tails4e 3y ago

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 domain seems strange

cmrx64 3y ago
Their docs explain it. It’s sorta like “implicit this”. https://www.chisel-lang.org/docs/explanations/multi-clock https://www.chisel-lang.org/docs/explanations/multi-clock
- tails4e 3y ago
  Thanks, so a single clock and reset is implicit, but clock2 (or more) is explicit.
  - seldridge 3y ago
    Yes. There's two common types of modules with different behavior here: `Module` and `RawModule`. The former has implicit clock and reset ports. The latter has no implicit clock and reset. All design can be done with the latter, just a bit more verbosely---all clock and reset ports need to be defined and anytime a construct that needs a clock or reset is used (e.g., a register), it would need to be wrapped in a `withClock`/`withReset`/`withClockAndReset`.
chrsw 3y ago
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.

tmitchel2 3y ago

I wish there was one in typescript, I just can't get on with python.

woadwarrior01 3y ago
Chisel is based on Scala, not Python.
snitty 3y ago
nmigen is a python based HDL.
progbits 3y ago
I figured this must exist and indeed: https://github.com/gateware-ts/gateware-ts https://github.com/gateware-ts/gateware-ts
dilawar 3y ago
myhdl is python based but I don't think it's been developed anymore.

progbits 3y ago

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?

irdc 3y ago
> 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.
- OhMeadhbh 3y ago
  I come from a VHDL background and I think this is why Chisel always looked weird to me.

programjames 3y ago

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?

glitchc 3y ago
C is excellent at bit-banging, miles better than Python.
- retrac 3y ago
  C is able to express efficient code for bit-banging. But it's still ugly and hard to use. Ada handles it better than any language I've seen. Types are abstract but can be given concrete realizations. A number can be defined as, for example, the range of 0 to 31. And optionally the compiler could be told to store that in bits 20 to 25 of a 32-bit word. Or non-consecutively, or out of order, or across multiple words. Just about any kind of bit reordering and packing is supported. With overflow checking and so on, too. Take away idea is you should never be using shift and and/or bitwise operations. The compiler should translate (and also check that it fits and doesn't overlap) into the low level binary representation behind the scenes for you.
- rowanG077 3y ago
  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.
- IshKebab 3y ago
  Actually for that Python is better than C due to its support for arbitrary precision integers. One of the few things Python got really right. It's way slower of course.

gchadwick 3y ago

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 of verilog style guides and decent linting tools solves most of the problem. You do still get bugs caused by missed typing issues but they're usually quickly caught by simple tests. It's certainly annoying to have to deal with all of this but fundamentally if it's all made easier it's not significantly improving your development time or final design quality. Another typical improvement you'll find in an alternative HDL is vastly improved parameterization and generics. Again this is great to have but mostly makes tedious and annoying tasks simpler but doesn't produce major impact. The reason for this is writing good HDL that works across a huge parameterisation space is very hard. You have to verify every part of the parameter space you're using and you need to ensure you get good power/performance/area results out of it too. To do this can require very different micro architectural decisions (e.g. single, dual and triple issue CPUs will all need to be built differently improved parameterization doesn't save you from this). Ultimately you often only want to use a small portion of the parameter space anyway so just doing it in system verilog possibly with some auto generated code using python works well enough even if it's tedious. So if the practical benefits turn out to be minor why not take all the nice quality of life improvements anyway? There's a large impact on the hard things. From a strictly design perspective these are things like clock domain crossing, power, area and frequency optimization. Here you generally need a good understanding of what the actual circuit is doing and to be able to connect tool output (e.g. the gates your synthesis tool has produced) and your HDL. Here the typical flow of HDL -> SystemVerilog -> tool output can become a big problem. The HDL to SystemVerilog step can produce very hard to read code that's hard to connect to your input HDL. This adds a new and tricky mental step when you're working with the design, first understand the circuit issue then map that to the hard to read SystemVerilog then map that to your HDL and work out what you need to change. Outside of design alone a major cost of building silicon is verification. Alternative HDLs generally don't address this at all and again can make it harder. Either you entirely simulate the HDL itself which can be fine but then you're banking on minimal bugs in that simulator and there's no bugs in the HDL -> SystemVerilog step. Alternatively you simulate the SystemVerilog directly with an existing simulator but then you've got the HDL to SystemVerilog mapping problem all over again. I think my ideal HDL at this point is a stripped down SystemVerilog with a good type system, better generative capability that crucially produces plain system verilog that's human readable (maintaining comments, signal and module names and module hierarchy as much as possible).

donatj 3y ago

Not being a hardware person, when I heard “Hardware Design Language” I was thinking more along the lines of Snow White[1] - the idea of an open source industrial design language would be pretty interesting, something along the lines of Material UI but for hardware. 1. https://en.wikipedia.org/wiki/Snow_White_design_language https://en.wikipedia.org/wiki/Snow_White_design_language

bee_rider 3y ago
That’s interesting! HDL’s are older than dirt and the term is pretty well embedded in the computer engineering field at this point, but it is a funny near-collision.
nkotov 3y ago
Are there other ones similar to this? For example, I really loved the 80s/90s Sony style.

ur-whale 3y ago

The goal is worthy, the effort is commendable, but the underlying language (Scala) is an absolute turn-off AFAIC, and I suspect I'm far from being the only one.

modulovalue 3y ago

There's a similar project at Intel: https://github.com/intel/rohd https://github.com/intel/rohd It uses Dart instead of Scala.

mrmax99 3y ago
Hey, I'm the lead for that! I think it addresses a lot of the problems raised in these comments about Chisel and other generator frameworks. Happy to answer questions! https://intel.github.io/rohd-website/ https://intel.github.io/rohd-website/

irdc 3y ago

I don’t understand how this improves upon VHDL, even after reading their own explanation[0]. Just why they think object orientation makes hardware design easier isn’t really explained. After a quick look at it I much prefer VHDL’s entities (though their syntax is rather too wordy for my tastes), which at least make the direction of signals clearer. The problem with libraries could have been easily solved by extending/fixing VHDL instead of going through all this effort. 0. https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages https://stackoverflow.com/questions/53007782/what-benefits-d...

ux01 3y ago
Doesn't VHDL have good support for libraries? VHDL packages and subfunctions can have generics (which I've not used) for library support similar to Ada. VHDL entities can also have generics (which I have used). I was wondering what was lacking and needs extending/fixing in VHDL.
mrmax99 3y ago
Hardware generator frameworks allow you to use a full-powered modern software language to control generation of hardware. Think about why it may be easier to implement something in Python than C. Adding capabilities to VHDL/SystemVerilog is very difficult since many vendors and tools have to implement it, and if any of them don't support it the whole feature can't be used.

physPop 3y ago

Anyone have experience that can compare this with Clash?

aidenn0 3y ago

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?

lambda 3y ago
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.
- Brian_K_White 3y ago
  Thanks for the heads up about QuickLogic. hdn't heard of them yet.

BooneJS 3y ago

These languages are fun. "Look ma, no verilog!" But the underlying problem with all of these DSLs is the fact that the EDA[0] industry interoperates on verilog. Period. Worse, at some point in the design cycle, post-synthesized gate-level verilog becomes the codebase. No upstream verilog changes are allowed because it can be difficult to get a precise edit (e.g. 2-input NAND into a 2-input AOI by changing a verilog function) and you just don't have 3 weeks of runtime to go from verilog to GDSII again. Or you want to make a metal-only respin that only changes one $0.xM mask layer and requires 8 weeks of fab time instead of changing multiple metal layers including the base and needs 16 weeks and a $xM payment. Programming language design is quite rich because they used to cross-compile to C, and now they generally generate LLVM IR. It doesn't matter what the bug is in the final binary; you're not going to hex edit the binary like you would with a single metal layer of a 300mm wafer. You're just going to recompile and it generally doesn't matter if one machine instruction changes or 1M do because unlike verilog, not even GHC needs 3w to compile a program. source: I've been on chip design teams for 2 decades and finally gave up on fighting verilog. [0]: Electronic Design Automation. Synopsys, Cadence, Siemens, Ansys, etc.

phkahler 3y ago
Your stance seems well founded and very compelling. As an outsider to chip design ima play devils advocate and ask, what if the higher level tools reduce overall design time and eliminate a lot of those errors you end up patching in the metal layers? I fought the same battle with auto-generated C from simulink models, and really don't think that's the way to do much for production. But thats because the tool isn't good enough for general software development (can't write hello world for example) not because I worry about patching generated code.
- sweden 3y ago
  The OP makes an interesting point but it doesn't point out the main problem with high level hardware languages: these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality. The problem is that you will end up with a hardware that is less optimized than if you were to design it in Verilog. I work at a very big semiconductor company and we did some trials with implementing the exact same hardware we had in Verilog but on an high level HDL and while development could be faster, we ended up with worse PPA (Power, Performance and Area). If you try to improve this PPA, you just end up bypassing the advantages of high level HDLs. On top of that, it raises a lot of questions on verification: are you going to do verification (testbenches) in the Chisel code or in the generated Verilog code from Chisel? If you do it in Chisel, how do you prove that Chisel didn't introduce bugs in the generated Verilog code (which is what you will end up shipping to the foundry for tape out after synthesis and place & route)? If you do it in the generated Verilog code, how do you trace the bugs back to the Chisel code? I do think that we need a new language but not for design. Verilog/System Verilog is fine for hardware design, we don't need to reinvent the wheel here. We will always end up in Verilog in our synthesis and quite frankly, we don't spend that much time writing Verilog for hardware design. Hardware design is 5 lines of code and that's it. The real cost of hardware development is the other side of the coin, which is hardware verification. If hardware design is 5 lines of code, hardware verification is 500 lines. Writing testbenches and developing hardware verification environments and flows is essentially normal programming and we are stuck in System Verilog for that, which is a very bad programming language. Using System Verilog as a programming language is so prone to unintended bugs in your testbenches and bad programming constructs. This is what we should try to improve, verification not design. We spend far too much time in hardware verification and a lot of that time is spent dealing with pitfalls from System Verilog as a programming language. I wish people would be investing more thinking here rather than trying to make hardware design friendlier for programmers.

codedokode 3y ago

I tried to use Verilog for a DIY project and found no way to control Verilog model from Python. Why is it like this? Do people really write tests directly in this awful outdated language instead of using Python? I tried to use cocotb, but this is not what I want. It runs verilog interpreter and launches Python script from it, but I want the other way: I want to create a verilog model instance and access it in Python. Also, I found that Verilog seems to have no built-in feature for modeling real delays. Let's say we have a gate, and when input signal changes, output should instantly go to "undefined" (x) state and only after a delay switch to a valid 0 or 1 value. It seems that verilog has no such type of realistic delay built-in. I found only "transport delay" and "elastic delay", both unrealistic. I had to create my own "delay gate" to simulate this (and made lot of mistakes doing this).

klysm 3y ago

Has anybody made this for factorio

throw10920 3y ago

I tried to use Chisel a few years ago, and gave up quickly because of the absolutely abysmal tooling. sbt is a nightmare.

dilawar 3y ago

Nice. BlueSpec (Haskell based) was open sourced few years ago. I wonder how it compares with BlueSpec.