Chisel/Scala hardware description language: why?

[legacy]

Just leave the thread if you don't have anything useful to contribute.

You are irritating people in this topic (yer, I got two PMs telling me how irritating you are), so I wanted to do some humor, which is based on what people like me really think about a new tool: we have spent our free and paid time on our daily tools, now we would like to hear WHY we should invest time in another tool.

[ataradov]

how boring and stupid you are in this behavior 
even when someone is kidding 

Stop doing this stupid post and delete thing. You are not kidding, you are trolling.

[legacy]

Stop doing this stupid post and delete thing. You are not kidding, you are trolling.

OK, enjoy my ignore list.

[legacy]

@brucehoult
ok, supposing I use Chisel/Scale, and I get ... VHDL files automatically generated. This would be good for my ModelSim and other HDL simulators that I usually need to use. But, supposing now that I get a problem in the wave-view of ModelSim: how difficult is to backpropagate the problem on Chisel/Scala sources?

This makes me a bit perplex (probably I need to try myself)

p.s.
LLVM works well on x86. On MIPS ... it's full of problems.

[brucehoult]

Maybe this is useful:
Or this:

[obiwanjacobi]

Watched the first one, made perfect sense.
Thanks Bruce.

[NorthGuy]

Watched the first one, made perfect sense.

I also watched it. It was interesting to watch. The presentation is focused entirely on SoCs - basically he presented a toolkit for quickly building SoCs. I've never worked with ASICs, so it's hard for me to understand why it is difficult to add UART to a design. I often use UART for testing and adding a test UART module to FPGA design takes only a minute (synthesis/implementation time not included). HDL blocks are very easy to put together on FPGA. Xilinx even has a graphical approach where you just instantiate IP modules and draw the connections using a mouse. You can build a "SoC" this way in a matter of hours without ever writing any code. Not everyone uses this approach, but many do. In the end, the FPGA tools analyze the logic, analyze what's inside FPGA (LUT, DSP, RAM, FIFO etc.) and map the design accordingly. If you use Chisel which compiles to Verilog, and then Verilog is synthesised by FPGA tools, the FPGA tools will do this for you anyway. Unless you specifically target certain elements, I don't see any reason to do this externally. The tools will also automatically delete extra wires on the bus, the tools will delete them. ASICs certainly are very different, and I don't know much about ASIC tools, but I would expect the synthesis tools to have at least the same level of intelligence as FPGA tools, at least judging by the price.

The second one was difficult to watch - I couldn't really see what on the slides, so I only could listen. It doesn't appear that the speaker expects FIRRTL optimization to improve the design. To contrary, he presents a method to find bad FIRRTL which may result if you do something stupid. His solution is to go back and re-write. This is similar to typical design flow with FPGA timing tools - if you write something stupid, your design will fail timing, the tools will show you the failing critical path, and then you would go back and re-write.

[Bassman59]

I also watched it. It was interesting to watch. The presentation is focused entirely on SoCs - basically he presented a toolkit for quickly building SoCs.

And for those designs which are not based on an SoC -- which my guess is the majority -- this approach offers no true benefits.

I've never worked with ASICs, so it's hard for me to understand why it is difficult to add UART to a design.

Adding the hardware is not.

I often use UART for testing and adding a test UART module to FPGA design takes only a minute (synthesis/implementation time not included). HDL blocks are very easy to put together on FPGA. Xilinx even has a graphical approach where you just instantiate IP modules and draw the connections using a mouse. You can build a "SoC" this way in a matter of hours without ever writing any code. Not everyone uses this approach, but many do.

What makes Vivado's SoC tools (and EDK before it, and Altera's version, and MicroSemi's version) effective for SoC designs is that when you instantiate an IP core in the hardware, you also get a firmware device driver. You get the base address for where the core's registers live in the processor's memory map and you get some handy functions to work with it. And if you change a connection or add a feature, behind the scenes the tools will keep everything in sync.

