Chisel/Scala hardware description language: why?

[legacy]

RISCV CPU written in the Chisel/Scala hardware description language

(written here, at lowrisc dot org)

I see a few projects are using Chisel/Scala instead of VHDL/Verilog: why?

I have no tools here supporting Chisel/Scala HDL, therefore, before taking it into consideration, I'd like to understand if it gives really good points.

[obiwanjacobi]

Both from Berkeley?   

[legacy]

so it seems ... a Berkeley idea for supporting RISCV 

[brucehoult]

RISCV CPU written in the Chisel/Scala hardware description language

(written here, at lowrisc dot org)

I see a few projects are using Chisel/Scala instead of VHDL/Verilog: why?

Exactly the same reason you might write a program in C instead of in assembly language.

[brucehoult]

so it seems ... a Berkeley idea for supporting RISCV 

Chisel is independent of RISC-V.

Many RISC-V CPUs from outside of Berkeley (or outside the SF Bay area) don't use Chisel.

Many things that aren't RISC-V CPUs do use Chisel. It's just a high level way to flexibly generate Verilog, just as C is a high level way to generate assembly language. In the end, you get gates (machine code) at the end of the process.

Chisel isn't the only recent high-level hardware description language. SpinalHDL is better, and was inspired by Chisel but fixes a lot of perceived problems, and is also built on Scala (which is built on Java).

[ataradov]

Berkeley is a research institution. They need to try new things, otherwise nobody else will.

I'm not a huge fan of it, but realistically only because it is not very wide spread. But it will never be wide spread unless someone is pushing it.

Thankfully there are a lot of other implementations out there in every language imaginable.

[legacy]

Exactly the same reason you might write a program in C instead of in assembly language.

Well, NO!

Talking about my paid jobs, VHDL is *THE* language to design HDL stuff, and I have collected a lot of job-experiences for this, as well as professional tools for this.

Now RISCV appears and when you look at the code, a lot of projects come written in another HDL language for which I have to start from the beginning.

It's not like Assembly vs C, it's a matter of reasons and purpose. Now, or this new language has valid points, or I will avoid spending my time (and probably money) on it.

[ataradov]

VHDL is *THE* language to design HDL stuff, and I have collected a lot of job-experiences for this, as well as professional tools for this.

You are again projecting your opinion. I use Verilog and collected a lot of tools for that. So I think that Verilog is THE language for HDL. Do you really not understand that different people have different preferences?

Also, horses are THE way for transportation.

[ataradov]

Obviously nothing new will be the best choice for real work at first. But you will never get anything new, if you don't try to make new stuff.

I like the recent explosion in programming languages. Some of them got the right ideas, others will be forgotten.

Right now, I would not waste time trying learn Chisel beyond idle curiosity.  But I'm glad that Berkeley spends their time moving that thing forward.

[ataradov]

There is not need for gigantic fonts.

Paid jobs will always be using the old tools, of course. But the question "why you need new stuff then", is invalid.

[brucehoult]

There is not need for gigantic fonts.

Paid jobs will always be using the old tools, of course. But the question "why you need new stuff then", is invalid.

And at my paid job, Chisel is the old HDL that all the legacy hardware was designed with, and the question of the moment is whether SpinalHDL is enough better (it clearly is better) to be worth converting everything to .. or whether Chisel can reasonably be enhanced to match Spinal (probably).

[mark03]

It looks to me as though SpinalHDL is quite similar to the approach taken by MyHDL.  It's unfortunate, IMO, to see MyHDL languishing while the Chisel "language family" gets all the attention and improvement work due to RISCV.  MyHDL has the enormous advantage of being built on top of Python, so you can do your testbenches in Python too.  Imagine writing a bunch of DSP HDL and then using numpy/scipy for verification.  (This is probably where your models and simulations existed already.)  Who wants to do that in Scala?  Yuck.

[ataradov]

To be fair SiFive is in a special position here.

I doubt there are any companies outside of academia that actually used Chisel for anything.

[NorthGuy]

Also, horses are THE way for transportation.

No doubts about this. Every engine is rated in horse powers.

[legacy]

Let's put the question in this terms: How useful would it be to learn Chisel HDL?

