Verification using Parrot: A Virtual Machine for Dynamic Languages

Parrot is a virtual machine that is being developed by an open source community to execute dynamic languages. Originally conceived a a re-write of the internals of Perl, it has since blossomed into a system that can support many languges. Although it is still a fair way from completion, it already sports implementations of Python, BASIC and Lua -- in addition to some early experiments with Perl 6.

Why do I believe Parrot is important for ASIC Verification? To answer this question, I draw on two existing technologies: the Verilog PLI, and Pivot, a tool created by a small startup that enables us to write testbenches in Perl.

When comparing Verilog to VHDL, most people acknowlege that Verilog won the HDL language wars of the '90s. I beleive there are two main reasons for this: simplicity, and a well defined extension interface.

Verilog is much simpler than VHDL. However, its simplicity does not equate to lack of ability in the realm of the RTL abstraction. Most designers design using RTL, so they do not require the advanced features offered by VHDL, and were able to realise greater productivity by using a simpler language. Verification teams did feel the pain of using a language whose features for functional abstraction are little better than pure assembly; but they were able to overcome these weaknesses because Verilog has a standard interface, the PLI, that allows us to extend its functionality using C

C is better than Verilog, but is still not a particularly powerful language for created test fixtures for ASIC verification. So many of us Verification Engineers use alternative languages over the PLI. C++, using 'extern "C"', is equally usable as a client of the PLI.

C/C++ are not languages designed for hardware verification. A number of technologies have arisen to rectify this. In the C/C++ world, SystemC is perhaps the most establised. Beyond this, specialised languages known as HVLs (hardware verification languages) have been created. The best known of these are 'E' and Vera. These languages offer 3 main things: connection to an HDL simulation, a constraint solver for random testing, and a run-time framework to track functional coverage. In today's world, even thoug officially "open", these languages are tighly coupled with the tools that implemnt them. Most recently System Verilog has been created as a monolithic language that assimilates the functionality of the HVLs. Some people have sugested that System Verilog bring to verilog those features that made VHDL unweildy when it lost the language wars.

So the majority of the EDA industy has persued the path of creating new language to rectify the lack of power in the original verilog standard (Even SystemC, though in reality a C++ library, is promoted as a language -- it includes a number of macros to make it more familiar to HDL users, and more obscure to C++ users). But one small company, GreenLight, chose a different approach. It produced a simple Perl library that it named "Pivot". Pivot is able to be simple because its users are able to use the full power of Perl and the CPAN library of Perl modules. But Greenlight is able to make a business of this package, because connecting Perl to the PLI is non-trivial, especially if performance is required (which it is). As a user of Pivot, I came to appriciate how Perl made many concepts of a testbench incredibily simple (examples: a scoreboard can be implemented as a hash; a fifo as an array).

The example of Pivot demonstrates the power of so-called "scripting" languages (more generally, "dynamic" languages) in the realm of ASIC Verification. But it also demonstrates the weaknesses of the Perl 5 extension architecture. To achieve their high-performance interface, Greenlight found it necessary to deploy custom-builds of Perl, thus preventing users from taking advantage of the latest releases of Perl. It also caused problems with a number of modules from CPAN. All the effort applied by Greenlight to create their tool produced a single-language solution. Conceptually this is no different to the general EDA approach of new HVL languages.

Parrot has the potential to change all this. The Parrot team have learned the lessons of the Perl extension interfaces to produce a vastly simpler embedding and extending capability. Furthermore, a single connection of the PLI to Parrot will provide the freedom to use any of the languages suported by Parrot. Thus a connection of the PLI to Parrot creates an extension interface in the same spirit as the original PLI: it does not constrain the user to a single "HVL" -- it provides freedom to use almost any languuage.

Finally, because the Parrot team are develping the tools needed to implement many languages on a single engine, the "open-ness" of languages such as E and Vera can truely be tested. Parrot (and especially Perl 6) will make it easy to implement compilers of these languages onto the Parrot core. By eliminating the need to reinvent many wheels, these will provide a foundation upon which the Open Source concept can be applied to the hardware verification world.

A strong foundation for open-source would threaten the EDA industry as it currently exists. This industry is currently in a phase of entrenchment: the creation of "Big" languages like System Verilog may act to raise a barrier to entry against new entrants into the competition. But if parrot can bring the full power of dynamic languages into the field (Perl, Python, Ruby, etc.) then this may make System Verilog irrelevant. It is my hope that this will happen, because an industry that survives by errecting barriers is prone to stagnation. If Parrot can raise the whole playing field above those barries, then everyone should benefit -- ultimately even those big EDA companies who currently resist interoperability. Interoperability, whilst enabling customers to take their business elsewhere, also makes a decision to buy into a company's products much easier. (as a buyer of tools, I often will feel that a tool is good, but the risk of vendor-lockin is to great)

Dave Whipp, 12 October, 2003