I don't see any of that being the case with the Chisel stuff, although some clever people may have worked that out.

[brucehoult]

The second one was difficult to watch - I couldn't really see what on the slides, so I only could listen. It doesn't appear that the speaker expects FIRRTL optimization to improve the design. To contrary, he presents a method to find bad FIRRTL which may result if you do something stupid. His solution is to go back and re-write. This is similar to typical design flow with FPGA timing tools - if you write something stupid, your design will fail timing, the tools will show you the failing critical path, and then you would go back and re-write.

The difference is that using his FIRRTL analysis tool he finds out the design is bad within a few seconds, instead of waiting possibly several hours for the FPGA synthesis.

[NorthGuy]

The difference is that using his FIRRTL analysis tool he finds out the design is bad within a few seconds, instead of waiting possibly several hours for the FPGA synthesis.

True. FPGA synthesis/implementation software is very inefficient.

[Bassman59]

The second one was difficult to watch - I couldn't really see what on the slides, so I only could listen. It doesn't appear that the speaker expects FIRRTL optimization to improve the design. To contrary, he presents a method to find bad FIRRTL which may result if you do something stupid. His solution is to go back and re-write. This is similar to typical design flow with FPGA timing tools - if you write something stupid, your design will fail timing, the tools will show you the failing critical path, and then you would go back and re-write.