[legacy]

Interesting answers here

[NorthGuy]

I've never heard of Chisel before. I looked at their documentation. They claim the language is highly parameterized and layered. After about an hour looking at their examples I couldn't see why it is better parameterized and layered any more than VHDL. It looks very similar to VHDL and I wouldn't have any problem re-writing their examples with VHDL. Most likely this can be done in Verilog as well. The syntax may be slightly better, but I haven't found anything dramatically better. It would be nice if someone could post a comparison between Chisel and VHDL (or Chisel and Verilog) and show where Chisel comes ahead.

Their white paper doesn't provide any specific details. They post an example where you can build a cache module just in few lines of the code (looks like the cache builder is the part of the language). But I don't see how it is different as using externally developed cache module.

[asmi]

IMHO Chisel is a typical product of academia where people tend to be more interested in the process as opposed to result.

[ataradov]

From what I've seen none of the new languages are any better than VHDL/Verilog. They all seem to be "VHDL but in <insert your favorite programming language>".

Hopefully something more interesting comes along soon.

[legacy]

IMHO Chisel is a typical product of academia where people tend to be more interested in the process as opposed to result.

precisely my doubt ...

[james_s]

IMHO there is already enough fragmentation between VHDL and Verilog, two different languages with virtually identical capabilities. The last thing we need is *another* HDL, unless it brings to the table something very unique.

[coppice]

VHDL is *THE* language to design HDL stuff

Except when Verilog is flavour of the month. 

[james_s]

It seems VHDL is the defacto standard in Europe while Verilog is more common in the US. I found there to be far more hobbyist support in VHDL so that's the language I went with. Overall I'd say there is no clear winner.

[asmi]

Overall I'd say there is no clear winner.

Of course there is - it's SystemVerilog!

Let the flame war begin!

[obiwanjacobi]

I find VHDL to be aweful. I find it is endlessly verbose and that is what I think Chisel aims to remedy. I looks (from a great distance) to be a more abstract language. Usually learning the syntax of a new language is not the problem. It is learning the paradigm and mindset (and their libraries and tools) that take real time. Ultimately the goal is to be more productive.

I did some (hobbyist) VHDL but my next project will indeed be in System Verilog. To me that looks like the best blend of abstraction, conciseness and readability. Not perfect but the best we have - not looked at other languages due to lack of knowledge of their existence and sometime lack of available tools.

[james_s]

The verbosity is one of the things I like about VHDL, I find it much easier to read, while Verilog looks like abbreviated gibberish. I can type much faster than I can think so the extra typing is a non-issue.

I've noticed though that some people make VHDL more verbose than necessary, including all the component declarations rather than just instantiating them from the default "work" library. The component declarations are only really needed when integrating a Verilog module.

[tggzzz]

I find VHDL to be aweful. I find it is endlessly verbose and that is what I think Chisel aims to remedy. I looks (from a great distance) to be a more abstract language. Usually learning the syntax of a new language is not the problem. It is learning the paradigm and mindset (and their libraries and tools) that take real time. Ultimately the goal is to be more productive.

I did some (hobbyist) VHDL but my next project will indeed be in System Verilog. To me that looks like the best blend of abstraction, conciseness and readability. Not perfect but the best we have - not looked at other languages due to lack of knowledge of their existence and sometime lack of available tools.

Frequently the productivity depends on the scale and duration of a project.

For a short-duration project completely done by a small team, verbosity can seem a drag. For a longer-duration project, or one where there are multiple teams maybe in different organisations (e.g. libraries), then verbosity can reduce the implementation time.

In most "interesting" projects, implementation is a very small fraction of the total project time. Requirements elicitation and validation, and implementation verification are often the tail that wags the dog. Key question: what percentage of time is spent typing vs designing/compiling/place&route/testing?

In the software domain there is a cycle that I've seen repeated several times:

• start with a non-verbose lanuage with many implicit features (e.g. one or more of variable declarations, dynamically typed variables, control constructs); think C and Basic and Excel(!)
• find applications become brittle and unmaintainable
• move to strongly typed languages with explicit variable declarations and comprehensive control constructs; think Java, C#
• applications become larger and more robust
• new young developer mistakenly thinks the extra typing slows you down
• (re)invent new language with fewer keystrokes; think Ruby and others

