Chisel/Scala hardware description language: why?

[NorthGuy]

The problem is that design validation is done in the corresponding ASIC tools, and it's done in Verilog, because this is what they can work with.

Apparently, whoever designed ASIC tools thought that supporting Verilog for their tools was better than supporting Chisel. So did FPGA vendors.

I've heard RISC-V team designed their own tools. I wonder how they work?

[vsmirnov]

I've heard RISC-V team designed their own tools. I wonder how they work?

There is an ISA-level simulation either through Qemu or Spike, it's easy and should be enough for software part that does not require exact timings of operations. Accelerators are represented as an RISC-V ISA extensions. PlatofrmIO embedded IDE & tools are just excellent. Board integration works excellent, including on-chip debugging.

Small scale RTL simulation works with Verilator. Alternatively, the infrastructure can utilize vsim if it's available. There is also a Chisel-specific FireSim (it works with FIRRTL, so any frontend producing FIRRTL may work too). FireSim is free, opensource, it can simulate entire compute clusters on multiple Amazon F1 instances at the speed of 10-100th of MHz. But, obviously, you can't run it on your desktop

[SiliconWizard]

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.

Certainly, but what you said would hold for comparing an open-source code generator with a commercial code generator. Point is, I was more comparing a code generator with a standardized language, and experience has proven again and again that code generators are likely to fall out of favor eventually, whereas standardized and industry-proven languages have an extremely low probability of falling out of favor for the foreseeable future. So with a standard HDL such as VHDL, Verilog or SV, the probability of tool vendors stopping their support is close to zero IMHO.

Additionally, not all companies are willing to bother themselves with maintaining such tools (similar to maintaining your own compilers, as tggzzz mentioned.) Another factor is that if you're working in a regulated field, proving the tools you use are validated is often mandatory, which can make things hairy if you choose "exotic" tools.

The tool being open-source sure gives you the *possibility* of not having to throw away years of work in case the tool stops being officially maintained, but that doesn't give you any *guarantee*. So as I said, this is always a tough choice. And the point is not so much that it's an open source or commercial tool, but rather that it's "exotic" enough that you can't predict it will keep people interested on a scale large enough that future maintenance will be reasonably guaranteed. Having to take over maintenance yourself one way or another is not always an option.

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.

The difference is that companies using in-house tools usually have the internal knowledge and experience with them. Sure in some cases, when some key people leave, the knowledge required for maintaining them is lost. Yes I've seen this as well, but every time, it's a management fault. Reasonable management can't let this happen, especially if said tool is critical.

Which makes me say this: if, after weighing the pros and cons, you still choose some such third-party particular tool, whether it's open-source or not, you have to organize things such that enough knowledge is acquired, not just for using the tools, but for possibly maintaining it as well. Then you'll be ready if anything goes wrong. A corollary of this, if the tool is open-source, that we have already discussed on this forum, is: just because some tool is open-source, don't assume it will cost zero. It has definite benefits, but it can actually cost you much more than a commercial tool, at least if you manage things in a reasonable way. So in particular here, as a company, I wouldn't choose Chisel unless I could make sure enough knowledge about its internals could be gained in-house.

As for validation, refer to the above. In some regulated fields, this may actually be a real concern.

As I mentioned earlier, I've witnessed university departments trying to push this kind of tools to industrial companies. They often fail to convince them in the end, and what I've seen is that in many cases, such tools end up in spin-offs/start-ups more or less founded around those tools. Now if such tools constitute the "core" tech of some company, even with possible shortcomings, that's obviously a different matter.

Just my 2 cents. I'll certainly be curious to see if Chisel survives a decade from now.

[vsmirnov]

Just my 2 cents. I'll certainly be curious to see if Chisel survives a decade from now.

