Why MyHDL?

Introduction

Why MyHDL? Here is a good reason: MyHDL is open-source software that you can use for free. However, there are many other good reasons why MyHDL is worth considering. This page describes a number of common situations and opinions, and how MyHDL addresses them. If you recognize them, MyHDL may be a good solution for you.

New to digital hardware design

Let's be honest about it: there's a lot to learn and it will be hard work. However, choosing the right development language can make the task significantly easier. Python is one of the easiest programming languages to learn, and MyHDL aims to achieve the same for hardware design.

Moreover, with MyHDL you can convert your designs automatically to both Verilog and VHDL. So you keep all your options open.

Dynamic language power

If you're a practicing hardware designer, you're probably using dynamic languages (sometimes called "scripting" languages) in your workflow already. For example, tcl is popular for tool control. Also, many designers use perl to glue things together. Others use ruby or Python for that purpose.

It is clear that these high-level dynamic languages play an essential role in modern digital design. Verilog or VHDL alone is not enough. Many designers even prefer those languages over their HDL, because they can get things done quickly with them.

Wouldn't it be great if one could use such a language directly to design hardware? That's exactly what MyHDL offers.

Modern software techniques

In the software methodology world, a lot of innovation is going on, with buzzwords such as "agile", "rapid application development", "scrum", and "test-driven development". This is not just hype. The new ideas and techniques offer real improvements to the development processes. Naturally, they are emerging in the communities of modern software languages, such as Python.

As HDL-based design has many similarities with software development, the new ideas are potentially quite relevant. Nevertheless, the hardware design world seems detached from them.

By using MyHDL, the newest software development techniques are readily available to the hardware designer, thanks to its Python foundation. For example, you can use a Python unit test framework to do test-driven development for hardware design.

Algorithm and implementation unified

Python is an ideal language for algorithm development and many engineers use it for this purpose. Commonly this work and a subsequent HDL implementation are done by different engineers. They use a different set of tools that require a specialized level of knowledge.

MyHDL is a big step towards the unification of the two domains. With Python/MyHDL an algorithm or model designer can explore HDL implementation and an HDL designer can explore algorithm and model design, all within the same environment. Of course, the conversion from algorithm to an HDL implementation still requires knowledge of HDL-based design. But being able to do this while staying in the powerful Python environment can be a significant boost to quality and productivity. For example, the verification work can directly be reused between both design domains.

Target both Verilog and VHDL

The usage of Verilog versus VHDL differs significantly between regions and sectors. However, there is every indication that the overall ratio is about fifty-fifty, and will remain so in the forseeable future. Consequently, it is often desirable that a design be available in the "other" language also. For IP developers, this may even be an explicit design goal.

Using MyHDL is a solution. A MyHDL design can be automatically converted to equivalent code in both Verilog and VHDL. Actually, using MyHDL and conversion is probably the best solution available for language-neutral design. It is obviously superior to manual conversion. Moreover, direct convertors between Verilog and VHDL don't work very well. Using a syntactically simple language like Python as the starting point is an easier way to a create a high-quality conversion tool.

Explicit, but not verbose

VHDL has many virtues, but conciseness is not one of them. Many feel that the syntax is verbose and even redundant, and even experts need a manual nearby to get the syntax right.

Python is different. It is concise. One reason is that it is a dynamic language without declarations. But the major reason is its well thought out design. Moreover, it achieves this without resorting to "magic". The code remains explicit, but the syntax has been reduced to the essence. Python has been called executable pseudocode, and that's actually a quite accurate description.

Power, not complexity

SystemVerilog has been called a "dumping ground" for any feature ever dreamed up by an EDA company. Through the process of "donations", the language contains an ever increasing pile of builtin constructs and features. Of course, not all of them can be equally important or well designed. The experience can be overwhelming.

