When you start verifying a module in SystemVerilog you work in terms of transactions. Even in a very nicely thought out Verilog based verification environment, it would be very difficult to work in terms of transactions.
And so you use SystemVerilog for verification. You feel enabled. From the very start of building verification infrastructure, you work at a higher abstraction level. Verification libraries (VMM and OVM) provide a generic verification platform which eases the effort you would have spent creating your verification infrastructure.
As you starts ramping on VMM/OVM based ASIC verification, you soon start missing the standard library. Well, SystemVerilog surely does provide a wealth of data-structures and containers (dynamic arrays, deque etc) — what I am talking about here, is the missing library of algorithms.
Most programming languages — C++, Haskell, Fortran, Java or the scripting languages like Python, Perl, TCL etc — all have wealth of commercial and free libraries. In fact languages like C++ are evolving more in the library space than by adding more constructs to the core language itself. Even languages with a more conservative stance — like scheme — now come with a standard library.
Would SystemVerilog ever have its own standard library of algorithms? Would we ever have the luxury of picking up algorithms like CRC, or DSP algorithms like FFT directly from an SV library? I do not think this is going to happen anytime soon.
Does it mean that we have to code all the algorithms ourselves whenever we are writing a behavioral model or even a stimulus generator? Does it mean that algorithms like CRC are going to be coded (and debugged) again and again on each project?
I think the conceptualizers and designers of SystemVerilog had DPI in mind when they left this space wide open. Unfortunately, many verification engineers ignore the Direct Programming Interface. Most use it with refrain and only when they are forced to.
In my next post, I will discuss implementation of an ATM Cell descriptor class. Later we will implement the CRC HEC for the ATM Cell header using DPI.