... go back to the beginning.

[hans]

There are also "competing" language suites to Chisel, like for example Clash. They both share a similar concept, as Scala has some remedies of functional programming. Clash uses Haskell, which IMO fits even better.

For example, here is a FIR filter:

Code: [Select]

fir coeffs x = dotp coeffs (window x)
  where
    dotp as bs = sum (zipWith (*) as bs)
Function fir takes a vector of coeffs and a value x, of which it calculates the dot-product (defined in "where") of the coefficients and a windowed version of x. The window function can figure out it's depth purely on types, as the function dotp will dictate it (not explicitly shown here).

There is no need to specify the types of the inputs that exactly (e.g. signed, unsigned, or float), as Haskell has kinds which allows for truly generic type programming. The "generics" in VHDL are mainly just some constants you can change manually of a module. The type system of a language is very important, "verbosity" is annoying, but purely lack of correctness-enforcing features is a worry if you want to build working modules.

Both tools are somewhat academic still. These RISC and other projects are proof of concepts, and part of the process of finding design patterns in these tool suites. I think it will takes a long time before any such higher level, more abstract capable, languages will "take over". I think it's the exact same discussion that C is the language for embedded systems (or perhaps some 'older' folks will say it's assembler). Meanwhile in C programs will quickly grow into structs-based data organization, but with the apparent lack of marrying methods to them.

[Nerull]

Exactly the same reason you might write a program in C instead of in assembly language.

Well, NO!

Talking about my paid jobs, VHDL is *THE* language to design HDL stuff, and I have collected a lot of job-experiences for this, as well as professional tools for this.

Now RISCV appears and when you look at the code, a lot of projects come written in another HDL language for which I have to start from the beginning.

It's not like Assembly vs C, it's a matter of reasons and purpose. Now, or this new language has valid points, or I will avoid spending my time (and probably money) on it.

If there is anything the history of programming teaches its that there's never one "*THE* language" for very long.

Then again maybe if you were doing financial computing you'd still be using COBOL, since it was *THE* language for a while, and its not possible for this to ever change.

[mac.6]

There is not need for gigantic fonts.

Paid jobs will always be using the old tools, of course. But the question "why you need new stuff then", is invalid.

And at my paid job, Chisel is the old HDL that all the legacy hardware was designed with, and the question of the moment is whether SpinalHDL is enough better (it clearly is better) to be worth converting everything to .. or whether Chisel can reasonably be enhanced to match Spinal (probably).

Interesting, I was involved in RISC-V effort in my company and Chisel was not seen "good" enough by HW guys due to critical issues with it (mainly at the time the single clock domain was a big no-no). I found SpinalHDL quite interesting and can solve most of Chisel issues, but the lack of adoption is also a big no-no when there is only one guy behind it.
Having SiFive converting to SpinalHDL would be a big accelerator for it.

[filssavi]

There are a bunch of new HDL that look pretty cool, chisel, spinalHDL, etc, they all solve a really important problem, verilog and VHDL are too low level, they are basically whay assembly is to modern x86_64 CPU's,
shure you can program with them, and if you are good the end product will be blazing fast and small, however the productivity is really really low, after all who would want to write a modern application (think of  compiler like gcc or llvm) in assembly?

Moreover testing and verification support in the languages themselves are almost non-existant, and the support for the few features we have is spotty at best, without paying hundreds of thousands of $/€ to the big 3 for their expensive tools.

Unfortunately nothing is going to change in the near future, as there is no competition whatsoever between tool vendors, the big 3 (Cadence, Synopsys and Mentor graphics), are not only producing tools but also definign verilog and VHDL standards and have no incentive to produce a better more modern language, that requires less and simpler tooling as that would considerably reduce the ammount of tools they can sell, and significantly reduce the barrier to entry for new tooling producers that might want to compete on price, forcing them to reduce prices

The only hope of a modernization (revolution) in this field (even though the chances are slim) is for the symbiflow effort to succeed becoming the GCC/LLVM of hardware, a de facto open source standard tool that everyone supports

