VMM recommends defining byte_pack and byte_unpack methods for each transaction descriptor class. Let us first understand exactly how and why these methods are useful.
The figure below depicts the various abstraction layers in a typical VMM-based verification platform. The concept of a transaction is central to VMM and a transaction transcends through all the different layers. Continue reading
Since the payload in many transactions constitutes of multiple data bytes, it is usually represented by a fixed-size or dynamic array. Often there is a requirement to replicate the array (for example in the VMM mandated copy function).
SystemVerilog provides various ways of achieving this end. Often it is done by copying all the elements .... Continue reading
As one starts building a Verification IP, the first task is to identify the various data transactions that the Design Under Test supports. Some of these transactions would be low-level — quite specific to the pin interfaces of the module. For example if the DUT supports I2C interface, it is imperative for the verification IP to have an I2C transaction descriptor class. In addition, on top of the low-level interfaces, higher abstraction level data transactions would often ride. Continue reading
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. Continue reading
