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

71–78 of 78 posts

Re: Chisel: A Modern Hardware Design Language

#71

Post by mrmax99 »

irdc wrote: post #14

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…

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.

Re: Chisel: A Modern Hardware Design Language

#72

Post by mrmax99 »

modulovalue wrote: post #15

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

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/

Re: Chisel: A Modern Hardware Design Language

#73

Post by xw3089 »

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’re preaching to the choir on improving validation. Like you mentioned, In commercial designs that’s where a majority of the man hours actually go, and coincidentally where basically none go in academia where chisel is popular.

I will mention though, not all IP needs max PPA or specific control of the netlist and there could be initial opportunities there. Especially with the cost per area on many nodes going significantly down it can be more economical, at some volumes, to save man hours with HLS even if it leads to larger areas, which in theory means more production cost but in reality might not even change the floor plan.

I think we’re going to see more HLS, not less.

Re: Chisel: A Modern Hardware Design Language

#74

Post by xw3089 »

chrsw wrote: post #35
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…

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

I think this comes from the idea that running the EDA flow is like compiling software and that’s the problem, it’s not.

The EDA flow, the software that goes from verilog to manufacturable files, is electrical engineering. Sure, it’s heavily automated, but it’s not fully automated. And if you want a semi decent chip, the tools need a ton of hand holding. And if you want a great chip, get prepared to dig into all the intermediate files…

If you just want a chip, any chip, they can kinda give you that in a fully automated way.

Re: Chisel: A Modern Hardware Design Language

#75

Post by xw3089 »

tverbeure wrote: post #62
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-gener…

There are tons of other practical problems. The HLS generated verilog is name mangled. This makes it really hard to generate all the various control files you need to run the EDA flow, the software that assists in turning verilog into manufacturing files. If you have a super stable design, like a codec, then you can deal with it because it’s basically a waterfall development cycle. But if you have a design whose requirements are changing as you develop it, like most things. HLS doesn’t fit into the existing organizational structures and you’ll end up with a less optimal circuit.

Re: Chisel: A Modern Hardware Design Language

#76

Post by tverbeure »

xw3089 wrote: post #75
tverbeure wrote: post #62

Earlier quoted context omitted.

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

There are tons of other practical problems. The HLS generated verilog is name mangled. This makes it really hard to generate all the various control files you need to run the EDA flow, the software that assists in turning verilog into manufacturing files. If you have a super stable design, like a codec, then you can deal with it because it’s basically a waterfall development cycle. But if you have a design whose requ…

This is not true for SpinalHDL and Amaranth/migen (I can’t speak about Chisel): the names of registers and IO ports are totally predictable and there’s no issues generation timing constraints, placement constraints etc.

If our backend team doesn’t complain about HLS, it most certainly won’t complain about RTL generators.

FWIW: the codecs are not super stable designs at all. They’re under constant development.

For modern ASICs, layout partitions are so large that your backend tools see hundreds of thousands of instances that are on the same clocks. The synthesis tools may have special recipes for optimization (which, again, you can still do), but the backend flow is mostly concerned with meeting timing on that clock. Except for external IOs, it’s rare to have specialty timing constraints at within partitions.

Re: Chisel: A Modern Hardware Design Language

#77

Post by Dolu »

ux01 wrote: post #29
cmrx64 wrote: post #2

I much prefer SpinalHDL, having used both.

Are you active in the SpinalHDL community? Reason for asking is this page: 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 Also note that isn't a VHDL thing but a synthesis thing. But I think you'…

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

Re: Chisel: A Modern Hardware Design Language

#78

Post by Dolu »

xw3089 wrote: post #75
tverbeure wrote: post #62

Earlier quoted context omitted.

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

There are tons of other practical problems. The HLS generated verilog is name mangled. This makes it really hard to generate all the various control files you need to run the EDA flow, the software that assists in turning verilog into manufacturing files. If you have a super stable design, like a codec, then you can deal with it because it’s basically a waterfall development cycle. But if you have a design whose requ…

> The HLS generated verilog is name mangled

Chisel, SpinalHDL, Clash, Migen, Amaranth aren't HLS

Most of the time, if you get some verilog out of those tools with mangled names, it can be because of bad coding practice.

Here is some examples about how to preserve good names for SpinalHDL : https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/S...

Post reply on HN