[FrankBuss]

Interesting answers here

I don't think the answer were interesting. If I didn't missed it, nobody who answered has actually used Chisel. They only say it is a good idea to learn and try new things, which is like a horoscope, always true.

I have tried Chisel, at least some of the tutorials, and I like that it is less verbose, and that it is much easier to write testbenches for it. Of course, if only one clock domain is possible, this would be a show stopper.

Are there any real users in the industry here who uses Chisel, SpinalHDL, or MyHDL? What is your experience? Looks like from the answers in this thread, at least one company uses SpinalHDL. I like Scala (learnt it 6 years ago at Coursera, got a Statement of Accomplishment, with distinction, from Martin Odersky himself) and would try SpinalHDL then. Why is it better than Chisel?

[legacy]

What is your experience?

I work in the avionics field. We only use VHDL on large ModelSim test benches and Cadence software. We have recently spent a lot of time on the ARINC 429 products that require FPGA on the hardware, as well as products with the "voter" unit. There are also AFDX products that require FPGAs for data transfer on aircraft avionics. Nobody has ever complained neither found VHDL too verbose etc.

We usually spend 10-20 months on a product, that must be guaranteed for the next 10 years.

Recently we have also been evaluating VHDL-AMS models for analog/mixed-signal blocks and verify their functionality and performance using the Virtuoso AMS Designer simulator. Two managers still have to take a decision about the final purchase of a couple of new licenses.

Anyway, on my personal laptop, I have my own copy of ModelSim with a license in my name. I am not mixing the analog with the digital. For the analog stuff, I have also a license for Tina professional (sort of PSPICE). But it's more used for designing filters and to check their probable response before I can physically touch the hardware, because, as you can imagine, the hardware is usually not available for me ( I am a freelancer) so I have to ... wait for my turn ... and this might take weeks, so with the experience of the last task, I speculatively anticipate a part of my next task in order to be ready once the hardware is ready


in short, I am working like the branch prediction in the RISC-ish CPUs

(the TINA/Pro software is really helping a lot in this  )

[brucehoult]

Are there any real users in the industry here who uses Chisel, SpinalHDL, or MyHDL? What is your experience? Looks like from the answers in this thread, at least one company uses SpinalHDL.

I'm not a hardware designer, I'm a programmer doing a lot of work with compilers and system software and also (along with the hardware guys) help design new CPU instructions for the hardware guys who sit a few feet away to implement.

I sometimes open a Chisel file and check something, or make a trivial mode, but I'm sadly absolutely not competent to comment myself on the practical differences between writing large things in Chisel vs Verilog.

All CPUs in our company are currently designed in Chisel. This includes at present three different microarchitectures (2-series, 3/5-series, and 7-series) of which both 2-series (2 stage pipeline) and 7-series (8 stage dual-issue) were completely created from initial design to customers using them in SoCs during 2018.

All three microarchitectures are highly parameterized in one source code base (and indeed there is a huge amount of sharing between them). Some of the switches available in all three are (at least!):

- 32 bit or 64 bit
- pure 32 bit instruction opcodes or 16/32
- no integer multiply/divide, or a choice of several speed/area tradeoffs
- speed/area tradeoff in integer shifter
- no FPU, single precision FPU or double precision FPU
- no memory protection, or a configurable number of Physical Memory Protection regions
- no MMU, or MMU
- machine mode only, or User+Machine, or User+System+Machine modes
- private L1 data and instruction caches independently: none, L1 cache or SRAM scratchpad.

Well, there's a lot more, but you get the idea.

The processors generated by this system work, run faster than competitors' processors in the same semiconductor node, are smaller, use less power. Some of this may be due to Chisel. Some of it may be due to the RISC-V instruction set. What I can say for sure is that neither Chisel nor the instruction set gets in the way.

I'm pretty sure that using Chisel (or something similar) is a *major* factor in being able to develop new and competitive processor cores quickly. Both 2-series (Alex) and 7-series (Andrew) are essentially the work of *one* engineer each as far as the HDL goes. Building, of course, on the work that went before in Rocket and 3-series and 5-series, and supported by several dozen other people doing everything from simulation to physical design to writing software to ...

