This document discusses system-level verification issues for system-on-chip (SoC) designs. It emphasizes that verification must be an integral part of the design process from the start. It recommends a divide-and-conquer approach to verification, starting with block-level verification before integrating blocks and verifying interfaces. It describes various strategies for functional verification including increasing abstraction, specialized hardware, and application-based verification using prototypes. It also discusses gate-level verification including formal verification, simulation with unit delay, and full timing simulation.
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
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
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 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.
