Why a system generator (Chisel) and not a purely RTL based approach?

[Shishir KC]

Hello, this is a just a beginner question out of curiosity.

I was curious to know why a high level synthesis based approach using a system/HDL generator like Chisel was used, as opposed to a conventional RTL based approach (VHDL, Verilog, SystemVerilog) for the design. Was there a specific reason why this was chosen, during development? My basic understanding of HLS vs. a pure RTL approach is that HLS has considerable overhead as opposed to RTL, but offers the advantage of shorter development cycles. Was this the primary reason for the chosen approach, or is there more to the decision that was made? 

[christop...@gmail.com]

Chisel is NOT high-level synthesis. Chisel's primitives are wires, registers, and memories.  There is no "overhead" in regards to area/power/timing versus using Verilog. I prefer to think of Chisel as Verilog++, where Chisel provides stronger bulk connections, object-oriented programming, and functional programming frameworks to better describe how to organize wires, registers, and memories.

At Berkeley, we used to use Verilog for designing things like vector processors, with parameterizable pipelines, execution widths, and pipeline organizations. We found it insufficient for effectively describing highly parameterizable designs like vector-issue schedulers (where you might want to change the number of lanes, elements, and sharing of functional units). We also found ourselves wasting a lot of time on Verilog-specific issues, like gate-level vs RTL-level simulation mismatches, due to poor Verilog semantics in which simulation behavior changes meaning at different levels. In contrast, Chisel generally only generates well-formed, linted Verilog. It's crazy how much effort can go into lint-cleaning industry-written Verilog!  

Above all, Chisel allowed us to write libraries of hardware components that could then be re-used. Things like parameterizable cross-bars and arbiters which helps when plugging new components together in a parameterized fashion. One example that has been particularly fruitful is that we could more easily thrown down more cores and devices and get a new uncore with the proper routing and connections once we had written a library for uncore components (like clock-domain crossing components). In industry, in my own experience, many of these aspects are not written in Verilog, but rather created using some sort of "generator" (perhaps written in Perl) that generates Verilog. The nice thing about Chisel though is that it is a proper DSL language with a compiler IR; so if your Chisel code compiles and runs, it should generate proper Verilog. With Perl/Python-based Verilog generators, the front-end language has no knowledge of what it is actually generating, so it is more easily for a incorrectly programmed Perl generator to give you garbage Verilog that doesn't lint/compile/work.

To speak more to that last point, industry doesn't like Verilog, but they suffer through it. Some companies have their own wrapper/meta-language to try to protect the designers from the more painful aspects of Verilog. Unfortunately, these tools remain in-house, so nobody else gets to learn from them, extend, or improve them.

You can read more about how Chisel has been used here (https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-17.pdf). You can also watch Google's talk on using Chisel for the EDGE TPU (https://www.youtube.com/watch?v=x85342Cny8c). It's a bit-outdated, in part because some of their pains are from using an older version of Chisel, but it gives a good feel for some of the advantages of using Chisel and some of the growing pains of using it within industry.

-Chris

[Giacomo Bernardi]

It Is for sure true that industry suffers verilog because it Is not strongly typed and hence error prone. 

For this reason many companies prefer to stay on vhdl, that produces more robust code even if It requires more of effort on the coding side by the designers.

For these companies to use chisel as generator would imply a too radical shift. 

So It seems to me that if chisel would have also vhdl as back-end It would offer the best both in front end and back end, beside the fact that its market target would greatly increase.

Is it being considered by the chisel community?

--
You received this message because you are subscribed to the Google Groups "riscv-boom" group.
To unsubscribe from this group and stop receiving emails from it, send an email to riscv-boom+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/riscv-boom/6bf8384d-8de4-4b5e-ba28-eb8159c010a8n%40googlegroups.com.

[luke.l...@gmail.com]

this is a complex topic on which Chris responded very informatively, providing valuable insights.  i'd like to provide some additional perspective, both as a Software Engineer having learned RTL, and as to why we picked nmigen rather than Chisel.

Chris is absolutely correct about Verilog being... tolerated (barely).  somewhere (around the 80s-90s) it was initially developed as a way to do unit tests (on gate-level designs), however at some point i believe someone noticed that the actual designs could be expressed *in* that unit-test language and it took off from there.  note: 80s and 90s.  when Object-Orientated programming languages were an extreme rarity.  it really has not progressed or evolved since.

