The API-based verification approach can be adopted for any chip, but it makes most sense for designs where chip configuration is done first.
With little modification based on Design Verification need, the API-based verification approach can be adopted for any chip, though it makes most sense for designs where chip configuration is done first, after which triggers are generated to start executing the scenario using the programmed values. Examples here include processor-based designs, where memory is initialised with desired opcodes/operands, and then execution triggered by writing to the same set of registers.
Verification using various methodologies has become popular as it saves VE development time. Even more time can be saved if we think of possible reuse of various VE components when defining the VE architecture. The reuse of VE components at different levels is crucial to time-saving during design verification, with applications comprising block, cluster/subsystem, chip or SoC levels, and can also result in huge time savings during post-silicon lab validation.
This article talks about an API (Application Program Interface) based verification approach that can be adopted for a whole segment of ASIC applications.
Design blocks B1, B2 and B3 of the example SoC in Figure 1 illustrates blocks are interconnected using unique interfaces and each one of them is to be verified independently at the block level followed by cluster and chip levels.
Figure 1: Example major blocks of SoC design.
Figure 2: Verification testbench for block B3.
In Figure 2:
api_top_ is a UVM component having instances of all block level API classes.
api_b3.sv is a UVM component containing all required APIs to program B3 design block through host interface driver.
api_b3_b1.sv is a UVM component having API wrappers that pass the programming details targeted for block B1 to B1 driver component by calling respective driver APIs.
api_b3_b2.sv is a UVM component having API wrappers that pass the programming details targeted for block B2 to B2 driver component by calling respective driver APIs.
B1 DRV is a driver for B1 interface signals.
B2 DRV is a driver for B2 interface signals.
To verify block B3, the VE should mimic the functionality of driving meaningful traffic on all the interfaces of B3 through which it talks to blocks B1, B2 and the host. This calls on driver B1 to drive interface B1, driver B2 to drive interface B2 and the Host Interface driver to program B3 design block.
Furthermore, test sequences execute sequences that constrain transaction classes of type B1, B2 and B3 and pass them on to their respective APIs. These transaction classes have all the required control knobs or fields to program block B1, B2 and B3, considering the design internals. Now, while doing B3 block level verification, since we don’t have actual design blocks B1 and B2, corresponding api_b3_b1/2.sv classes call on the respective driver’s APIs that program them to drive the B1/B2 interfaces. Through a host interface and using B3 transaction details, the host driver programs design block B3.
Though it’s not shown in the sketch, other components like interface monitors and data checkers are also present here, sitting on major interfaces to monitor design signals for interface activity checks and for data integrity check of data flow as per the predicted results from reference models. A similar API-based approach can be followed to verify other blocks which have some other interfaces as per their adjacent surrounding blocks.
Figure 3 shows how the same environment looks like when we move one step up to verify the B3 block at cluster level, having B1, B2 and B3 blocks in the design.
Figure 3: Testbench for B3 block verification at the cluster level.
In Figure 3:
api_b1.sv is a UVM component containing all required APIs to program B1 design block through host interface driver.
api_b2.sv is a UVM component containing all required APIs to program B2 design block through host interface driver.
We can see that the B1 and B2 drivers are no longer required here as the real design blocks B1 and B2 are present to fill them while they interact with block B3. Instead of calling the B1/B2 drivers’ APIs, api_b3_b1 and api_b3_b2 calls respective APIs in api_b1 and api_b2 components.
The api_b1 and api_b2, through the host interface, programs B1 and B2. Thus, the test sequences and entire VE remain the same but the scope of verification for B3 gets changed to one step up.
Like we have api_b3 developed for verification of the B3 block, api_b1 and api_b2 are similar ones which are developed and used for block level verification of blocks B1 and B2. No extra time is needed to develop them. They are just reused as-is. A similar approach can be adopted while moving one step up to verify the design at chip level.
First published by EDN.
Bipin Patel is a senior member of the technical staff and Manzil Shah is a technical manager, both at eInfochips.