One might think that language complexity is a necessary consequence of feature complexity. However, a language like Python shows that this is not true. The core Python language is actually very small. However, it is designed for extensibility and modularity. Most of the action happens in libraries, with the core language serving as a common ground. There is an extensive standard library that comes with the distribution. In addition, there is a vast amount of third-party libraries available for all kinds of functionality. MyHDL is an example.

Python's modular structure explicitly separates the essential from the secondary. After learning the small core language, you only need to study and import those libraries that contain the functionality that you need. This is a superior and scalable way of dealing with complexity.

Signals and variables, like VHDL

One of the most confusing aspects of Verilog is about the difference between blocking and non-blocking assignments. Actually, if you are not confused about this, you probably don't have enough experience :-).

Here is the problem. The semantics of blocking (=) versus non-blocking (<=) assignments are radically different. So different in fact that a language like VHDL (and MyHDL) uses dedicated objects called signals to implement non-blocking semantics. However, in Verilog, you can use and mix the two types of assignments on any object.

In many cases, Verilog's permissiveness on this matter is senseless and confusing. Consequently, most designers follow guidelines on acceptable use patterns. Unfortunately, as a testimony to the initial confusion, such guidelines can be overly restrictive. For example, a commonly used guideline basically forbids variable semantics in clocked synthesizable processes completely!

MyHDL follows the sensible example of VHDL. It has dedicated signal objects and signal assignments that correspond to the semantics of Verilog non-blocking assignments. The clear separation between signals and variables avoids the confusion about the two types of assignment.

Signal assignments done right

Hardware Description Languages need a way to describe racefree communication between parallel hardware blocks. This is the purpose of VHDL signal assignments and Verilog non-blocking assignments. In both languages, these assignments are implemented using a special assignment symbol, which happens to be identical: <=. We will refer to "signal assignments" in the following discussion.

As signal assignments are not natively present in software languages, HDL newcomers often have problems with them. While this is a normal part of the learning process, the VHDL and Verilog approach doesn't help. Consider the following pseudocode snippet of signals assignments:

a <= b
b <= a

Even when this code is inside procedural code, the semantics are concurrent. In particular, the value of a used on the second line is not the one assigned to a on the first. The value used is the current value, while the value assigned is the future value of a.

MyHDL uses a different approach. Instead of a special assignment symbol for signals, it uses attribute assignment to the special attribute next. Attribute assignment is common in object-oriented languages. Our example becomes:

a.next = b
b.next = a

In this way, it is explicitly clear that the assigment on the first line isn't modifying the current value, but the next value of the signal.

A MyHDL designer merely has to learn that a signal's future value should be modified by assigning to its next attribute. From there on, the semantics are clear from the code.

Straighforward integer arithmetic

When writing synthesizable VHDL code, you typically use the signed and unsigned types for arithmetic operations. These are "representational" types that focus on bit representation and bit width. The operators defined for such types have stringent requirements on the types and bit widths of operands and results. As a result, you typically need a lot of conversion functions and resizings. Many designers take this for granted and view it as a result of VHDL's strong typing. In reality, it is a consequence of using low-level types.

MyHDL follows a different path, but one that has actually been shown by VHDL in the first place. It has the intbv type, which is an integer-like type whose values can be constrained like in VHDL. However, unlike VHDL, there are no artificial limits on the minimum and maximum values it can take. Moreover, and again unlike VHDL, the type has an indexing and slicing interface to access the representation if required.

The result is that in synthesizable MyHDL, you can basically do arithmetic using integers. Therefore, all issues with signed/unsigned representations simply disappear. The convertor to VHDL infers the required conversions and resizings automatically, thereby automating a cumbersome task.

Signed arithmetic that works

Signed arithmetic in Verilog can be quite confusing. The reason is that when you mix signed and unsigned operands, the operation is done in unsigned mode. This is the opposite of what should be done to get the normally expected results. To avoid this, operands should be explicitly cast to signed.

In MyHDL, these issues do not exist, because you can basically use integers for arithmetic, using the intbv type presented in the previous section. The convertor to Verilog infers the required casts and bit extensions automatically.