now look at how programming is done, now.  classes, exceptions, multiple-inheritance (unless you love java), these are all normal.  except in HDL.  question: why should HDL engineers be "punished" and told that they can only develop HDL using languages designed 30-40 years ago?  you can't even load and process/use a CSV file in Verilog (but interestingly apparently you can in VHDL).

hence things like pyrtl, nmigen, myhdl and Chisel3 and many others came about.

the ability to use [multiple] inheritance has two immediate benefits:

1) code-reuse.  saving huge amounts of time

2) incremental development when it comes to unit tests.  you can have unit tests that test the base class... *and save code on the over-rides*.  if you design it right you could even mirror the multiple inheritance, base-classing the *unit* tests along-side the code that it is testing.

here's the thing, though: one of the down-sides of [multiple] inheritance is that the code complexity goes *up* with the number of subdivisions.  you risk changing the API of a base class at a fundamental level, breaking complex contracts, and spreading code out across dozens of files.  so there is that to watch out for.

the other thing is: no matter what the language, if it is entirely devoid of comments it really does not matter how "good" or how "compact" the language is.  this is one of the things severely holding rocket-chip back (the base for BOOM).  the code is "compact"... *because it has zero comments*.  by total contrast, the libraries to which Chris refers, (chisel3 io), the ones used *by* rocket-chip (BOOM) are exceptionally well-documented.

the last point is to look at the TIOBE index for python and for Scala.  python is right at the top: scala only very recently even entered the top 20.  with python being known by over 30% of all programmers and Software Engineers on the planet, the decision to use it instead of Scala (and Chisel3) was a no-brainer.  that just left us with an evaluation process to pick a python-based HDL, and nmigen proved to be the best, with the largest most dynamic community.

the summary then is that it is not about the actual HDL language, at all: it's a suite of interlocking factors, and at the heart of those, the common theme linking them all is: communication.

l.

[Shishir KC]

Probably because Verilog is more close to a programming language like C/C++/Scala structurally and VHDL is much different owing to the "strongly-typed" nature. Most of Europe, and some defense and space standards subscribe to VHDL. I too wonder why a VHDL code generator doesn't exist, at least thanks to my ignorance. 

[luke.l...@gmail.com]

On Monday, November 9, 2020 at 11:48:18 AM UTC skc.s...@gmail.com wrote:

Probably because Verilog is more close to a programming language like C/C++/Scala structurally

 naah :) verilog in no way has object-orientated inheritance, the 2008 IEEE approved syntax you cannot pass records as parameters to modules: that is a proprietary non-standard feature added to Synopsis variants only.

and VHDL is much different owing to the "strongly-typed" nature.

which, personally, i love.

 

Most of Europe, and some defense and space standards subscribe to VHDL. I too wonder why a VHDL code generator doesn't exist, at least thanks to my ignorance. 

chisel3 itself provides the strong typing and OO inheritance.  the translation to verilog is treated as a machine code target.  by transitive application of the benefits of chisel3 *there is no need* for the assembly-code-like verilog to *itself* have strong typechecking. 

by logical inference VHDL although it would have such checking it is utterly redundant because the chisel3 compiler *has already done that job* and in a much mire thorough way than the underlying features of VHDL could.

even if it was added, the resultant VHDL, again being a machine-code-like target, would still be as hopelessly unreadable by humans as its verilog equivalent.

what you *might* be hoping for is a means and method of "importing" VHDL **INTO** chisel3 applications as a foreign object.  obviously this would not simulate under the chisel3 simulator, you would have to compile to a common language and for that you could use yosys with the ghdl plugin, or verilator, or (very recently) the new cxxsim backend developed by whitequark that has been added to yosys and is language-independent.

or you simply compile the chisel3 application to verilog, import *that* as a foriegn object into a verilog simulator, and likewise import the VHDL HDL source into the same.  again: verilator and yosys cxxsim will support this.

bottom line is that there is no benefit to the idea of chisel3 outputting VHDL, and there exist conversion tools to get to where i think you probably want to go, but they are nothing to do with (and should have nothing to do with) chisel3 itself.

i leave you with that, to return to BOOM specific discussions.

best,

l.