Efficient Methodology of Sampling UVM RAL During Simulation for SoC Functional Coverage
1 like1,041 views
Paper presented at Microprocessor/ SoC Test, Security & Verification (MTV 18 ) C onference, Dcemeber 10 , 2018 , Austin, USA © 2018. Paper URL: https://ieeexplore.ieee.org/document/8746049
Ad
More Related Content
What's hot (20)
Similar to Efficient Methodology of Sampling UVM RAL During Simulation for SoC Functional Coverage (20)
Ad
More from Sameh El-Ashry (8)
Ad
Recently uploaded (20)
Efficient Methodology of Sampling UVM RAL During Simulation for SoC Functional Coverage
- 1. Efficient Methodology of Sampling UVM RAL during Simulation for SoC Functional Coverage Authors Sameh El-Ashry, [email protected] Ahmed Adel, [email protected] Microprocessor/SoC Test, Security & Verification (MTV18) Conference, Dcemeber 10, 2018, Austin, USA © 2018
- 2. Outline • Motivation. • Introduction. • The Proposed UVM RAL Generation Flow. • The Proposed UVM RAL Backdoor. • Conclusions. 2
- 3. Motivation 3 Why? How? • Why Functional Coverage? • We need good coverage model. • Sampling problem in bad coverage model. • Ex: Sampling on the clock is dangerous for simulation performance. • Sampling on the change of the register. • Efficient backdoor technique is proposed using RAL model.
- 4. Motivation2 • Register files verification represent critical part of any digital design verification process. • One of the most powerful ways to model memories and register files is using Register Abstraction Layer (RAL) which is part of the UVM. • This paper will go through the process of UVM Register model generation with its coverage model using Synopsys tools. 4
- 5. Motivation3 • We propose an efficient and automated methodology of functional coverage UVM- based verification environment supported by RAL model, backdoor access and how to automatically generate it starting from IP-XACT model till producing the UVM RAL model. • The proposed methodology has strong flexibility in frequent design specification changes. • The proposed functional coverage technique is applied to beat performance degradation and enhance the simulation. 5
- 7. Register Abstraction Layer (RAL) • Verification engineers use register models to ease the stimulus generation and the functional checking. • A register model consists of a set of register definitions, register instances clustered under a register block and their address mappings into Design Under Test's (DUT) address space. • RAL allows modeling and verification of hardware registers and memory blocks, the UVM register layer provides read() or write() tasks that can be called from a UVM sequence. 7
- 8. UVM Register Library Features 8 • Read and write for the registers and the memories as part of the normal operation. • Modeling registers, memory blocks and analyze the register activity. • Checking the DUT registers and memories against a shadow device (with shadow registers) at the scoreboard. • Collect coverage on the registers that are created at the RAL model (point to improve). • Initialize the DUT registers and memories. • Randomize the contents of DUT registers and memories.
- 9. The Proposed UVM RAL Generation Flow • The UVM RAL Generation Flow • The Proposed Generic, Scalable, and Configurable UVM Architecture 9
- 10. The UVM RAL Generation Flow • UVM provides mapping of register content of DUT, a layer for accessing register, and memory locations within DUT which is called as RAL. • Once a description of the available registers and memories in a design is available, ralgen tool proposed by Synopsys can automatically generate the UVM RAL for these registers. 10
- 11. The UVM RAL Generation Flow2 11 • Figure describes the flow of the UVM register model generation starting from the Excel spreadsheet register file, the generating of Register Abstraction Layer File (RALF) format. Register File Excel Format IP-XACT Schema Format RALF Model UVM Register Model UVM Register Model Generation Flow ralgen Tool ralgen Tool User Script
- 12. The Proposed UVM Architecture 12 • The designed testbench uses a UVM methodology and constrained random verification techniques. • The goal is to meet the expected functional coverage metrics, and verifying the digital hardware parts in System-on-Chip (SoC) ,and wireless systems.
- 13. The Proposed UVM Architecture2 13 • The verification environment was designed to verify a network consisting of up to four PHYs (DUTs) and can be configured to support extra DUTs as shown in Figure. • One RAL model is implemented, although we created instances from the RAL model for each peer.
- 14. The Proposed Generic UVM Architecture3 14 • A shared functional coverage model is implemented for all DUTs as some scenarios may happen at the transmitter side, others scenarios may happen at the receiver side.
- 15. The Proposed UVM Architecture4 15 • One coverage database is needed for the network so the total coverage percentage is easily merged by automatic way due to the shared functional coverage model. • A structured testbench is built using classes based on UVM supported by UVM RAL model and RAL backdoor access.
- 16. The Proposed UVM Architecture5 16 • Another effect of using the RAL model is that the total coverage closure time is reduced due to an automatic integration for the functional coverage and the covergroups results for all DUT’s instances. • The automatic integration is achieved by mapping all the DUT’s instances to the same covergroups at the RAL model.
- 17. The Proposed UVM Architecture6 17 • There is one more important thing to simulation performance. • The number of calling the sample coverage task badly affects simulation performance next to the size of design. • Thus, the concept of backdoor for specific data path has been applied to register modeling.
- 18. The Proposed UVM RAL Backdoor • Conventional UVM Backdoor classes • Modified UVM Backdoor classes for Coverage Sampling • Proposed Backdoor Sampling Technique for Checking Proposes 18
- 19. Backdoor Access 19 • Front-door access uses the same bus interface for observing operations. This is commonly used in simulation-based register verification because it does not require an additional interface for observation. • Back-door access uses a different interface for observation – usually direct access to registers. • Backdoor access enables efficient observation, but requires the use of an additional interface. • Backdoor improves the efficiency of verifying registers as it can access register locations with little or no simulation time.
- 20. EDA Vendors RAL Generators 20 • The input specification of a register model such as IPXACT, System RDL, Excel file or word file (typically in IPXACT or RALF in our case study) contains all of the necessary information to generate the UVM register model leveraging the UVM base class library. Commercial or open source generators ralgen tool IP_XACT System RDL Excel file Word file UVM Classes RAL Registers Backdoor read/Write Tasks Backdoor Classes for Registers Model Coverage UVM Register Model
- 21. Conventional UVM Backdoor classes 21 • There is a lack of literature discussing the backdoor technique using the hierarchical HDL path based backdoors. • We discuss the backdoor mechanism and the challenges associated with it. • In this mechanism, register constructs are accessed using the Verilog style cross- module references. • This would be relatively less intensive with regards to simulation performance as the HDL paths are all resolved at the compile time.
- 22. Generated UVM RAL read/write backdoor tasks 22 • The interface would contain tasks defined within it to access the constructs that are used to model registers in the RTL of the DUT.
- 23. Generated UVM RAL backdoor classes 23 • The usage of the backdoor classes and the signatures will not change which will allow existing RTL code to work seamlessly with the newly generated model.
- 24. Modified UVM RAL interface with wait for change tasks 24 • When Active Monitoring code is desired, the following generated classes and tasks are modified additionally as shown in Figure.
- 25. Modified UVM RAL backdoor classes 25 • The additional code in the interface file would be as shown: Sampling event to use it in coverage sampling at the base_test to achieve high performance coverage/simulation.
- 26. Modified UVM RAL backdoor interface. 26
- 27. Functional Coverage Model Generation 27 • The coverage model is created at the proposed UVM environment by our scripts to generate covergroups for the desired registers only and avoid the auto generated coverage model from the ralgen tool for all registers that are created at the RAL model so that a higher coverage simulation performance is achieved. ralgen tool IP_XACT UVM Classes RAL Registers Backdoor read/Write Tasks (will be modified) Backdoor Classes for Registers (will be modified) RAL with Model Coverage UVM Register Model User Script bins_reg_1.txt bins_reg_2.txt bins_reg_N.txt
- 28. Sampling of the coverage model 28 • The sampling of the coverage model for coverage closure is happening at the UVM test layer and is controlled using the event trigger for high simulation performance as shown in Figure.
- 29. Sampling for Scoreboard Checking 29 • The scoreboard peeks registers to use the register’s value in a comparison process, the scoreboard may pull up on the change of the register based on an event that is triggered from the backdoor classes as shown in Figure.
- 30. Conclusions • Commercial or open source tools support the automatic generation for the functional coverage model and the covergroups for all implemented registers at the RAL model. • The auto-generated covergroups are not the most efficient coverage method as the verification engineers may need to exclude some undesirable registers from the final coverage report based on the verification coverage plan that is prepared at the starting of the project. • The coverage sampling of undesirable registers may lead to low simulation performance, a new efficient methodology is proposed for the coverage sampling based on RAL backdoor access to achieve the highest simulation performance. • The automated methodology has strong flexibility and high-level maintainability upon frequent specification changes. 30
- 31. 31 Questions?
- 32. Thank You