[Bassman59]

A quick web search brings up the Chisel page at Berkeley, and followed links to a user's guide of sorts.

Now, I do VHDL daily, and I've done Verilog in the past, and as a hardware/FPGA engineer I looked to see whether Chisel supports the usual constructs. I also looked to see how it works as a simulation/verification language. Also, I've noted in this thread that many people assume that writing VHDL (or Verilog) is somehow akin to writing in assembly for a processor. That's really not true at all. (If you want an example of VHDL-as-assembly-code, look at the Xilinx PicoBlaze code, which is nothing more than instantiations of the LUTs with INIT values and flip-flop primitives.)

My current work involves data paths from multiple ADCs, with some processing on samples, and pushing those samples into block RAMs for re-organization prior to being shipped out over a communications link. There is also a lot of "other" stuff required, such as a command/data uplink, a command parser, a mechanism to store parameters in off-FPGA non-volatile storage, SPI control of DACs for setting biases and control of ADCs for housekeeping. I think this sort of design is where FPGAs excel, and it's probably the most common sort of FPGA design. There is no sequential-execution processor in this part of the design. (Sensor data go to and commands come from a remote box with a processor, but that's because the processor is well-suited to managing an Ethernet interface.) A current design has three clock domains.

So, with that. I looked at examples for describing synchronous logic, since that's the basis of digital logic design. We're all familiar with VHDL's process and Verilog's always blocks, both of which make clear which signal is the clock, which is an async reset, and so forth. The examples here are, honestly, baffling. None of the examples seem to make clear which clock and which reset are used. Maybe I'm missing something, maybe there's a mechanism to indicate "all of these signals are clocked by this and reset by that," but I can't find it.

I assume that it can infer adders and multipliers, based on operators.

There appears to be a very simply method of instantiating memories, with both synchronous and asynchronous reads.

It has a mechanism similar to a VHDL generic that allows one to pass a, well, generic, down to an instantiated entity where it can be used as a constant or as a thing to select.

There is a thing called BlackBox which allows the designer to hopefully instantiate device-specific hardware, such as high-speed serializers and deserializers or input and output DDR registers and clock PLLs and DLLs, all of which are necessary for real designs. It might be useful to see an example of how Chisel would handle the instantiation of a Xilinx DCM and how it can use that module's outputs to clock various logic parts.

That Chisel seems to think tristates are not important is puzzling -- sure, inside an FPGA we cannot use them, but at the I/O they're used all the time.

That I can't tell what logic is synchronous and what is combinatorial strikes me as somewhat dangerous. You know, the whole Cliff Cummings "Styles that kill" thing, where you can write Verilog with blocking and non-blocking assignments. Hell, looking at the Chisel examples, I can't tell if there's any sort of delta timing model involved.

They admit that for non-trivial test benches you should use Verilog.

OK. That there is a RISC-V implementation written in Chisel is interesting. But what I want to understand is: why is Chisel "better" than VHDL or Verilog/System Verilog? It looks simultaneously verbose yet

Part of what makes VHDL "Verbose" is that you have to specify things like the clock and the reset and which edge of the clock is used for the logic and all of that. A person looking at the code wants to know that stuff. And then we can hide it all by putting it into an entity and verifying the entity is correct, and then instantiating the entity where it is needed.

