Assertions and Constrained Random

Last week, I went to the closing symposium of the Code review process for hardware designers.

We heard some interesting technical talks on constrained random and coverage driven verification in SystemC. SystemC has a set of library classes and methods that allow users to define constraints on the input parameters of a device under test.

There was also a presentation on various systems for inline assertions:

I especially liked OVL because it is implemented as standard VHDL/Verilog. While it has serious disadvantages (you need a lot of text for simple assertions), the one big advantage is that everybody can start using OVL right now. You just need to downlod the library from the Accellera site, and start using it in your designs.

Hearing these two talks back-to-back, I started wondering about which features should be built into a language and which features should be provided in a library.

Computer language design

Many software languages (such as C and Java) have a very simple language definition, with few syntactic constructs, but most of the power of the language comes from the standard library and third-party libraries, native to the programming language. C has its ISO/ANSI libraries, and tons of third-party libraries. Java has the standard libraries provided by Sun (or should I say Oracle) and numerous libraries provided by other parties such as the Apache Software Foundation.

Putting your key functionality in libraries has two major advantages. First, the language itself remains easy. Easy to learn and easy to implement. Every undergrad computer science student can write a working C compiler, and some will actually do so in their courses. If it is easy (i.e. cheap) to build a new compiler from scratch, the economy of your programming language changes dramatically. Small companies or undergrads can easily make new viable tools that are capable of processing the entire language. This boosts innovation and lowers the price for tooling, which is exactly what you see in the software world today.

And second, if major functionality is added through libraries, there is no specific hurdle for anybody that wants to add functionality. Everybody can create a new library for their favorite language, without any modifications to their build tools (i.e. to the compiler). These new libraries can be shared, licensed, sold or (when many people agree on their added value) maybe even standardized.

EDA and its languages

In the EDA world, people have been doing things backwards for the last two decades. Languages like VHDL and SystemVerilog have clearly been designed (or rather: negotiated) in standards committees. These languages have a large amount of syntactic constructs, many of which are inconsistent with other constructs. While few hardware designers will admit to this, hardly anybody knows the entire syntax of VHDL (let alone SystemVerilog) by heart. People just know the safe subset they use in their designs.

On the side of libraries, traditional HDL design also makes the wrong choices. VHDL only has two files in its standard library and about half a dozen in its IEEE library, which is also standardized. These standard libraries take care of primitive datatypes (basically integers, bits and arrays of bits) and some rudimentary I/O.

As a result of these complex languages, the barrier of entry for new tool vendors is higher than it should be. Good thing for the big three (or should I say four?), but not for smaller EDA companies, not for the FPGA vendors and not for hardware designers.

Cheap parsers

So what would an Ideal World look like? In an ideal world, the lingua franca of hardware design would be easy to understand for man and for machine. This means: easy to learn, easy to type and easy re-implement. From that language, each may implement their own extensions, preferably as libraries or as preprocessor steps, not requiring any change of the fundamental grammar or compiler. While the accepted linguae francae (VHDL and Verilog) are far to complex to be ideal candidates, there are some good examples of "extensions" to these languages.

A nice example of a library that enhances the functionality of VHDL is the Open Verification Library, mentioned earlier. Another example is the Freesics package, which enhances the I/O capabilities of VHDL.

Most newly designed hardware description languages do have their own simulator, but they do not have their own synthesizer that generates net lists. As an example, MyHDL, built on top of the Python core, simulates as a Python script and has a functionality to generate both Verilog and VHDL entities for further processing.

The EDA industry has made some bad choices in the past, which inhibit innovation. As long as industrial quality (i.e. not prototype quality) parsers for the common hardware description languages cost several hundred thousand dollars, too few companies will join us in building tomorrow's EDA tools.