It definitly will because it's backed by academia and some commercial legal entities. RocketChip, that is state of the art in RISC-V R&D, is using Chisel. But there is a versioning issue. Chisel is not backward compatible, as well as Scala itself, and there is a high risk that you will end up with completely unsupported version of the developments stack (that is huuuge) in a perspective of just a few years. For the same reason, I'm never considering Scala for long-term development until absolutely necessary. Ad-hock things, playing around with new technologies and esoteric language features, picking up best design techniques is OK. So if someone ever considering using Chisel in long-running commercial development, they do need an infrastructure team maintaining this tool.

[vsmirnov]

What they usually fail to do is discuss whether the  benefits could be achieved by other less radical technologies. Frequently, by careful application of existing technology, those benefits can be achieved. Often it appears that the proponents don't know how to use traditional technologies well.

It can be an argument from ignorance, but I just don't know better tools for hardware construction. If you need hardware design space exploration and/or software/hardware co-design, then Chisel/RockChip is the way to go (RockChip contains pretty big library of reusable modules as well as a lot of actual examples coming from risc-v soc code). Building my own tool for that? No way, I'm done with this. I'd better learn Chisel's internals and become a committer. Because everything I can do in a reasonable timeframe will be worse than Chisel.

[vsmirnov]

I don't know Chisel. While I can believe it is a reasonable tool for some forms of hardware/software codesign, I doubt it is the tool for all forms of that. There are just too many forms of that, and it is only a small part of system design.

It's that simple. If those tools do really exist, they deserve considering. But I don't know anything about them, maybe out of ignorance. I'm definitely a newbie on this field. With pretty high certainty I can say that if you need RISC-V design space exploration, then Chisel is the way to go.

There is one exception when I will be considering in-house metaprogramming tools, it is boilerplate code generation. Using Chisel for that will definitely be an overkill, given all this code versioning headache derived from Scala. Some form of "interface definition language" (IDL) and a codegen from it is definitely the way to go. AntLR4 + Java/C++. This tool will be working even after 50 years. But if there is even slight chance that this IDL should be Turing-complete, then it's very-very-very easy to get into Turing tarpit (this is what happened to C++ TMP). In such case, considering existing field-proven tools is a reasonable decision.

[tggzzz]

The RISC-V toolset sounds as if it is in the same space as the Mill Computing toolset. But the Mill Computing toolset is used for far more than simple hardware generation.

As for C++ TMP, it was most amusing to watch the reactions while TMP was being designed[1]. The language designers refused to believe their creation was Turing complete until someone rubbed their noses in it by creating a valid C++ program which caused the compiler to emit the prime numbers during compilation.

That confirmed my decision to avoid C++, which I've never regretted. If the language designers don't understand their creation, what chance have mere mortals?!

[1] another favourite was the endless debate over whether it must be possible or impossible to "throw away constness". There are solid use-cases for both.

[DiTBho]

so, to make it short, I have the feeling that Chisel is the RAD for FPGAs 

[mac.6]

There is an interesting project, FireSim. It's cycle-accurate digital hardware simulator running on FPGAs (Amazon F1) with pretty high speed, 10th of MHz. FireSim takes Chisel input, compiles it to FIRRTL, then augments this intermediate representation (IR) with assertions, logging and all other requested machinery that is necessary for simulation. This instrumented IR then is compiled down to Verlilog and to FPGA bitstream. FireSim is cloud-scalable and can utilize hundreds of FPGAs. It can simulate entire computing clusters, not just a single chip.

There are success stories, when BOOM people could be able to find subtle bugs in their OoO engine billions of cycles deep. They said, that traditional simulator required months for such deep simulations.

It's way more than interesting, we use intensively emulation/simulation for functional verification and software pre-development on FPGA at work and this kind of thing can really be a game changer.
We use a mix of FPGA boards and Zebu emulation machines, but both have caveats and limitations that make this emulation process painful and complicated.
Having a scalable emulation platform like this could be a game changer. Today it's too limited as we need broad HDL support (verilog. VHDL, SV) but it's surely something very interesting.

[vsmirnov]

It's way more than interesting, we use intensively emulation/simulation for functional verification and software pre-development on FPGA at work and this kind of thing can really be a game changer.
We use a mix of FPGA boards and Zebu emulation machines, but both have caveats and limitations that make this emulation process painful and complicated.