Chisel has software-based concepts such as inheritance and classes (there's an example which starts with

Code: [Select]

class StackPointer(size:Int) extends Module { ) but are those useful in hardware designs?

Anyways, these are just my first-order thoughts. There are things about the standard HDLs that work well, and things that can be annoying, and we all know the line about "the languages were originally for simulation and modeling with synthesis an afterthought." But, sheesh, it's been over 30 years for VHDL and likely that same amount of time for Verilog, and it is obvious that both languages have evolved to the point where they that "original" concept is obsolete. A competent engineer can write correct descriptions of the intended synthesizable logic and then turn around and write comprehensive test benches (that take advantage of non-synthesizable constructs) in either language.

Or, tl;dr: tell me why Chisel (or, really, any potential new HDL) is significantly better for hardware design and verification than the incumbents, and please don't bullshit me.

[tggzzz]

Useful, apparently sane, review omitted for brevity.

Or, tl;dr: tell me why Chisel (or, really, any potential new HDL) is significantly better for hardware design and verification than the incumbents, and please don't bullshit me.

Too often it comes down to "I don't know the history, so have reinvented the wheel", which implies they are unaware their explanations are bullshit.

The same is true, in spades, for most computer languages. Realising that has enabled me to skip learning many languages-du-jour (e.g. Delphi, D, C++, Modula, Ruby, C#) and concentrate on learning significantly different ones (e.g. Algol, C, Smalltalk, Java) along with knowing the principal benefits of other paradigms so I can implement them in the "trad" languages (e.g. FSMs, various rules-mechanisms).

I'll also note that a traditional pitfall is to develop a higher level language that implements one paradigm very well. But if your problem doesn't fit into that paradigm, you're sruffed and there's no escape route.

That's similar to you noting that Chisel (etc) stumbles badly over vital abstractions like digital clock modules, SERDES i/o blocks, and probably asychronism/metastability.

[Bassman59]

After some more poking around, I found the SpinalHDL documentation, which seems to be an extension (?) or clarification (?) of Chisel, or possibly a fork? Whatever.

All of the examples I saw for sequential logic assumed a clock was defined somewhere but I could not find out how that might happen. I found this page, which discusses the concept of "clock domains," which are applied to the entire design or to individual modules, in a way I haven't quite understood.

What the clock domain concept attempts to do is to wrap up everything necessary for your flip-flops into one instance of a class, and then that instance is sort of hidden away somewhere. By "everything necessary" I mean it indicates the active clock edge, reset type (async or sync) and level, a possible additional synchronous reset, and a clock enable. Why this is preferable to having all of that information right there in front of you in the form of a process which specifies everything is not clear to me. It saves typing?

SpinalHDL has a built-in check to warn you if your signals cross clock domains without a special tag applied to the signals. Crossing clock domains is not an error, we do it all the time, and the competent engineer will handle that appropriately (and put comments in the code indicating such).

Possibly the biggest thorn in the rose here is that there is zero native synthesis support for this language. Whatever you write gets boiled down to synthesizable Verilog or VHDL. So you have to trust that the boiler does the right thing and doesn't generate stupid VHDL. Experienced FPGA design engineers know to check what the synthesizer actually implements from the source code; sometimes the synthesizer makes baffling choices. With Chisel/SpinalHDL there's an added step -- is the resulting hardware wonky because of the SpinalHDL description, or the SpinalHDL-to-Verilog conversion, or the Verilog synthesis that you should probably constrain in the usual way?

So, again, I ask, why is SpinalHDL "better" than the incumbents? I realize that's a purely rhetorical question as nobody on the language definition team is reading this.

And that last sentence brings up a good point. "People" like to complain that VHDL and Verilog were "designed by committee," with the implication that the reason the languages are "suboptimal" is because of the committee. But why is a new language designed by a couple of guys at a university better? The language committees exist for good reasons. How else can you possibly get significant input from experts from all over, with different points-of-view and different experience? No single person, and no small group, can possibly have the breadth of experience needed to do this sort of language definition.

[Marco]

Why this is preferable to having all of that information right there in front of you in the form of a process which specifies everything is not clear to me. It saves typing?

Also screenspace and it prevents copy paste errors.

[brucehoult]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages

[tggzzz]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages

It strikes me Chisel is in need of a decent whitepaper, along the lines of Gosling's 1996 Java whitepaper. That stated, with admirable brevity and clarity, what the key features were, why those features were chosen, where the features had been successfully used in anger, and why all of the features played well with each other. Plus which features were omitted and why (that's important; consider C++ ).

A standard problem of organically-grown DSLs is that they do one thing well and cover 80% of the requirements. Provided your application is within those requirements, the DSL can be very productive. But when you go outside the 80%, you fall off a cliff. I would like to see a statement of what's outside the design objectives.

Finally, that article states "Due to language features and libraries, the real utility metrics become: How many lines of code do I need to describe some component? Does the language enable writing and reusing code?".  That's a typical non-professional hacker mentality. Professional think a useful metric is "how quickly can I get a demonstrably working solution". Bugger the number of lines of code and code reuse; they are secondary.

[NorthGuy]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

I, by now, have read several articles about Chisel, including white papers and some of the docs. Everyone says that Chisel has new paradigms, but, for some reason, they're shy to say what these new paradigms are. I won't buy the idea that "the best way to tackle this is to do deep dives on mature Chisel code". If nobody can tell what the new paradigms are and I cannot see any new paradigms by myself, perhaps the new paradigms are not there.

[tggzzz]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

I, by now, have read several articles about Chisel, including white papers and some of the docs. Everyone says that Chisel has new paradigms, but, for some reason, they're shy to say what these new paradigms are. I won't buy the idea that "the best way to tackle this is to do deep dives on mature Chisel code". If nobody can tell what the new paradigms are and I cannot see any new paradigms by myself, perhaps the new paradigms are not there.

I am coming to that conclusion, too.

I've seen too many such attempts in this arena and also mainstream computer languages; not following them has saved me years going up blind alleys.

[legacy]

In short: I will go on with VHDL & my commercial tools until something will convince me that I'd better consider Chisel/Scala.

Chisel/Scala requires Java (it's in its dependency), and the procedure to compile the tool is ... a bit long and complex, so ... frankly, I don't like to deal with Java on PowerPC/POWER, which is my daily development platform.

for this turn, I am out 

[Bassman59]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages

From a comment on that article:

The synthesizable subset of Verilog, VHDL, etc. share qualities of both procedural languages (C) and low-level languages (assembly). This makes them poorly matched to solve classic hardware design problems: design re-use (we write the same modules over and over) and specialization (targeting different FPGAs, ASIC toolchains, VLSI technologies).

For the assertion about design re-use, has the commenter never heard of modules? Every FPGA engineer I know has a "kit" full of proven modules ready to be reused in new designs. We don't "rewrite the same modules over and over."

As for specialization, nothing in the description of Chisel appears to actually deal with the differences in device families -- they have an out and say, "just black-box the chip-specific thing."

Regarding toolchains, that's actually a separate issue from the design entry (which is, after all, what Chisel is all about). I write the VHDL and then use a synthesis tool to build a netlist ready for the place-and-route. The VHDL doesn't care* which synthesis tool is used. Nothing I've seen in any of the Chisel documentation addresses constraining designs, whether for timing or for placement, which does make sense -- the logic design doesn't really care about timing (up until you have to reconsider your design so it meets timing, that is). But to complain that VHDL and Verilog are ignorant of toolchains while Chisel itself is ignorant of toolchains doesn't make any sense.

* well, to the extent that we use synthesis pragmas to direct the operation.

[brucehoult]

If anyone is still reading here, the answer to this stackoverflow question is pretty good

I, by now, have read several articles about Chisel, including white papers and some of the docs. Everyone says that Chisel has new paradigms, but, for some reason, they're shy to say what these new paradigms are. I won't buy the idea that "the best way to tackle this is to do deep dives on mature Chisel code". If nobody can tell what the new paradigms are and I cannot see any new paradigms by myself, perhaps the new paradigms are not there.

I really can't say. I'm a software and instruction set design guy, not a hardware designer. I've never done anything serious in any of Chisel, Verilog, or VHDL.

What I *can* say is:

1) the guys who sit a few desks away from me designing CPU cores and SoCs in Chisel are very happy with it, and are knocking out new and competitive designs at an astounding rate considering the small number of people in the company

2) no one is trying to sell you Chisel. No one except you is going to make more or less profit depending on whether you use it or not. You've been made aware of it, investigated, and made up your own mind. Great!

