Experience has taught me to be skeptical when a new HDL is proposed. It seems that aspiring HDL language designers insist on repeating the very same mistakes. (It goes without saying that MyHDL, my own project, is the exception.)

A recent HDL that is getting some attention is Chisel. After all, if it comes from Berkeley, it must be interesting.

Here is a hint to everyone that wants to evaluate HDLs: review the assignment semantics. They tell you a lot about the nature of the language. Therefore, I propose to review section 3.1.1, "Assignments and reassignments" in the Getting Started manual for Chisel. I will go over it line by line and add my comments.

When you first define a value in Chisel, we use the = operator in order to tell Chisel to allocate the value for the first time.

OK, that would be like constructing an object and giving it a name to refer to it later. We do the same in MyHDL.

On every subsequent reassignment to the value, we must use a := when reassigning the value.

That makes sense also. We use dedicated assignment statements to change the value of an existing object.

Since we are constructing a digital circuit, the notion of reassignment does not make much sense since connections between circuit nodes only need to be specified once.

This is a puzzling statement. It would suggest that Chisel reduces the goal of an HDL to structurally constructing a circuit. What about describing behavior, which is the main reason why industrial HDL designers use VHDL, Verilog, SystemC and MyHDL?

Moreover, if reassignment makes no sense and single assignments are the rule, the implication is that Chisel has only concurrent (parallel) semantics. There would be no support for procedural (sequential) semantics whatsoever, unlike the popular HDLs listed earlier.

Really? Perhaps we are missing something. Let us read on.

However, there are some cases when we will need to perform reassignment to a value in Chisel since it is compiled sequentially unlike Verilog.

By now the confusion is complete. How so, Verilog is not compiled sequentially?? How is it compiled then, by starting at random lines in the source code? Of course not. Verilog is compiled sequentially just like any source code.

Perhaps the Chisel folks confuse compilation with simulation semantics? Do they mean that Verilog is a fully concurrent simulation language? That would then be completely wrong also. Verilog does have full support for procedural semantics. All statements within a begin-end block are procedural.

Thus it may be necessary to perform reassignment when a value or connection is not known until later in the Chisel source.

If this is supposed to be a difference with Verilog, it is again completely wrong. The way you handle concurrent assignments in Verilog is identical to the way described here: you declare a wire, and later in the source you use a dedicated assignment statement to assign an expression to it. It is called the assign statement in Verilog.

And so the information on assignments in Chisel ends.

When we look beyond the errors and confusion, what have we learned about Chisel? All it supports is the "construction" of hardware through concurrent assignments. Because of its Scala foundation, it can probably to so in a sophisticated manner. Although the industrial relevance is limited, there is some value in that.

However, there is a much better option for that kind of modeling: MyHDL. Because of its Python foundation, the parametrization features of MyHDL are second to none, as demonstrated in this example. But for MyHDL this is just a starting point that almost comes for free. Its main focus is on what matters most: behavioral modeling. For that reason, MyHDL supports not only concurrent, but also procedural modeling.

In contrast, Chisel HDL merely repeats the flaws of an endless list of older HDLs. Those flaws can be summarized and refuted as follows:

• The main problem in HDL design is not constructing and generating hardware. Rather, it is behavioral modeling and verifying correctness.

• The fact that "hardware is concurrent" does not imply that an HDL should have concurrent semantics only. On the contrary, a procedural description is often the clearest and most powerful way to describe a piece of hardware behavior.

Apparently, aspiring HDL language designers are not very strong at background research of industrial needs. Not even if they come from Berkeley.