21–30 of 78 posts
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?
Earlier quoted context omitted.
Their docs explain it. It’s sorta like “implicit this”. https://www.chisel-lang.org/docs/explanations/multi-clock
Thanks, so a single clock and reset is implicit, but clock2 (or more) is explicit.
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…
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…
Have you looked at/used Bluespec SystemVerilog? If so, any comments based on your experience? https://github.com/B-Lang-org/bsc
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 and you've got to work out how the compiler will compose things. At least you do if you care about how many cycles something takes. I never did any frequency optimisations either which would also be harder as it'd be deeply coupled to the rule scheduling behaviour.
Ultimately like many new HDLs it's a nice language from an abstract perspective but very much feels like someone with little practical experience with building real world silicon just applying software language design to hardware. The non existent type system of SystemVerilog being viewed as a major problem rather than what it is in reality an annoyance that causes more medium than any real substantial issues.
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.
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.
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…
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 from HDL to System Verilog, and associating the tool outputs to your inputs: a ton of effort has gone into CIRCT to ensure its output is decently readable by humans _and_ has good PPA with popular backend tools. There is always room for improvement here, and new features are coming to Chisel in the form of intrinsics and new constructs to give designers fine grained control over the output.
On top of this, a new debug[3] intermediate representation now exists in CIRCT, which associates constructs in your source HDL with the intermediate representation of the design as it is optimized and lowered to System Verilog. Think of it like a source map that allows you to jump back and forth between the final System Verilog and the source HDL. New tooling to aid in verification and other domains is being built on top of this.
Besides this, the combination of Chisel and CIRCT offers a unique solution to a deeper problem than dealing with minor annoyances in System Verilog: capturing design intent beyond the RTL. New features have been added to Chisel to capture higher-level system descriptions, and new intermediate representations have been added to CIRCT to maintain this information and its association to the design. For example, you could add information about bus interfaces directly in Chisel, and have a single source of truth generate both the RTL and other collateral like IP-XACT. As the design evolves, the collateral stays up to date with the RTL. I gave a talk[4] at a CIRCT open design meeting that goes into more detail about what's possible here.
[3] https://circt.llvm.org/docs/Dialects/Debug/
[4] https://sifive.zoom.us/rec/share/MhHtXPg_7iZk-QWw0A66CaBJDGs...
I much prefer SpinalHDL, having used both.
I much prefer SpinalHDL, having used both.
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'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.
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'…