Hardware development is similar to software development when it comes to languages. There are many of them, each one with its own pros and cons, and when I start a project I must choose one, for the right or for the wrong reasons:
- It has the right set of functionalities for what I want to do
- I know this language so I must use it to complete something quickly
- I already have a library in this language
- There are free tools for this language
- This language needs a proprietary tool, but the tool quality is worth the price
- The environment we have in place is designed for this language
- We need support, and that well-known company sells good support for this language
A good place to find information about the different hardware description languages is ASIC World, a very complete portal with tutorials, examples and links. Here I’m giving a subjective take on some languages that I encountered. (The following list of languages is a glimpse on what’s available: it is not meant to be a complete reference)
This language is the basis for hardware description: it’s simple, mature, widespread in the industry world and it’s regulated by a standard group. I think it is the best language to start developing hardware, because the learning curve of the language syntax is not very steep, and the brain can concentrate on other problems. The most difficult barriers when starting to design hardware are: understanding concurrency, and understanding the synchronous sequential logic (registers and clocks). These concepts can be grasped by using the opposite mindset with respect to sequential programming; for this reason it is particularly difficult for a software programmer to migrate to the hardware world.
VHDL is much like Verilog, in terms of low-level hardware description. In addition it puts the emphasis on abstraction in terms of libraries (for example the handling of integer values), and on behavioral modeling. It is also possible to define types and “records”, that are similar to the ANSI C “struct”. Together with Verilog, they describe the great majority of hardware components.
SystemC is a way to use C++ to model hardware. The definition of objects in C++ is similar to the description of hardware modules, and similar is also the encapsulation of objects inside other objects. SystemC consists of a library of classes that can be used to model hardware, and a runtime that performs simulations. A SystemC design can be compiled using a C++ compiler such as the one in Visual Studio or GNU g++, and the resulting simulation is very fast. Moreover, running a simulation on a multi-core machine is very efficient, because it is largely based on threads to model concurrency [Edit: the current SystemC simulation kernels are single-threaded, work has been done to create an experimental kernel expoiting Simmetric MultiProcessing].
The e language is impossible to Google. For this reason, it is better to associate it with the proprietary tool that interprets it: Specman. There are other tools that can deal with e, but historically and commercially Specman is the most fit. This language is based on extensions: for example if you have a library function that prints “Hello World!” you can extend it to print also “Especially hello girls!”. This language can also model a random behavior: you can define a module containing an integer, and write a constraint that keeps the integer in the range 0 to 100; during the simulation the module instance will contain an integer with a specific value that satisfies all the constraints. This feature is useful to verify an hardware block by giving it many random inputs that have specific rules (data packets, control messages…). The syntax is quite clear, but the concepts of aspect-oriented programming are not immediate to grasp.
IP-XACT is not really a language but a group of specifications to write an XML description of a hardware design. It has been created by the Spirit Consortium and is in active development. IP-XACT was born to cope with real world problems of the hardware industry from design to implementation.
Those problems for example are:
- how should I deliver my hardware block to other companies?
- how can I keep synchronized: hardware development, documentation and software code?
- how do I integrate hardware blocks from different vendors, written in different languages?
- how can I connect different blocks to design my system top-down?
- how should I keep track of information associated with the code, for example the tools used to compile?
IP-XACT offers a framework to solve these problems using XML descriptions as the common denominator. Ideally, this is how it should work out:
Suppose you’re designing a system with a CPU and a SATA controller. You get the CPU from a vendor and the SATA from another, both ship their product with it an IP-XACT description. You use an IP-XACT enabled graphical tool to import the two blocks into your project and connect them (using your mouse) to the bus, to the memory and the other peripherals of your system. You then click a button to generate ANSI C code to access SATA using the IP-XACT description of its registers; you compile it using the software indicated in the IP-XACT files. You then elaborate the design for simulation using the tool information in the IP-XACT, and run the simulation.
The key to make this work-flow possible is to have all tools with IP-XACT support, and this is gradually becoming the case. There is a shortage of open source tools though, apart from a useful Eclipse plugin.
MyHDL is an open source tool (hosted on sourceforge) that allows you to describe hardware using the Python language. Establishing a new language is not straightforward; MyHDL renders the transition easy in many ways:
- it is based on an existing well-known and proven language syntax (Python)
- it implements code generation to Verilog and VHDL
- it allows mixed simulation of MyHDL and Verilog (through VPI modules)
Moreover, MyHDL associates the concept of verification in the hardware world with the concept of unit testing in the software world. While doing so, it exploits the existing Python modules for unit testing, that are widely used for entirely different projects such as web services. Hardware verification is the most time-consuming task in the design flow, so anything that can ease the job is well accepted.
low-level description and verification