An approach to accelerate UVM based verification environment

Transcription

1 An approach to accelerate UVM based verification environment Sachish Dhar DWIVEDI/Ravi Prakash GUPTA Hardware Emulation and Verification Solutions ST Microelectronics Pvt Ltd

2 Outline Challenges in SoC Verification A common solution: Co-emulation Conclusions

3 Challenges in SoC Verification In the past: Register map tests IP data-flow integration tests (one IP at a time) Connectivity tests (interrupt, configuration signals, etc...) We still have to do these, but also: Multi-IP stress tests (groups of IPs exchanging data simultaneously) Performance assessment with realistic application scenarios More complex coverage models (e.g.: ACE bus transactions) Interconnect scoreboards Low-power features System-level features verification (security, debug/trace, etc.)

4 Issues Designer needs to: run benchmarks on lots of different system configurations Verification engineer needs to: run a growing number of ever longer tests They both need: performance Facing all these challenges only in simulation is not feasible Black boxing some IPs can help, but only to a limited extent

5 Solution Focus on a single comprehensive verification environment Support for performance measurements within traditional functional verification environments Boost the simulations UVM based Co-Emulation Environment

6 What is Co-Emulation? It is a technique that allows the synthesizable portion of the design to run on an emulator......while having the rest of the verification environment running on a traditional HDL simulator on a workstation Verification Environment on HDL simulator SCEMI 2.0

7 Co-Emulation benefits Easiness of design mapping no need of a user intervention to partition the design Complete visibility of all the internal signals of the design Equivalent to the debug capability provided by the RTL simulator Unique verification environment smooth path from simulation to emulation Efficient usage of an emulator Regressions instead of interactive usage mode Enable simulation of modern complex SoCs Performance analysis on modern interconnect is currently challenging

8 Co-emulation Partitioning Separation Between HDL (synthesizable) and HVL (nonsynthesizable) portion Agent VIP Sequencer Monitor proxy Driver proxy SCE-MI I/F Monitor BFM Driver BFM RTL DESIGN

9 UVM architecture in simulation

10 Why Dual Top mechanism? Only DUT can be mapped on board Interface also can t be mapped on board (??) Even if interface gets mapped on board communication between HDL and HVL will become a bottleneck. Driver item over interface is non-static (against synthesis!!) So, requirement becomes to have a dual top architecture (hvl_top & hdl_top) and both will communicate at transaction level.

11 UVM Architecture in Acceleration Two tops communicate through communication channel (SCE-MI or DPI or SV_connect) All Time consuming codes should be moved to HDL Side. Clocks/Reset used by the DUT and BFMs should be generated within the hdl_top hierarchy Only UVM Topology related code remains in Software Side. The testbench should not access individual signals in the DUT.

12 Conclusions Co-Emulation with UVM-based environment is a viable and powerful solution EDA vendor solution for Co-emulation is rapidly maturing from systemc based environments to UVM-based Topics that need to be address API functions to access DDR content in Co-emulation Common methodology to manage PHY True reusable PLL models Solutions to enable SW-debugging in Co-emulation