I agree, I was modest saying that this project is interesting. On the software development side code instrumentation works extremely well for testing, verification, deployment and maintenance. And even for development. BAR folks just brought this technology to HW development by introducing a  feature that is pretty common for model compilers -- semantically reach intermediate representation. In-house tools can be run against it doing such magic tricks. This is actually the difference Chisel is actually making. It's not about the HDL itself at all.

Having a scalable emulation platform like this could be a game changer. Today it's too limited as we need broad HDL support (verilog. VHDL, SV) but it's surely something very interesting.

According to this page there is a Verilog-to-FIRRTL compiler (Yosys) that might help in your situation. From my (again, very SW-biased) point of view, instrumentation is so powerful tool, that I even would be ready to contract a person who can fix Yosys for my cases (V* -> FIRRTL) to be able to utilize FireSim. But I'm fluent with C++/Java and with opensource code bases, so YMMV. If you fink that fixing Yosys for your cases in beyond feasibility, it's most likely true.

You can also watch Circt project. Chris Lattner has proven track record of delivering very successful compiler technologies (Clang, MLIR, Swift).

[vsmirnov]

so, to make it short, I have the feeling that Chisel is the RAD for FPGAs 

Actually, for ASICs, because this is what they are mainly working with. RocketChip RISC-V can target FPGAs, but their cores are pretty big and somewhat slow. Single rv64ima core takes around 6500K LUT on Arty A7-100t and fmax is somewhere at 75MHz. Not sure about actual Dhrystone rank for this core. You can put one "big" core rv64imafdc into this FPGA at 50MHz with pretty large L1D/I$ and DDR3. And you have some room for accelerators. Vivado utilization reports attached. Folks who want to know where to get Arty100TShell with integrated DDR3 controller, it's in this branch.

Specifically for FPGAs (for purposes other than just validation/simulation) I'd choose fpga-optimized risc-v cores.

[NorthGuy]

so, to make it short, I have the feeling that Chisel is the RAD for FPGAs 

You're kidding. If you want RAD, open Vivado, drop few IPs on your screen, draw some connections, and you're done.

[vsmirnov]

You're kidding. If you want RAD, open Vivado, drop few IPs on your screen, draw some connections, and you're done.

Ahaha. He is not. Same thing for RocketChip, just in text. Drop in some desired core parameters, accelerators, FPGA shell, salt, sugar -- and ops! You have a SoC for your board. Not that many fpga boards are supported out of the box right now, but it's a different story. I don't think that writing a new board shell should be a challenge for an experienced HDL engineer.

[brucehoult]

The RISC-V toolset sounds as if it is in the same space as the Mill Computing toolset. But the Mill Computing toolset is used for far more than simple hardware generation.

The Mill tools are completely and automatically changing the binary encoding of the instruction set from model to model in the design space. The distribution format for apps has to be compiled at install or first run for every different machine.

Or would if they had any machines. The project started well before the RISC-V project and, as far as we know, they don't even have anything running in an FPGA yet.

The Mill is a radically more ambitious project than RISC-V but ... time is passing, and windows of opportunity with it.

[brucehoult]

so, to make it short, I have the feeling that Chisel is the RAD for FPGAs 

Actually, for ASICs, because this is what they are mainly working with. RocketChip RISC-V can target FPGAs, but their cores are pretty big and somewhat slow. Single rv64ima core takes around 6500K LUT on Arty A7-100t and fmax is somewhere at 75MHz. Not sure about actual Dhrystone rank for this core. You can put one "big" core rv64imafdc into this FPGA at 50MHz with pretty large L1D/I$ and DDR3. And you have some room for accelerators. Vivado utilization reports attached. Folks who want to know where to get Arty100TShell with integrated DDR3 controller, it's in this branch.

Specifically for FPGAs (for purposes other than just validation/simulation) I'd choose fpga-optimized risc-v cores.

