Hello everyone! My name is Jan Decaluwe and today I am starting a series of blogs about MyHDL -- a Python-based HDL (hardware description language) that I created.
At first glance, MyHDL looks like an open-source alternative to Verilog and VHDL (see also Max's Verilog and VHDL blog). You can use MyHDL at the register transfer level (RTL) of abstraction for synthesizable code, or at higher levels of abstraction for tasks like system modeling and verification.
"Hmmm," I hear you saying: "Why would we need yet another HDL? How can such a project fly without EDA vendor support? This sounds like a crazy idea!" My answer to this is simple and clear -- in order to realize the full potential of HDL design, we need a better HDL. Verilog and VHDL are holding us back.
Now don't get me wrong, VHDL and Verilog have served us exceptionally well, but they also have significant issues. Some of these issues are intrinsic to the languages, while others are man-made, but they all work in the same direction -- they lead designers, as by an invisible hand, toward low-level coding styles and away from modern practices. Let's briefly consider a number of these issues along with MyHDL's answers to them...
When coding at the RTL level (I know that the use of the word "level" is redundant, but it sounds right and you know what I mean), integer arithmetic is omnipresent. However, Verilog and VHDL make integer arithmetic unnecessarily difficult. The problem is with their RTL type system, which starts from bit vectors and attempts to attach integer-like meanings to them afterwards.
In practice, this concept is broken. For example, mixing "signed" and "unsigned" variables in an expression is notoriously tricky. It gives rise to subtle bugs and you need awkward castings and resizings to make things work.
By comparison, MyHDL starts from integers that work like integers in the first place. Then it allows you to access the bits -- if required -- according to the standard two's complement representation.
Under the influence of the RTL type system in their HDL, many designers use a bit-level representation for constants. Consequently, RTL code often contains lots of bit strings to represent integer constants and state encodings. Designers seem to think that they have to help the poor, easily-confused synthesis tool to get the bits right. Quite obviously, this should be the other way around.
The result is code that is unnecessarily hard to read. Worse yet, bit string representations are a source of subtle bugs. MyHDL puts you on the right track by encouraging human-friendly representations -- integer constants in decimal and symbolic state names.
Variables are one of the best understood programming concepts, and they are supported by both Verilog and VHDL. Nevertheless, even though mainstream HDL design is more than 20 years old, HDL designers still haven't figured out how to use variables properly.
An important factor is Verilog's confusing support and obscure terminology for variables ("blocking assignments"). However, the main problem is man-made. Instead of teaching how to use variables, mainstream Verilog guidelines ban them altogether (in clocked processes). Thus, the confusion is "solved" by brute force amputation.
In reality, local variables work just fine in clocked processes and synthesis supports them without a problem. They can be very useful with regard to writing clearer and more elegant code. Due to a set of mistaken guidelines, many designers remain unaware of these possibilities, and that's a shame.
MyHDL has separate variables and signals, like VHDL, and its signal assignment is more explicit. By making the distinction with signals crystal clear, it encourages the use of variables.
Next page >