The difference is that using his FIRRTL analysis tool he finds out the design is bad within a few seconds, instead of waiting possibly several hours for the FPGA synthesis.
[/quote

By "design is bad," do you mean the logic is not correct, which is why we have test benches and verification, or doesn't meet timing?

[vsmirnov]

Just my 2c to this discussion about Chisel/SpinalHDL vs Verilog/VHDL as a software engineer exploring design space of hardware accelerators. DISCLAIMER: Because I'm not a hardware engineer, my view on this topic is software-biased.

The problem with Chisel (that I'm currently playing with) is that the output is Verilog and all important tools work with this output, not with the original input. There is (or was) no clear way from *.v back to the *.scala source for this *.v. This source mapping (that exists for all high-level programming languages) is not that simple thing in case of Chisel than one might imagine. Because Chisel HDL is not a classical programming language like C or Java. It's a metaprogramming-heavvy language where the source is a metaprogram (a program generating another program), so plain source mappings doesn't work here. AFAIK, Chisel-native simulation is in works, and there is also Circt project by Chris Lattner, which aims to remake the ideas behind FIRRTL (the Chisel's intermediate represenation) on a more systematic ground. But currently, as far as I can understand it, the automated flow is mostly unidirectional: from Scala source to Verilog. Inverse mapping may be tricky if something goes wrong on the Verilog side.

Chisel may shine in cases when metaprogramming is necessary/inevitable. Because Scala was specially designed for "metaprogramming in medium/large". For example, if you need very specific CPU core, SV is probably is the way to go. But if you need to be able to quickly materialize some subspace of the design space for a class of CPU cores, metaprogramming is necessary. And usually such metaprogramming goes far beyond "template instantiation". C++ has Turing-complete template metaprogramming (TMP) and I can generate pretty complex algorithms and data structures using high-level specifications, but writing and maintaining template metaprograms is real pain. This thing is not scalable. TMP doesn't scale at all. It's that simple.

And if folks think that using Perl/Pythog to generate Verilog is the solution, than I have bad news. This doesn't scale (in the meaning of programming in large) the same way C++ TMP doesn't scale. Sure, it may work extremely well for cases when all requirements are known beforehand (closed world assumption), but it doesn't work for open worlds. You will find yourself designing some metaprogramming language for this. In the best case, you will resort to Scala, Haskell or even modern C++.

This is why Chisel shines at SiFive (I'm not affiliated with them anyhow), because they are selling custom configured CPU cores, which can be augmented with user-supplied software accelerators (In Chisel or in Verilog). I don't know how common this usecase in hardware design, but in software engineering metaprogramming is currently a cornerstone. It's used everywhere. But not everywhere -- explicitly. You can easily be unaware of it writing some JavaScript, Java or sometimes even C.

So, Chisel is a DSL in Scala for writing HDL generators by piggybacking on the Scala-provided metaprogramming infrastructure that is pretty powerful. RISC-V+accelerators is a commecrcially-proven showcase for this software-centric technilogy.

If Scala's powerful metaprogramming is not necessary (if SV/VHDL-provided parametrization is enough), then Chisel will be an unacceptable overhead over Verilog.

Small addition. Folks argued above that adding some module to an FPGA design in Verilog may be as easy as typing this sentence. That's true. But metaprogramming in Chisel goes far beyond simple composition. As other folks also mentioned, Chisel has Diplomacy. We can think about it as a application-specific type of constraint solver allowing different modules to agree on values of various free parameters across the entire design. Without constraint solving, this is a painful manual work for large designs.

[brucehoult]

Seems like a fair summary.

Something that makes meta-programming more debuggable is if there is an ability to save and view the results of the meta-programming, before it is converted to something far different and unrecognizable from the original source.

LIke "gcc -E".

One of the great pains with C++ is it doesn't have this kind of facility for templates.

[DiTBho]

LIke "gcc -E".

"-E" tells GCC to stop after the preprocessing stage, the output you get is what the cc1 compiler will actually get after expanding all macros. I have used it several times to better understand *which* #if #else block was actually in use.

Nice trick! Nice example

[SiliconWizard]

This is a non-trivial question, but those "code generators" are very popular, in general, in the academic circle. University researchers are kind of obsessed with code generators in general. I've seen a lot of them. The industry, OTOH, is usually kind of wary of them. Sometimes they are designed to allow some level of formal verification, sometimes to allow more abstraction, or a combination of both.

Even though some of those tools in general, and Chisel in particular, are interesting, one of the reasons to be wary is long-term support, or any support at all. Settling for Chisel, for instance, when you're an industrial company, is a tough choice. You won't know if or when it will basically become an abandoned project. You'll also have a hard time finding engineers able to properly use it - or the learning/training phase may be pretty long. Another point is robustness. How was the code generator ever validated exactly? It's often hard to compare code generators to industry-proven tools. Then yes, the generated code is usually very hard to make sense of, so this can become hard for low-level simulation or other tasks.

As to configurability, frankly, well-written VHDL or SystemVerilog both allow writing configurable designs without much problems. Some extra features could make it even easier, but this is definitely doable.

SiFive was founded by Berkely researchers who worked with Chisel - sort of a spin-off, so the reason it's used there is obvious and not just related to the inherent merits of Chisel, or at least it's a circular rationale.

As vsmirnov noted, there definitely are specific benefits of Chisel, but with the above said, I for one would not use it, at least in an industrial setting. Just MHO though.

[brucehoult]

Even though some of those tools in general, and Chisel in particular, are interesting, one of the reasons to be wary is long-term support, or any support at all. Settling for Chisel, for instance, when you're an industrial company, is a tough choice. You won't know if or when it will basically become an abandoned project.

The consequences of an abandoned open source project are quite different to the consequences of an abandoned commercial product. If it does the job you want it to do it will keep doing it, and no one can ever tell you you're not allowed to continue using it. You also have everything necessary to adapt it to work on later OS versions, or generate different Verilog, or to fix bugs. Well -- everything necessary except the skill, perhaps, but you can probably find someone to contract that out to.

You'll also have a hard time finding engineers able to properly use it - or the learning/training phase may be pretty long. Another point is robustness. How was the code generator ever validated exactly?

I find such concerns generally overblown. Every large and/or old company has similarly critical and complex things developed in-house, but which are usually much less well documented, *absolutely* impossible to hire people who already know them, and once the people who wrote them move on you're in a much worse position.

[tggzzz]

Software engineers always want to invent a language and/or implement a compiler.
Hardware engineers always want to invent a microprocessor.

Both are misguided, due to the effort required to produce the surrounding tool sets,  and the difficulty of hiring/training good people to use niche tools.

Another software delusion, for those same reasons, is inventing a domain specific language when a domain specific library in a standard language would be perfectly adequate and without disadvantages.

But then 40 years ago while at university I remember impressing one interviewer by stating that I had zero interest in writing a Pascal compiler, and another interviewer by noting that while I had a preferred microprocessor, the most important decision factor was the tools that enabled you to use it.

[vsmirnov]

I see that this metaprogramming argument is somewhat confusing, so let me share my story with Chisel.

I have a long-running personal project in the area of advanced data structures. It's mostly a personal research and a source of fun, but I had some non-trivial production experience with it. The idea is somewhat similar to Chisel/RocketChip, but instead of generating hardware, I'm generating application-specific data storage and processing engines based on high-level requirements. Implementation is very different, Memoria is using C++ TMP, and because of that its metaprogramming core is not even nearly sophisticated as Chisel's one.

Advanced data structures have been considered impractical because of high CPU costs. Data usually is stored in memory in a some compressed format, so each access operation might have pretty big hidden constants in O-estimation of its time complexity. OoO helps a lot but doesn't make a real difference. Nevertheless, potential is huge and very appealing. For example, we can use compressed multidimensional spatial trees (with space complexity of 2 bits per node) to encode functional approximation and use it instead of multilayer perceptrones (modulo the curse of dimensionality). Perceptrones have linear complexity form the number of parameters in the hidden layer, but spatial trees have logarithmic complexity. Huge difference for power-constrained use cases.

Compute-intensive applications require special hardware that, from another side, must have software-driven design. Or software-hardware co-design, if I don't misuse this term. I tried to jump into HDL area to develop application accelerators for Memoria, but actually HDL is an another full-time+ job. And I'm already having two (regular job and personal projects). Anyway, there were no FPGAs with HBM memory, and all such things I'm talking with are memory-bound. But recently I could be able to buy Alveo U50 with 8GM HBM, that is a game changer for hobbyists like myself. Also, Arty A7-100 as a "starter kit".

Long story short, I was able to get custom version of RV64 multi-core setup with DDR3 running on my Arty A7-100 in just a few weekends. Zero-to-hero. Original Freedom SDK does not provide DDR3 for E310 soft risc-v core (because it's an MCU), I had to solve the problem myself. Important thing is that I have a lot of freedom within the design space. I can implement single "fat" OoO core, or even multicore SoC, or manycore (dozens+ on U50) system of small cores equipped with application specific accelerators.

The latter is the most important thing. Given specific class of problems, I can infer the kind of hardware acceleration it is required (matrix multiplication, FP-intensive, integer-intensive, memory-intensive, some combination of the previous, some specific memory hierarchy, etc) and to generate specific accelerators for RVxx cores, as well as the software part.

This is what software-hardware co-design is (at list it is how I see it). Chisel + RocketChip is responsible for the hardware part. But in order to understand this technology better, it should be put into the context of much larger process where there are multiple generators responsible for different aspects of the system.

Chisel, as standalone technology, is not that impressive even for myself. Scala is good for metaprogramming, as I have said above, but unfortunately it's not good enough, given modern requirements. Scala's build tools are still based on the good old "make" paradigm from 80th, but now "on steroids". What we need is fully-featured dataflow-based data platform with elaborate RESTful API for external automation and integration, exposing the entire build process together with all intermediate artifacts available through this API to external tools like IDEs, we need extensible analytics on top of intermediate data. With today's Scala you will have hard times trying to get RocketChip working normally in an IDE. Emerging LanguageServer pattern is the right way to go, but it's still in the infancy. C++ is nowhere near as well as Scala, but I'm working to fix this situation.

The whole thing of Chisel is not the HDL itself, and not the Scala, of course. It's that advanced software engineering practices like utilizing intermediate representation preprocessing for various automation tasks are entering traditionally conservative hardware design and engineering. Chisel is just one of the early birds. Much better things are coming. Thanks to the RocketChip, I was able to jumpstart completely new area for my project in just a few weekends. Yes, it's a good time to be alive

 

[NorthGuy]

But currently, as far as I can understand it, the automated flow is mostly unidirectional: from Scala source to Verilog. Inverse mapping may be tricky if something goes wrong on the Verilog side.

It's much simple. If you have an HDL language, it must compile into something. There's no assembler. So Verilog it is.

There may be some Assembler-equivalent HDL languages, such as XDL in ISE. But I can't envision language creators who have enough guts to write a compiler which will compile their language into XDL.

[vsmirnov]

But I can't envision language creators who have enough guts to write a compiler which will compile their language into XDL.

Watch Circt project. I'm sure they have.

But, as far as I understand, the issue with Chisel is not that it compiles to Verilog and not to some low-level representation. But in that FIRRTL compiler does (did) not preserve source mapping metadata. So there is no easy way to which part of the Verilog code corresponds to which part of Scala code. And the simulation is done in Verilog, not in Scala. What is (was) even worse, the compiler is (was) eager to rename everything on each new compilation. Those complains have a long beard today, so I hope many of those issues have been at least remedied since that.

As opposite to that, Circt project is based on MLIR (multi-layer intermediate representation) that is declaring source metadata preservation as one of  primary goals. It's targeting SV, but MLIR can be lowered to pretty any basic formal language using standard compiler techniques. 

[tggzzz]

When compiling anything from a "higher level" representation to a "lower level" representation, there is loss of information. Examples: C->asm, LISP->C, Chisel->Verilog.

The only way around that is to encode meaning/significance in the form of metadata.

If you are going down that route, you need to understand what the Mill architecture is doing and why. https://en.wikipedia.org/wiki/Mill_CPU_Architecture

[ali_asadzadeh]

Nice tutorials on chisel/Scala etc are needed, more beginner friendly steps on how to do things, etc.... because most of us have done a lot Verilog or VHDL, so the question is how easily we can switch to this new approaches, certainly I would like to make my life easier

[DiTBho]

It's much simple. If you have an HDL language, it must compile into something. There's no assembler. So Verilog it is.

HDL stands for "hardware description language", it's one level on the top of RTL and it doesn't actually compile, it provides information to the RTL level.

RTL stands for Register-Transfer-Level, it needs RTL-models, and it directly compiles into GateLevel, which needs physical implementation details.

GateLevel is then used by synthesizers to build bitstream (which needs more physical implementation details), and bitstream is then loaded into CPLDs/FPGAs's configuration chip, usually static RAM or Flash.

It's not supported by synthesizers but technically HDL can also describe analog things, making your "hardware description" compatible with PSPICE.
 
Chisel/Scala is "one level above" HDL.

Hope this schema is correct, if so that's the hierarchy of the whole new toolchain:

Chisel/Scala -> HDL -> RTL -> GL -> bitstream or whatever

[NorthGuy]

So there is no easy way to which part of the Verilog code corresponds to which part of Scala code. And the simulation is done in Verilog, not in Scala.

Sure, it should be possible to create a tool which simulates Scala directly.

Verilog is not a low-level presentation (as assembler is to C). Just another HDL. You can synthesize and implement it on FPGA, or you can use it for ASICs. You cannot do this with Scala. If vendors supported Scala, you wouldn't need Verilog at all. Until then, you have to suffer whatever inconveniences there are.

[NorthGuy]

HDL stands for "hardware description language", it's one level on the top of RTL and it doesn't actually compile, it provides information to the RTL level.

RTL is not a level, and you certainly can use HDL to describe hardware which doesn't have a single register in it.

HDL can describe hardware it two ways. Structural - what the hardware consists of and how things are connected. Behavioural - what the hardware should do. Synthesis translates everything to structural. So, in a sense, structural is lower level, even though the same language (e.g. Verilog) can be used to describe it. It is as low as it gets without going into implementation.