SystemVerilog UVM Tutorial # 1

Digital verification

The digital design verification has been a challenging field and there's a lot which has changed from last 10-15 years in the field of digital design verification. The verification job has got complex and critical for IP/subsystem as well as for SoC.

With Moore's law, we clearly see the complexity has increased many-fold and hence the life of verification engineer has been even more complex while at office and on project :-)

There are more logic to verify hence need of more verification scenario at subsystem or IP level. In the SoC verification context, the key is to fetch what all shall be verified so that the integration of various IP/subsystems are properly verified. The need for the same matter turns into extracting the detailed, exhaustive test scenarios which came from IP and Subsystem level as verification suite.

What is it that ensure verification sanity of SoC verification task -

First of all, Verification is a never ending and like keep expanding the context as the verification engineer gets involved.

Now, In order to create some way to ensure a good signoff for IP/Subsystem verification. The coverage  is such a parameter which shall be used to specify what all shall be covered for IP/Subsystem verification. There are different kind of coverage (typically supported by various toolsets from EDA vendors) -

• Functional coverage - The coverage in terms of features need to be verified.
• Code Coverage - all what shall be covered of RTL code during verification.
• Toggle coverage  - The toggle coverage aims to look at all in/outs at subsystem(or internally) toggling or not.

Verification Environment topology

    The verification environment for any subsystem needs the IP/subsystem's RTL view and the verification IP. There are certain additional requirements to program the Subsystem's registers. Another requirement is to have a memory buffer which can be used to store data which shall be provided to IP or subsystem. This is typically for all the subsystem's which has internal DMAC (or a master interface e.g. AXI, AHB).

Verification environment shall look as follows -

    The verification IP typically designed in Verilog, C and e-language (Cadence proprietary) and for last few years, the OVM/UVM methodology has taken the complete space. More and more Verification IPs are modeled and designed in SV/UVM.

What is UVM ?

     The Universal Verification Methodology (UVM) is a standardized methodology for verifying integrated circuit designs. UVM is derived mainly from the OVM (Open Verification Methodology) which was, to a large part, based on the eRM (e Reuse Methodology) for the e Verification Language developed by Verisity Design in 2001. The UVM class library brings much automation to the SystemVerilog language such as sequences and data automation features (packing, copy, compare) etc., and unlike the previous methodologies developed independently by the simulator vendors, is an Accellera standard with support from multiple vendors: Aldec, Cadence, Mentor, and Synopsys.

Reference

So the key components as seen in the image are -

• Driver

    The driver in verification IP is key component which is used to generate the data towards the DUT. In fact, the driver is responsible for taking the data from other component i.e. Sequencer in higher abstracted data packets and generates the data traffic on the virtual I/F.

• Monitor

    The monitor is the component which is responsible for collecting all data coming on the virtual I/F. It could have a transactor to packetize data for a higher abstraction level(Typically, it could be wrapped in a class).

• Sequencer

    The sequencer's main functions:

• DUT and the verification environment initialized through sequencer.
• configuring and the scenario generation with the sequences for the verification environment and DUV

• Sequences

    The sequences are the key elements which are responsible to play through Sequencer. The sequence is the most primitive for the stimuli generation.

• Scoreboard

    The scoreboard is one of the most important component. It is responsible to confirm whether the test pass or fail. The Scoreboard implementation varies a lot depending on the verification environment. Overall, it's the comparison between the reference (already available or extracted) and the results of the simulation.