RocketChip and Chisel/FIRRTL can target and optimize for FPGAs, but the evaluation cores that SiFive distribute as RTL or bitstream are optimized for SoC so as to give the best fidelity per clock to the eventual SoC, even though this results in more resource usage and a lower Fmax on the FPGA than optimizing for FPGA would give.

[brucehoult]

You're kidding. If you want RAD, open Vivado, drop few IPs on your screen, draw some connections, and you're done.

Ahaha. He is not. Same thing for RocketChip, just in text. Drop in some desired core parameters, accelerators, FPGA shell, salt, sugar -- and ops! You have a SoC for your board. Not that many fpga boards are supported out of the box right now, but it's a different story. I don't think that writing a new board shell should be a challenge for an experienced HDL engineer.

Olof Kindgren's "FuseSoC" seems pretty good too, and works with a variety of open RISC-V cores and FPGA boards. https://fusesoc.readthedocs.io/

[vsmirnov]

Olof Kindgren's "FuseSoC" seems pretty good too, and works with a variety of open RISC-V cores and FPGA boards. https://fusesoc.readthedocs.io/

Very-very cool thing. Small and powerful. Thank you for the reference!

For C++ there is Vcpkg package manager that is built on similar ideas. The package manager of choice for my C++ libraries.

[DiTBho]

RocketChip and Chisel/FIRRTL can target and optimize for FPGAs, but the evaluation cores that SiFive distribute as RTL or bitstream are optimized for SoC

how is it done? 

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

In this process Chisel/Scala would need specific RTL information in order to carefully *chisel out a groove* (word pun  ) for one of the many "optimal(n)" solution (literally choosing the best way to express a digital set of behaviors under constraints) for a given problem for a given FPGA.

solution_space/constraints[]={optimal(0), optimal(1), optimal(2), optimal(3),... , optimal(inf)}
optimal(0) namely "zero-optimal", and optimal(inf) namely "absolute optimal" aka "utopia"

This would imply a solid knowledge about physical FPGA resources available inside the chip and constrains (some are hidden, some are visible), which is a semi public available information unless you also assume you can "probe" not only a chip but the whole process that creates the bit-stream for a chip (or "reverse engineering" it?)

Code: [Select]

z = new(problem, chip, constraints[]);
do
{
     x = new_attempt(z, strategy, methods, etc ...);
     HDL = Chisel/Scala(x);
     bitstream = VendorToolchain(HDL,chip); /* -> RTL -> GL -> bitstream */
     load_bitstream_into_FPGA(bitstream);
     s = testbench_fpga();
     err=compare_diff(expected(z),got(s));
}
while (abs(err) < acceptable);

Even assuming you know it, I imagine you would have somehow to provide this information to Chisel as input if you want it to output some "optimal(n)" code.

Chisel/Scala(some extra information) -> HDL(some optimal(n)) -> RTL -> GL -> bitstream 

[brucehoult]

RocketChip and Chisel/FIRRTL can target and optimize for FPGAs, but the evaluation cores that SiFive distribute as RTL or bitstream are optimized for SoC

how is it done? 

The same way as humans write HDL that is optimized for SoC or specific FPGAs. Optimizing the use of FFs vs SRAM, arranging circuits to fit nicely into LUTs with the appropriate number of inputs, and so forth.

However I'm not an expert or even a novice in this -- I've only talked to the people who are experts (and develop Chisel and FIRRTL).

[vsmirnov]

how is it done? 

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

Architecture search is not feasible for such kind of designs, especially taking into account exceptionally long bitstream compilation times. All target-specific optimizations are explicitly coded in the framework. Like, "if ASIC flow is specified, then we are using these generators, otherwise -- those ones". Local search is possible, though. And may be used at FIRRTL processing stages.

[NorthGuy]

how is it done? 

Humans optimize things, not machines. Look at the PicoBlase code (as well as the doc which describe how they wrote the code). This is an example of code optimized for Spartan-6 FPGA. Similarly, you can optimize for ASIC.