chapter 11 system-level verification issues. the importance of verification verifying at the system...
DESCRIPTION
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 productionTRANSCRIPT
Chapter 11 System-Level Verification Issues
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 testbenc
hs used Quality and performance of the verification tools Robustness of the individual predesigned blocks
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
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 prot
otypes of single-use blocks before they are integrated into the chip
The first version of the chip must be considered a prototype.
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
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 go
od simulation performance. Observability, controllability
Point-to-point interfaces : build some simple transaction checking into the interface module of each block
Block1Block1
RTLInterface
Block1RTL
Interface Block2
Block2RTL
Interface
Block2RTL
Interface
Block3Block3
RTLInterface
Block3RTL
Interface Block4
Block4RTL
Interface
Block4RTL
Interface
System verification using interface testing
Block4
Block1 RTLInterface
Block4
Block1 RTLInterface
BusTransaction
Monitor
Block4
Block1 RTLInterface
Block4
Block1 RTLInterface
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.
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
Canonical SoC Design
PROCESSOR
PERIPHERALS
MEMORYCONTROLLER MEMORY
I/OINTERFACE
DATATRANSFORMATION
I/OINTERFACE
SYSTEM BUS
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
System verification environment
CommunicationBus functional
Model(RTL)
SequenceGenerator/analyzer
CommunicationBus functional
Model(RTL)
I/O Interface(RTL)
DataTransformation
(RTL)I/O Interface
(RTL)
BusMonitor
Application software/Drivers/RTOS Complier
RTL interface RTL interface
MemoryC/C++
OtherPeripherals
(RTL)
ProcessorC/C++
ProcessorC/C++
CHIP
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
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 r
equires repartitioning of the design between devices
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
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
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
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 o
ut 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 t
hat 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 manuf
acturing defects
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 ti
ming, is used to complement formal verification and static timing analysis
Full scan plus BIST provides a complete manufacturing test for functionlity.
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, reg
ardless of modifications made to the final netlist
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 descripti
on Gate simulation complements formal verification Gate simulation is important for verifying initialization bec
ause gate-level simulation handles propagation of unknown or uninitialized states more accurately than RTL simulation
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.