[legacy]

Next week we will meet a salesman of the ensilica group. They have an interesting Configurable Embedded RISC Processor, covered by a full development tool.

So I was said. I am curious to see the environment 

[NorthGuy]

What I *can* say is:

1) the guys who sit a few desks away from me designing CPU cores and SoCs in Chisel are very happy with it, and are knocking out new and competitive designs at an astounding rate considering the small number of people in the company

2) no one is trying to sell you Chisel. No one except you is going to make more or less profit depending on whether you use it or not. You've been made aware of it, investigated, and made up your own mind. Great!

Perhaps you *can* do more. Ask those happy guys what's the single most important quality of Chisel which puts it ahead of other languages, and post their answers here.

[legacy]

LOL

for me the premium point for staing on VHDL ....  is ... hey, oh? I spent 14 months at designing and developing a stand-alone beautifier, from the lexer to the parser, and then from the parser to AST used to the semantic action (which does nothing, it's not a translator, it's just a code beautifier, but it's cool when you exposer your project to people because having an AST opens the door to more features .... eventually a translator from VHDL to Verilog? maybe)


Oh, so: should I have to start again from the beginning for a new language?!?!? 

I want a "n", and a "o", say NO

[ataradov]

People should not stop working on stuff just because you don't need it. Just leave the thread if you don't have anything useful to contribute.

It is not a Scala author's problem that you developed some tools for VHDL. I don't think anyone here cares.

I too would like to hear from those developers at SiFive.

[brucehoult]

Perhaps you *can* do more. Ask those happy guys what's the single most important quality of Chisel which puts it ahead of other languages, and post their answers here.

I asked them and they gave me the link I posted here yesterday.

Chisel is just one part of a hardware creation pipeline that works a lot like LLVM in software.

With LLVM you have various programming language compilers including clang (c/c++), go, rust, fortran all producing LLVM IR (Intermediate Representation). You can then run a variety of machine-independent and machine-dependent optimisations over the IR. Then you feed the IR to a code generator for x86 or ARM or RISC-V or whatever. If someone writes a new optimisation it will work with every language and every processor. If someone writes a new processor back-end it will work with every programming language. Etc.

In the case of Chisel, it's a high level language for humans to specify not just some particular item of hardware, but generators for families of hardware designs.  Chisel outputs firrtl. There are general optimizers for firrtl that clean up the design. There are optimizers for firrtl that mold the design to fit better FPGAs (or to better fit LUT4 or LUT6 FPGAs), or better fit SoC. There are "optimizers" for firrtl that obfuscate it so you can give synthesizable HDL to someone and it will work but they hopefully won't be able to figure out how it works or change it. Then there are back ends for firrtl that produce Verilog or other traditional HDLs to feed into a physical design workflow.

In addition to being able to parameterize modules with Chisel, there is a tool called Diplomacy that works out the constraints on parameters between instantiations of different modules, doing things such as finding the best bus width between two modules, or deciding whether some control signal is necessary or not given the options chosen.

Not everyone needs all this stuff. If you're doing one fixed design that will only be implemented in one way then you might be just as well off using traditional tools. It's like trying to explain to someone who is perfectly happy writing ARM assembly language why they might want to use C instead (so their code works on x86 and PowerPC and RISC-V as well) or why they might want to use C++ templates, or why they might want to write a program in Perl or Lisp or Haskell that generates some of the C++ code for them.

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

[vsmirnov]

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

Chisel itself is a very simple language. So, given prior Verilog experience, this bootcamp should be enough. The complexity is in Scala itself, functional-style programming (type system, objects, collections, immutability etc), in its build tools (sbt), IDE integration (I'd recommend Intellij IDEA community, VSCode/Metals may be also OK). Scala is a pretty complex language, so some good  primer is strongly recommended if there is no prior Java experience. With prior Java experience, Scala tutorial should be enough.

[vsmirnov]

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

AFAIK, small modules can be simulated this way. 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. If something goes wrong, going back to Scala to fix the error can be problematic. EdgeTPU folks shared their experience with Chisel:

.

The most complex issue was with design validation that was much longer for them with Chisel than it usually was with traditional approaches. But they did love hw/sw co-design that Chisel enabled for TesorFlow developers.

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.

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

[tggzzz]

When assessing a new tool or concept, you need to understand the (claimed) benefits. For something radically different, an order of magnitude "better" is the minimum. The tools proponent's will usually trumpet these things loudly (and hopefully clearly).

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.

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

[tggzzz]

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.

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.

When I come across proponents of X that make statement like "X is good for P₁ if C₁ is true, but not for P₂ nor P₃", then I am much more likely to believe their claims. Over the decades I've come across far too many people that claim "everybody should use this hammer"

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