Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chisel: A Modern Hardware Design Language

github.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Chisel: A Modern Hardware Design Language

#61

Post by BooneJS »

codedokode wrote: post #57
sweden wrote: post #55

Earlier quoted context omitted.

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…

Cannot one write tests in Python? Python seems much nicer to use language. Sadly, I found no library that would allow to create an instance of verilog model from Python and control it (cocotb doesn't allow this).

I verified verilog using the Vera language back in the day. The largest test benches would take 5s to compile to interpreted bytecode. Verification engineers rarely change the design, so keeping that part compiled is great for productivity. It’s really too bad that monolithic compilation is so dang slow.

Re: Chisel: A Modern Hardware Design Language

#62

Post by tverbeure »

BooneJS wrote: post #45

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 f…

I don't understand your point.

Chisel, SpinalHDL, Clash, Migen, Amaranth, and RTL variants generate synthesizable RTL Verilog in the end. From that point of view, they are compatible with any existing ASIC flow.

The only problematic aspect is that most companies use line and conditional coverage as one of their sign-off criteria. That's hard to do with automatically generated Verilog.

But here's the kicker: HLS-generated Verilog is orders of magnitude worse in terms of readability, and yet most recent ASICs with video codecs are design with HLS and derived from HLS reference implementations. And forget about doing traditional coverage metrics just on that RTL just the same.

If HLS-generated Verilog is fine for an ASIC flow, then alternatives like Chisel and friends are much less problematic.

Re: Chisel: A Modern Hardware Design Language

#67

Post by clhodapp »

sweden wrote: post #55
phkahler wrote: post #48

Earlier quoted context omitted.

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 go…

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…

... 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.

It is a common misconception that Chisel is yet another high level synthesis language with these drawbacks, however it is not. It simply allows you to write your own high level abstractions on top of exact low-level synthesis primitives.

Re: Chisel: A Modern Hardware Design Language

#68

Post by tverbeure »

tails4e wrote: 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…

I've used SpinalHDL extensively for hobby projects, which is a close cousin of Chisel. The way it works there is by defining ClockDomain "areas" that contains logic for a particular clock/reset.

Signals can freely travel between different such areas, but unless you explicitly mark those signals as asynchronous, the Verilog code generator will fail with cross-domain clock violations. It's amazing.

Here's an example of a clock domain crossing APB bridge: https://github.com/tomverbeure/panologic-g2/blob/ulpi/spinal....

The module object takes the 2 domains as instantiation parameters: https://github.com/tomverbeure/panologic-g2/blob/9225b86011a...

Here's the area with the logic that lives in the source APB clock domain: https://github.com/tomverbeure/panologic-g2/blob/9225b86011a...

Here is the destination APB clock domain logic: https://github.com/tomverbeure/panologic-g2/blob/9225b86011a...

And this is the pulse synchronizer between them: https://github.com/tomverbeure/panologic-g2/blob/9225b86011a...

Re: Chisel: A Modern Hardware Design Language

#69

Post by mrmax99 »

sweden wrote: post #55
phkahler wrote: post #48

Earlier quoted context omitted.

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 go…

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…

You may find ROHD to be interesting, since it takes a very serious approach to verification and even has a simulator built-in! https://intel.github.io/rohd-website/

Re: Chisel: A Modern Hardware Design Language

#70

Post by mrmax99 »

tails4e wrote: 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…

ROHD (https://intel.github.io/rohd-website/) is sort of similar to Chisel on the design side (Dart instead of Scala), plus a big focus on verification. It has explicit clock and reset (though nothing precludes automating connectivity of clocks and reset via your generation software).
Post reply on HN