1. Chapter 11 System-Level Verification Issues

2. The Importance of Verification Verifying at the system level is the last opportunity to find errors before the design is committed to silicon For many teams, Verification takes 50 to 80% of the overall design effort For SoC design, verification must be an integral part of the design process from the start and it cannot be an afterthought to the design process Successful system-level verification factors Quality of the verification plan Quality and abstraction level of the of the models and testbenchs used Quality and performance of the verification tools Robustness of the individual predesigned blocks

3. The Verification Strategy Divide-and-conquer approach Verify that the leaf nodes of the design hierarchy are functionally correct as stand-alone units Verify that the interfaces between blocks are functionally correct Run a set of increasingly complex applications on the full chip Prototype the full chip and run a full set of application s/w for final verification Decide when it is appropriate to release the chip to production

4. Block Level Verification For large SoC designs, block-level verification is prerequisite Bugs are much easier to find at the block level rather than chip level Exception to block level verification The design team may well decide not to produce prototypes of single-use blocks before they are integrated into the chip The first version of the chip must be considered a prototype.

5. Interface Verification Chip verification with interface verification Knowing that the individual blocks have been robustly verified, chip-level verification consists of verifying the interfaces and interaction between the blocks Inter-block interfaces usually have a regular structure Transaction Verification Data and Behavioral Verification Standardized Interfaces

6. Transaction verifiaction Transaction types that can occur at each interface and testing each one. A simple, Regular communication architecture between blocks can reduce the system verification effort Transaction checking Bus monitor : coded behaviorally and provide very good simulation performance. Observability, controllability Point-to-point interfaces : build some simple transaction checking into the interface module of each block

7. Block1 RTL Interface Block1 RTL Interface Block2 RTL Interface Block2 RTL Interface Block3 RTL Interface Block3 RTL Interface Block4 RTL Interface Block4 RTL Interface System verification using interface testing Block4 Block1 RTL Interface Block4 Block1 RTL Interface Bus Transaction Monitor Block4 Block1 RTL Interface Block4 Block1 RTL Interface

8. Data or Behavioral Verification It is necessary to verify that the block behaves correctly for all values of data but it is impossible We can construct test cases either from our knowledge of the system of by random generation Data sequences that the designer expected the block to receive can occur in the actual system to which the block does not respond correctly Another method for dealing with the problem is to design a checker into the block interface itself. This approach bas been used effectively in high- reliability system designs.

9. Functional Verification(1) The ultimate goal of this aspect of verification is to try to test the system as it will actually be used. However, conventional simulation is simply not fast enough to execute the millions of vectors required to run even the smallest fragments of application code Two basic approaches to addressing this problem Increase the level of abstraction Use specialized hardware for performing verification

10. Canonical SoC Design PROCESSOR PERIPHERALS MEMORY CONTROLLER MEMORY I/O INTERFACE DATA TRANSFORMATION I/O INTERFACE SYSTEM BUS

11. Functional Verification(2) The key features of the verification environment The full RTL model is used as the simulation model for most of the functional blocks Behavioral of ISA models may be used for memory and the microprocessor Bus functional models and monitors are used to generate and check transaction with the communication block It is possible to generate real application code for the processor and run it on the simulation model Behavioral models are now substituted for the memory and microprocessor Using C/C++ models for both the processor and memory dramatically improves simulation speed over full RTL simulation

12. System verification environment Communication Bus functional Model(RTL) Sequence Generator/ analyzer Communication Bus functional Model(RTL) I/O Interface (RTL) Data Transformation (RTL) I/O Interface (RTL) Bus Monitor Application software/ Drivers/RTOS Complier RTL interface Memory C/C++ Other Peripherals (RTL) Processor C/C++ Processor C/C++ CHIP

13. Application-Based Verification About 90% of ASIC designs work right the first time, although only about 50% work right the first time in the system because most ASIC design teams do not do system-level simulation Running significant amounts of real application code is the only way to reach this level of confidence in an SoC design. The available options for rapid prototyping include FPGA or LPGA prototyping Emulation-based testing Real silicon prototyping

14. FPGA and LPGA Prototyping For small designs FPGA Reprogrammable Allowing rapid turnaround of bug fixes LPGA higher gate counts Faster clock speed For prototype of a single large chip Use multiple FPGAs to build a prototype But it is impossible to modify quickly when a bug fix requires repartitioning of the design between devices

15. Emulation Based Testing A better alternative to using a collection of FPGAs for rapid prototyping of large chips Programmable interconnect Fixed board design Relatively large gate counts Special memory Processor support Emulation can provide excellent performance for large-chip verification if the entire design can be placed in the emulation engine itself

16. Silicon Prototyping If an Soc Design is too large for upper cases then building a real silicon prototype may be the best option. Reasonable set of criteria The bug rate form simulation testing should have peaked and be on its way down. The time to determine that a bug exists should be much greater than the time to fix it The cost of fabricating and testing the chip is on the same order The scenario we want to avoid is building a prototyping only to find a critical bug that prevents any useful debug of the prototype Help facilitate debug of this initial prototype Good debug structures for controlling and observing the system The ability to selectively rest individual blocks in the design The ability to selectively disable various blocks to prevent bugs in these blocks form affecting operation of the rest of the system

17. Gate-Level Verification The final gate-level netlist must be verified for both correct functionality and for timing Sign-Off Simulation Formal Verification Gate-Level Simulation with Unit-Delay Timing Gate-Level Simulation with Full timing

18. Sign-Off Simulation(1) RTL sign-off, where no gate-level simulation is performed, is becoming increasingly common. Problems Full timing simulation of million-gate ASIC is not possible with out very expensive H/W accelerators, and it is very slow Parallel vectors have very low fault coverage Parallel vectors do not exercise all the critical timing paths Different paradigm Verification that synthesis has generated a correct netlist and that subseqeunt operations such as scan and clock insertion have not changed circuit functionality Verification that the chip, when fabricated, will meet timing A manufacturing test that verifies that the chip is free of manufacturing defects

19. Sign-Off Simulation(2) The Current methodology uses separate approaches to address each issue Formal verification is used to verify correspondence between the RTL and final netlist Static timing analysis is used to verify timing Some gate-level simulation, either unit-delay or full timing, is used to complement formal verification and static timing analysis Full scan plus BIST provides a complete manufacturing test for functionlity.

20. Formal Verification Formal verification uses mathematical techniques to prove the equivalence of two representations of the circuit To check equivalence between the original RTL The synthesized netlist The netlist after test logic is inserted The netlist after clock tree insertion and layout. Hand edits Benefit of formal verification Allows the RTL to remain the golden refrence for the design, regardless of modifications made to the final netlist

21. Gate-Level Simulation with Unit-Delay Timing Unit-delay simulation involves performing gate-level simulation with unit delay for each gate. Unit-delay simulations can be used to verify The chip initializes properly The gate implementation functionally matches the RTL description Gate simulation complements formal verification Gate simulation is important for verifying initialization because gate-level simulation handles propagation of unknown or uninitialized states more accurately than RTL simulation

22. Gate-Level Simulation with Full timing Full-timing simulation on large chips is very slow Used only where absolutely necessary This technique is useful for validating asynchronous logic Embedded asynchronous RAM interfaces single-cycle timing exceptions These tests should be run with the back- annotated timing information from the place and route tools, and run with hazards enabled.