Anda di halaman 1dari 14

2

Agenda
r Why Verification ?
r Verification Alternatives
r Languages for System Modeling and Verification
r Verification with Progressive Refinement
r SoC Verification
r Concluding Remarks
3
Trend of Verification Effort in the Design
r Verification portion of design increases to anywhere from
50 to 80% of total development effort for the design.
Code Verify ( 30 ~ 40% ) Synthesis P&R
Code Verify ( 50 ~ 80% ) Synthesis P&R
1996
300K gates
2000
1M SoC
Verification methodology manual, 2000-
TransEDA
4
Percentage of Total Flaws
r About 50% of flaws are functional flaws.
o Need verification method to fix logical & functional flaws
From Mentor presentation material, 2003
CIocking
5%
Race
5%
Power
4%
Other
9%
YieId
7%
Noi se
12%
SIow Path
13%
LogicaI/
FunctionaI
45%
5
r Another recent independent study showed that more
than half of all chips require one or more re-spins,
and that functional errors were found in 74% of these
re-spins.
r With increasing chip complexity, this situation could
worsen.
r Who can afford that with >= 1M Dollar NRE cost?
6
Bug Fixing Cost in Time
r Cost of fixing a bug/ problem increases as design
progresses.
o Need verification method at early design stage
Verification methodology manual, 2000 TransEDA
Behavioral
Design
RTL
Design
Gate Level
Design
Device
Production
Cost of
Fixing
a Problem
8
Completion Metrics: How do we know when
the verification is done?
r Emotionally, or ntuitively;
o Out of money? Exhausted?
o Compet ition's product is there.
o Software people are happy with your hardware.
o There have been no bugs reported for two weeks.
r More rigorous criteria;
o All tests passed
o Test Plan Coverage
o Functional Coverage
o Code Coverage
o Bug Rates have flattened toward bottom.
9
Verification Challenges
r Specification or Operating Environment is
ncomplete/ Open-Ended. (Verification metric is never
complete like last-minute ECO.)
r The Day before Yesterday's tool for Today's Design.
r Design productivity grows faster than Verification
productivity.
10
Agenda
r Why Verification ?
r Verification Alternatives
o Simulation
o Hardware-accelerated simulation
o Emulation
o Protot yping
o Formal verification
o Semi-Formal (Dynamic Formal) verification
r Languages for System Modeling and Verification
r Verification with Progressive Refinement
r SoC Verification
r Concluding Remarks
11
Overview of Verification Methodologies
Simulation
Hardware
Accelerated
Simulation
Emulation
Formal
Verification
Semi-formal
Verification
Prototyping
F
aster speed, cIoser to finaI product
B
igg
er coverag
e
Basic
verification
tooI
12
Software Simulation
r Dynamic verification method
r Bugs are found by running the design implementation.
r Thoroughness depends on the test vector used.
r Some parts are tested repeatedly while other parts are
not even tested.
a = 1;
#20 b = 1;
$display (status is = %d,c);
...
Testbench DUV
Some part of the
design is tested
repeatedIy.
Other parts are
not even tested.
13
Cycle-Based Simulation
r Simulate the behavior of the design cycle-by-cycle.
r Cycle-accurate information is provided as a result of
simulation.
r Only signals at the flip-flop input are evaluated to be
stored, not internal signals of combinational logic.
CombinationaI
Iogic
CombinationaI
Iogic
CombinationaI
Iogic
CombinationaI
Iogic
CombinationaI
Iogic
CombinationaI
Iogic
CombinationaI
Iogic
CombinationaI
Iogic
CombinationaI
Iogic
CombinationaI
Iogic
14
Cycle-based vs. Event-driven
At the output of every
logic gate on the event
propagation path
Every flip-flop
boundary
Evaluation node
Proportional to the
number of events (circuit
size* no. of cycles* event
density)
Proportional to the
(number of cycles)
times (C/ L size *
number of F/ F's)
Simulation time
At the occurrence of
events
Rising/ falling/ both
clock edges
Evaluation time point
User-defined minimum
delay
Clock cycle Timing resolution
Event-driven Cycle-based
15
Software Simulation
r Pros
o The design size is limited only by the computing
resource.
o Simulation can be started as soon as the RTL
description is finished.
o Set-up cost is minimal.
r Cons
o Slow (~100 cycles/ sec) ; Speed gap between the
speed of software simulation and real silicon widens.
(Simulation speed = size of the circuit simulated /
speed of the simulation engine)
o The designer does not exactly know how much
percentage of the design have been tested.
16
Hardware-Accelerated Simulation
r Simulation performance is improved by moving the
time-consuming part of the design to hardware.
r Usually, the software simulation communicates with
FPGA-based hardware accelerator.
Simulation environment
Testbench
ModuIe
0
ModuIe
1
ModuIe 2
Hardware
Accelerator
ModuIe 2 is
synthesized &
compiIed into
FPGAs
17
Hardware-Accelerated Simulation
r Pros
o Fast (100K cycles/ sec)
o Cheaper than hardware emulation
o Debugging is easier as the circuit structure is unchanged.
o Not an Overhead : Deployed as a step stone in the gradual
refinement
r Cons (Obstacles to overcome)
o Set-up time overhead to map RTL design into the hardware can
be substantial.
o SW-HW communication speed can degrade the performance.
o Debugging of signals within the hardware can be difficult.
18
Hardware-Accelerated Simulation
r Challenges
o Overall speed depends on the communication
between simulator and hardware.
o Execution time decomposition in a typical case of a
PC -based hardware accelerator
o SW simulator + PL / FL + Driver overhead : 38%
t is desirable to reduce the driver call overhead
o PC overhead : 44% Can be reduced by using DMA data
transfer
o Today (2008), SystemC has substituted PL / FL (Ney)
SW SimuIator + PLI/FLI + Device Driver
38%
Hardware AcceIerator
18%
PCI overhead
44%
19
Emulation
r Emulation: mitating the function of another system to
achieve the same results as the imitated system
r Usually, the emulation hardware comprises an array of
FPGAs (or special-type processors) and interconnection
scheme among them
r About 1000 times faster than simulation
Simulation
Hardware
Accelerated
Simulation
Emulation
Prototyping
20
Emulation
r User logic design is mapped to emulation board with
multiple FPGAs and/ or special processors
r The emulation board has external interconnection
hardware that emulates the pins of final chip.
&
&
>
+
Logic design
Emulation hardware with multiple FPGAs
Design
mapping
External pins
21
Emulation
r Pros
o Fast (500K cycles/ sec)
o Verification on real target system
r Cons
o Setup time overhead to map RTL design into
hardware is very high
o Many FPGAs + resources for debugging
high cost
o Circuit partitioning algorithm and interconnection
architecture limit the usable gate count
22
General Architecture of Emulation Systems
FPGA 0 FPGA 1
FPGA 2 FPGA 3
Crossbar
(Switch)
r Many FPGAs are interconnected together for large gate
capacity
r Emulation systems on the market have differences in their
interconnection architectures
23
Emulation
r Challenges
o Efficient interconnection architecture and Hardware
Mapping efficiency for Speed and Cost
o RTL debugging facility with reasonable amount of
resource
o Efficient partitioning algorithm for any given
interconnection architecture
o Reducing development time (to take advantage of
more recent FPGAs)
24
Prototyping
r Special (more dedicated and customized) hardware
architecture made to fit a specific application.
Simulation
Hardware
Accelerated
Simulation
Emulation
Prototyping
25
Prototyping
r Pros
o Higher (than emulation) clock rate (over 1M
cycles/ sec) due to specific design of prototyping
board
o Components as well as the wiring can be customized
for the corresponding application
o Can be carried along (Hardware Emulation? Forget
it!)
r Cons
o Not flexible for design change
(Every new prototype requires a new board
architecture. Even a small change requires a new
PCB.)
26
A Prototyping Example
r Prototype of 4-Port
Gigabit Ethernet
Switch
o Two Xilinx Virtex-E
2000 FPGAs are on
FPGA board.
o Four FPGA boards are
used.
o Processor board
contains PC bridge
and MPC860
microprocessor.
PCI bridge
MPC860
microprocessor
XiIinx FPGA
Switch board
Processor board
Courtesy of Paion, Inc.
28
Formal Verification
r Objective
o Check properties of model with all possible conditions
r Pros
o Assures 100% coverage
o Fast
r Cons
o Works only for small-size finite state systems
o Uncomfortable due to culture difference (E.g., engineers are
not familiar with the use of temporal logic used for property
description in Model Checking)
29
Formal Verification: Equivalence Checker
r Equivalence checker compares the golden model with the refined
model.
r Functional representations are extracted from the designs and
compared mathematically.
r Pros
o Exhaustive design coverage
o Very fast
r Cons
o Memory explosion
r Tools such as LEC (Verplex), Formality (Synopsys), FormalPro
(Mentor) supports Equivalence checking.
Golden
Model
Golden
Model
Refined
Model
Refined
Model
30
Formal Verification: Model Checking
r Model checking verifies that the design satisfies a
property specified using temporal logic
r Computational Tree Logic (CTL)
o Specify the temporal relationship among states in FSM with
temporal operators:
o A (always/ for all), E (exists/ for at least one) path quantifier
o G (global), F (future), X (next), U (until) temporal modality
Computational
Tree Logic
Computational
Tree Logic
Design
Design
31
Formal Verification
r Challenges
o The most critical issue of formal verification is the
state explosion problem
o The application of current formal methods are
limited to the design of up to 500 flip-flops
o Researches about complexity reductions are:
o Reachability analysis
o Design state abstraction
o Design decomposition
o State projection
32
Semi-Formal Verification - Assertion
r Assertion-based verification (ABV)
o Assertion is a statement on the intended behavior of a design
o The purpose of an assertion: to ensure consistency between
the designer's intention and the implementation
r Key features of assertions
o 1. Error detection: f the assertion is violated, it is detected by
the simulator
o 2. Error isolation: The signals related to the violated assertion
are identified
o 3. Error notification: The source of error is reported to the user
33
Semi-Formal Verification - Assertion
r Example of assertion-based bug detection
PCI DMA ControIIer
PCI DMA ControIIer
PCI
event devseI :
if ( FRAME= 0) [ 1..4]
( DEVSEL= 0)
assert( devseI) ;
I dentify signaIs reIated to
the vioIated assertion
"devseI"
assertion is
vioIated!
Report to the
user!!
34
Semi-Formal Verification - Assertion
r Quality of assertion-based verification (simulation)
Time, Effort
Setup
testbench
Describe
assertions
FormaI verification
SimuIation
SimuIation with assertions
Efficiency of
assertion
By IBM in 'Computer-Aided Verification" 2000
36
Semi-Formal Verification - Coverage
r Coverage metrics for coverage-directed verification
o Code-based metrics
o Line/ code block coverage
o Branch/ conditional coverage
o Path coverage
o Circuit structure based metrics
o Toggle coverage
o Register activity
o State-space based metrics
o Pair-arcs : usually covered by Line + condition coverage
o Spec.-based metrics
o % of specification items satisfied
37
Semi-Formal Verification - Coverage
r Coverage Checking tools
o VeriCover (Veritools)
o SureCov (Verisity)
o Coverscan (Cadence)
o HDLScore, VeriCov (Summit Design)
o HDLCover, VeriSure (TransEDA)
o Polaris (Synopsys)
o Covermeter (Synopsys)
o HDL simulators (today, 2008, Ney)
38
Semi-Formal Verification
r Pros
o Designer can measure the coverage of the test environment as
the formal properties are checked during simulation
r Cons
o The simulation speed is degraded as the properties are
checked during simulation
r Challenges
o There is no unified testbench description method
o t is difficult to guide the direction of test vectors to increase
the coverage of the design
o Development of more efficient coverage metric to represent
the behavior of the design
39
Speed Comparison
0 kHz
Software
SimuIation
HDL
SimuIators
10 kHz
1MHz
Hardware-
AcceIerated
SimuIation
(from Quickturn/
DynaIith
Presentation)
Hardware
emuIation
(from
Quickturn
presentation)
100kHz
500KHz
100Hz
100 kHz
Speed (CycIes/sec, Iog scaIe)
10MHz
1~10MHz
Prototyping Semi-formaI
(Assertion-
based
verification)
50-70Hz
40
Design Complexity
Depends on the
components on the board
1M~5M gates Protot yping
Limited to about 500 flip-
flops due to state
explosion
< 10K gates Formal verification
Depends on the number
of FPGAs in the
architecture
1M~16M gates Emulation/ Hardware-
accelerated simulation
Unlimited Simulation/ Semi-
formal verification
Comments Gate counts
41
Verification Time vs. Coverage
Coverage
Verification Time
SimuIation
Semi- formaI
Prototyping
EmuIation
/ AcceIerated simuIation
SimuIation
set up
Semi- formaI
set up
EmuIation
set up
Prototyping
set up
Redirection
of testbench
constraints
100%
42
Agenda
r Why Verification ?
r Verification Alternatives
r Languages for System Modeling and Verification
o System modeling languages
o Testbench automation & Assertion languages
r Verification with Progressive Refinement
r SoC Verification
r Concluding Remarks
43
Accellera
r Formed in 2000 through the unification of
Open Verilog nternational and VHDL
nternational to focus on identifying new
standards, development of standards and
formats, and to foster the adoption of new
methodologies
44
Accellera
r Three different ways of specifying
Assertions in Verilog designs:
oOVL (Open Verification Library)
oPSL (Property Specification Language)
oNative assertion construct in System Verilog
o(Ney) n fact, today this is a new language, SVA
(SystemVerilog Assertions), complementary to PSL
45
ACCELLERA APPROVES FOUR NEW
DESI GN VERI FI CATI ON STANDARDS
r June 2, 2003 - Accellera, the electronics industry
organization focused on language-based electronic
design standards approved four new standards for
language-based design verification:
o Property Specification Language (PSL) 1.01
o Standard Co- EmuIation AppIication Programming
I nterface (SCE-AP ) 1.0
o SystemVeriIog 3.1
o VeriIog-AMS 2.1
46
Accellera's PSL (Property Specification
Language)
r Gives the design architect a standard means of
specifying design properties using a concise syntax with
clearly defined formal semantics
r Enables RTL implementer to capture design intent in a
verifiable form, while enabling the verification engineer
to validate that the implementation satisfies its
specification with dynamic (that is, simulation) and static
(that is, formal) verification
47
SCE(Standard Co-Emulation nterface)-AP
r SCE-AP standard defines a high-speed, asynchronous,
transaction-level interface between simulators or
testbenches and hardware-assisted solutions such as
emulation or rapid prototypes
48
Language Heritage for SoC Design
r New languages are developed to fill the productivity gap
Verilog
VHDL
C
C++
JAVA
Assembly
SystemC
SystemVerilog
Vera
TestBuilder
Language for
Software deveIopment
Language for
Hardware test
Language for
Hardware description
Schematic
Past Current Today
49
SystemC
r SystemC is a modeling platform consisting of
o A Iibrary of C+ + cIasses for modeling hardware
o ncluding a simuIation kerneI that supports hardware
modeling concepts at the system level, behavioral level and
register transfer level
r SystemC enables us to effectively create
o A cycIe-accurate modeI of
oSoftware algorithm
oHardware architecture
o nterfaces of System-on-a-Chip
r Program in SystemC can be
o An executabIe specification of the system
50
SystemC
r Modules, ports, and signals for hierarchy
r Processes for concurrency
r Clocks for time
r Hardware data types for bit vectors, 4-valued logic,
fixed-point types, arbitrary precision integers
r Waiting and watching for reactivity
r Channel, interface, and event for abstract communications
sc_main
ModuIe
ModuIe
Process
Process
Process Process
Process
Process Process
ModuIe
Process
Process
51
Abstraction Levels of SystemC
Algorithm level
Untimed functional level
Timed functional level
Bus-cycle accurate level
Cycle accurate level
Behavioral level
RT level
C/C++
SystemC
Function hierarchy
Modular structure
Timing information
ntra module: untimed
nter module: cycle accurate
Cycle accurate
Synthesizable
Gate level
VeriIog/VHDL
52
Test-bench automation
r Why is test-bench automation required?
o Test-bench for P can be more complex than the P itself
o Manual description of the test-bench is a time-consuming job
o Simulating the whole test-bench in HDL yields excessive
verification time
r Players
o TestBuilder (Cadence)
oCloser to C, integrated to SystemC
o(Ney) Today, (2008) adopted as the SCV (SystemC
Verification Standard)
o VERA (Synopsys)
oCloser to Verilog, integrated to SystemVerilog
53
TestBuilder
r Transaction-Based Verification
Functional verification in higher-level abstraction
Engineer develops tests from a system-level perspective
o Advantages
oEnhance reusability of each component in the test-benches
o mprove debugging and coverage analysis
DUV DUV
(Design (Design
Under Under
Verification) Verification)
TVM TVM Tests Tests
Signal Level Signal Level Transaction Level Transaction Level
TVM: Transaction Verification Model TVM: Transaction Verification Model
54
TestbuiIder/C/C++ HDL
TestBuilder
Signal Level Signal Level Transaction Level Transaction Level
Tests Tests TVM TVM DUV DUV
while(){
tx.send_packet();
mem.expect_write();
..
}
tx.send_packet(..){
header = hd;
address=0xff0011;
data = 0xff0011;
}
r TVM (Transaction Verification Model)
o Translates a bus cycle command to a signal waveform
o May be described in C AP or Verilog PL . (Ney) Today, (2008)
this is described (mostly) in SystemC, using the SCV
55
TestbuiIder/C/C++ HDL
TestBuilder
Signal Level Signal Level Transaction Level Transaction Level
Tests Tests TVM TVM DUV DUV
while(){
tx.send_packet();
mem.expect_write();
..
}
tx.send_packet(..){
header = hd;
address=0xff0011;
data = 0xff0011;
}
r TVM (Transaction Verification Model)
o Translates a bus cycle command to a signal waveform
o May be described in C AP or Verilog PL
56
Inputs to VERA
VERA (Synopsys)
dut.v dut.v vera.vr vera.vr
VERA VERA
DUT DUT
r Functional verification language for testbench description
o OpenVera is a language specification
o VERA (Synopsys) is a testbench generation tool
Constraints written in
OpenVera syntax
59
SystemVerilog
r SystemVerilog 3.1 provides design constructs
for architectural, algorithmic and transaction-
based modeling
r Adds an environment for automated
testbench generation, while providing assertions to
describe design functionality, including complex
protocols, to drive verification using simulation or formal
verification techniques
r ts C-AP provides the ability to mix Verilog and C/ C++
constructs without the need for PL for direct data
exchange
r (Ney) Today (2008), this last characteristic is also
supported by SystemC!!
60
SystemVerilog
r New data types for data abstraction level higher than
Verilog
o Structures, classes, lists, etc. are supported
r Assertion
o Assertions can be embedded directly in Verilog RTL
o Sequential assertion is also supported
r Encapsulated interfaces
o Most system bugs occur in interfaces between blocks
o With encapsulated interfaces, the designer can concentrate on
the communications rather than on the signals and wires
r DirectCas a fast C-AP
o C codes can be called directly from the SystemVerilog codes
62
System Description Languages Summary
Few tools (simulation,
synthesis, etc.)
Easy to learn for the
HDL designers
Easy to model system
behaviors
SystemVerilog
Limited tools (simulation,
synthesis, etc.) - (Ney)
This is no longer true!
Easily connected to
C/ C++ codes
Easy to model system
behaviors
SystemC
Focuses on the lower-level
designs
mproper for system
modeling
Familiarit y
Easy to describe H/ W
designs
HDL
(Verilog,
VHDL)
Unable to handle some
hardware environments
Easy to write test
vectors/ environment
C/ C++
Cons Pros Languge
63
Agenda
r Why Verification ?
r Verification Alternatives
r Languages for System Modeling and Verification
r Verification with Progressive Refinement
o Flexible SoC verification environment
o Debugging features
o Cycle vs. transaction mode verification
o Emulation products
r SoC Verification
r Concluding Remarks
64
Criteria for Good SoC Verification
Environment
r Support various abstraction levels
r Support heterogeneous design languages
r Trade-off between verification speed and
debugging features
r Co-work with existing tools
r Progressive refinement
r Platform-based design
66
Core model
Core model
SS
SS
Transaction-Level Modeling
r Model the bus system in transaction-level
o No notion of exact time.
o But precedence relation of each functional block is properly
modeled.
o Rough estimation on performance is possible.
o Used as the fastest reference model by each block designer
Memory
Memory
P
P
P
P
Transaction-level Bus model
Transaction-level Bus model
Rough
Performance
Estimation
...
...
Behavior
model
---
---
---
---
---
---
Software design
Hardware design
transaction
68
AMBA AHB CL Specification
r AMBA AHB Cycle Level nterface (CL ) Specification
o Released on July 23, 2003 by ARM.
o CL spec defines guidelines for TLM of AHB with SystemC.
o nterface methods
o Data structures
o Header files for SystemC models
o CL spec leaves the detailed implementation of the AHB bus
model to the reader.
master
master
sIave
sIave
master
master
HADDR
HWRTE
HRDATA
HTRANS
sIave
sIave
Read 10 data from slaveX starting
Address 0x10
CycIe-IeveImodeIing Transaction-IeveImodeIing
69
AMBA AHB CL Specification
r Example master implementation
o Transactions are represented as methods in transaction-level modeling.
o The abstraction levels of each method can be decided as needed such
as cycle-count accurate, cycle-accurate, transaction accurate, etc.
void masterA::run()
{
bus_request();
has_grant();
init_transaction();
read_from_sIave();
...
}
void masterA::run()
{
bus_request();
has_grant();
init_transaction();
read_from_sIave();
...
}
Header Body
The granularity of
transactions are
decided according to
the verification needs.
SC_MODULE(masterA) {
...
...
void run();
};
SC_MODULE(masterA) {
...
...
void run();
};
masterA.h masterA.cpp
70
Flexible SoC Verification Environment
r Build C reference model
for the target application.
r Setup of platform-level
verification environment
as early as possible
JPEG
decoding
HEAD VLD DCT DSP
Functional block model
TRS TRS TRS TRS
HEAD VLD DCT DSP
Platform-level model
Algorithm
Memory Timer NTC
SW Model
HW Model
71
Flexible SoC Verification Environment
r Transactor connects
various types of SW
block models with HW
bus system.
r Several types of
transactors must be
prepared, for example
o AHB C model
o AHB HDL model
o OPB Testbuilder
o PLB SystemC
JPEG
decoding
HEAD VLD DCT DSP
Functional block model
TRS TRS TRS TRS
HEAD VLD DCT DSP
Platform-level model
Algorithm
Memory Timer NTC
72
Flexible SoC Verification Environment
r Socketize P representation
o HW: C HDL ED F
o SW: native C SS Processor Core
C
Transactor
HDL
AHB
C to HDL
EDF
Synthesis
Transactor
C
AHB
SS
AHB
Processor
Cross-compiler
Transactor
Transactor
Transactor
SW part
modeI
HW part
modeI
73
Cycle-Level Transactor
r Generate stimulus at every clock cycle
r Check the result of DUT at every clock cycle
PC
Controller
DUT PC
Channel
Testbench
Testbench
DUT
FPGA part
Device
Driver
S/W simuIation part
Cycle-level
transactor
74
Transaction-Level Transactor
r Only information to generate transaction is transferred
to DUT, i.e., address and data
r No need to synchronize at every clock cycle
PC
Controller
DUT DMA
Channel
Testbench
Testbench
DUT
FPGA part
Device
Driver
S/W simuIation part
T
r
a
n
s
a
c
t
o
r
Main
Memory
75
Cycle vs. Transaction-level Transactor
r Cycle-level transactor
o Synchronized at every clock cycle.
o Transactor can be automatically generated according to the pin
count.
o Operating speed depends on the number of signals to be
transferred.
r Transaction-level transactor
o Synchronized at the end of each transaction.
o Transactor generates all necessary signals for DUT to properly
transfer the data.
o Transactor must be designed for each interface standard
ex) AHB transactor, SDRAM transactor, S transactor
76
Example) iPROVE Technology
r PC -based Simulation Accelerator
o Cycle-level verification
o Seamless integration with the HDL testbench.
o Up to 100K cycles/ sec speed. (1000 times faster than SW
simulation)
o Transaction-level verification
o Up to 33M cycles/ sec speed. (330K times faster than SW
simulation)
DUT Transactor
Transactions SignaIs
DUT Test
SignaI information SignaIs
AutomaticaIIy
generat ed
moduIe
Test
77
OpenVera (OV) verification P
r Reusable verification modules, i.e.,
1) bus functional models,
2) traffic generators,
3) protocol monitors,
and
4) functional coverage blocks.
78
Companies providing
OpenVera Verification I P
r ControlNet ndia EEE 1394, TCP/ P Stack
r GDA Technology HyperTransport
r HCL Technologies 2C
r ntegnology Smart Card nterface
r nSys S EEE 1284, UART
r Qualis Design Ethernet 10/ 100, Ethernet 10/ 100/ 1G,
Ethernet 10G, PC -X, PC , PC Express Base, PC Express
AS, 802.11b, ARM AMBA AHB, USB 1.1, USB 2.0
r Synopsys, nc. AMBA AHB, AMBA APB, USB, Ethernet
10/ 100/ 1000, EEE 1394, PC/ PCx, SONET, SDH, ATM,
P, PDH
79
Debugging Design in the FPGA
r Embed logic analyzer with user design in ED F format
o Logic to store pre-registered signals into the probing memory.
o Logic for trigger condition generation.
o Triggering condition is dynamically configured.
r nternal node extraction
o Sometimes the designer wants to watch internal nodes in the
design.
o nternal node probing
enables this by
wiring-out the internal
nodes to the boundary
of the DUT top block.
DUT
Built- n
Logic
Analyzer
Top bIock
Sub-bIock
I nternaI node
External
Dump
Memory
B LA, Dynalith Systems
80
RTL Debugging Feature
r Emulation is based on gate-level netlist.
r Gate-level netlist generated from the synthesis tools has
too complex name styles difficult to trace manually.
r Techniques to resolve RTL symbol names from the gate-
level symbol names and to provide debugging
environment in RTL name spaces is required.
r nsert RTL instrumentation P for debugging
o Design flow
o Read RTL design (Verilog, VHDL)
o Generate instrumented RTL design (spiced with triggering and
dump logic)
o Synthesis
o Compile (mapping & PAR)
o DiaLite (Temento), dentify (Synplicity)
81
RTL Debugging Feature
r nstrumentation Ps for debugging logic blocks mapped
into FPGAs.
o Trigger
o Logic Equation Module
o History Register
o Transaction Register
o Random Generator
o Traffic Analyzer
r nstrumentation Ps are
interconnected to
support various
configurations.
Structures of the RTL design
Interconnection of instrumentation IPs
DiaLite from Temento
82
FPGA-based Debuggers
Debugger
Debugger
Level
Level
Memory
Memory
Control ports
Control ports
Triggering conditions
Triggering conditions
Dynalith Systems
B LA
Dynalith Systems
B LA
Netlist
level
Netlist
level
Temento
DiaLite
Temento
DiaLite
RTL
RTL
Block memory
of FPGA
Block memory
of FPGA
External
memory
External
memory
PC
PC
JTAGsignals
mapped to
user / O ports
JTAGsignals
mapped to
user / O ports
Synplicity
dentify
Synplicity
dentify
RTL
RTL
Block memory
of FPGA
Block memory
of FPGA
Dedicated JTAG
Ports of FPGA
Dedicated JTAG
Ports of FPGA
Dynamically configurable
without recompiling FPGA
Dynamically configurable
without recompiling FPGA
83
Connecting Actual Chip to the Simulator
r Building a correct and fast reference model for the hardware is very
difficult.
Use the actual discrete chip
for the P (or FPGA).
r Control the clock signal to the
actual chip (or FPGA), i.e,
slow down and
synchronize with the HW simulator
and SW debugger
in the host machine.
r Application
o FPGA prototyping
o HW/ SW co-verification
o Silicon validation
from SimPOD
84
Synthesizable Testbench
r Prepare a set of programmable test bench module
which can be also synthesized into hardware.
r To verify a DUT, build a test bench using the
programmable
test bench.
r The test bench is
applicable to both
simulation and
emulation in
the same fashion.
from Duolog Technolog Generic Mini-ControIIer
( GMC)
gmc_cfg_datasize 3 # Set to 32 Bits
gmc_cfg_msmode 0xF # Set to Master TX
gmc_cfg_datapath_0x00 # Read/Write to Mem
gmc_cmd_send_data 100 # Send 100 Bytes
uart_cfg_odd_parity 1 # Set ODD parity
85
Large-Scale Emulators
r Celaro, Mentor
o Massive array of FPGA's
o Distributed compilation
o RTL debuggability
o Full visibility without re-compilation
r VStation, Mentor ( KOS)
o Reduced routing problem by multiplexing multiple physical
signal lines to a virtual wire.
r Palladium, Quickturn (Cadence)
o Use custom processor-array instead of FPGA
o Support synthesizable testbench
o Support multi-user operation
88
Agenda
r Why Verification ?
r Verification Alternatives
r Languages for System Modeling and Verification
r Verification with Progressive Refinement
r SoC Verification
o Co-simulation
o Co-emulation
r Concluding Remarks
89
SoC Verification
r Co-simulation
oConnecting SS with HDL simulation environment
oSeamless, N2C
r Co-emulation
oEmulation/ rapid-prototyping equipments supporting
co-emulation
oARM ntegrator, Aptix System Explorer, AX S XoC,
Dynalith iPROVE
90
What's the point in SoC Verification?
r Mixture of SW and HW
o Let the HW model to cooperate with Processor Model such as
SS or BFM (Bus functional model)
r Mixture of pre-verified, unverified components
o Utilize legacy Ps already verified
r Mixture of different language, different abstraction levels
o Provide common interface structure between SoC components
91
Canonical SoC design flow
System
Spec.
System
Design
HW/ SW
Partitioning
HW
DeveIopment
SW
DeveIopment
HW refinement
( UT-> T-> RTL)
Gate
HW I P
SW I P
Software
Verification
FunctionaI
Verification
Gate-LeveI
Verification
HW-SW
Co-Design
HW-SW
Co-
Verification
SW refinement
( RTOS
mapping)
FinaI code
r Emulator
o n-system emulator
o HW-SW co-debugging
92
Tools for HW-SW Co-Verification
o HW-SW co-simulation
o SS
o RTOS simulator
HW/ SW
Partitioning
HW
DeveIopment
SW
DeveIopment
HW refinement
( UT-> T-> RTL)
Software
Verification
FunctionaI
Verification
Co-
Verification
SW refinement
( RTOS
mapping)
HW-SW
o High-level synthesis
o Testbench automation
o P accelerator
System
Spec.
System
Design
HW/ SW
HW I P
SW I P
93
Tools for System-level Verification
r System-level design (Performance analysis tools)
o Hot-spot analyzer
o High-level cycle count estimation
o High-level power analysis
o High-level chip area estimation
o On-chip-bus traffic estimation
System
Spec.
System
Design
HW/ SW
Partitioning
HW I P
SW I P
HW-SW
Co-Design
94
Co-Simulation Tools
r Software debugging in SS and hardware verification in
HDL simulator are done in parallel way.
r Co-simulation stub manages the communication
between HDL simulator and SS.
r The most accurate solution albeit very slow
r Commercial Products
o Eaglei (Synopsys), Seamless (Mentor)
ISS
HDL
SimuIator
Co-simuIation
Stub
Debugger
Remote
Debugging
nterface
95
while(true) {
inst = fetch( pc );
opcode=decode(inst);
switch( opcode ){
.
case ADD:
.
break;
}
}
nstruction Set Simulator
r nterpretive SS
oSlow but flexible and accurate
r Compiled SS
oFast and accurate but applicable
only for static programs
oStatic vs. dynamic
oDepending on the code generation is
done in static or dynamic due to
cache miss, branch prediction and
self-modifying code, etc.
r Native Code ( not an SS )
oFast but not accurate
o / O handling problem Main loop of interpretive SS
96
nstruction Set Simulator
r Execution speed
oNative code > Static compiled SS > Dynamic
compiled SS > nterpreted SS
r Accuracy
oNative code < Static compiled SS = Dynamic
compiled SS <= nterpreted SS
97
Seamless (Mentor)
r Seamless and C-Bridge enables co-verification of
SS(Processor) + HDL + C Hardware model
r Full visibility and dynamic performance estimation.
r Supports various CPU's
(over 100 models)
r The communication
between the S/ W and
the H/ W is optimized
to maximize the
verification performance.
from Mentor
98
N2C
r A set of tools allowing co-simulation of the system
described in various abstraction levels
o Un-timed C
o Timed functional description
o Behavioral bus cycle accurate description
o RTC (Register Transfer C)
o HDL with C
r nterface synthesis to enable platform exploration
o nterface synthesis make it possible to verify the performance
of each platform efficiently in the early design stage.
o Solving Hardware/ software partitioning problems.
o Deciding bus architecture of the SoC.
99
Co-Emulation Tools
r Link hardware emulators with a processor model
running in host machine or an actual processor core
module
r Most emulation and rapid prototyping products support
linkage with SS running in host machine
r As the emulator runs very fast, speed of SS including
memory access as well as synchronization between
emulation and SS rise as new bottlenecks in
verification
100
Example) ARM ETM (Embedded Trace
Macrocell)
r Real-time trace module capable
of instruction and data tracing
dedicated to
the ARM core family
r Triggering enables to focus
collection around the region
of interest
r Trace module controls the
amount of trace data by
filtering instructions or data
r Only applicable to the ARM
core debugging
ARM ARM
core core
Memories
Peripherals
O
t
h
e
r

c
o
m
p
o
n
e
n
t
s
ETM
Target system with ARM based AS C
PC-based
debugger
Trace
Trigger
Trace
port
analyzer
JTAG
interface
Conf.
101
Typical Co-Emulation Environment
r Connect ARM SS or ARM board to the emulation
system.
ARM SS
Emulation
System
ARM
Development
Board
Emulation
System
o ARM SS can be configured to
user's target SoC architecture.
o SW debugger can be fully utilized.
o Faster than SS.
o Ready-made ARM development
boards has fixed architecture and
it may be different from user's
desire.
102
ARM ntegrator
r ARM prototyping platform
r Composed of the followings
o Platform : AMBA backbone + system infrastructure
o Core Module : various ARM core modules (up to four)
o Logic Module : FPGA boards for AMBA P's
r Allows fast prototyping
of ARM-based SoC
r Enables co-emulation
of both software in ARM
processor core and
hardware in the FPGA
r Difficult to debug hardware
logics
from ARM
103
XoC(Axis)
r ARM core module is connected to Axis's FPGA arrays.
o Source level debugging for both hardware and software
o HW/ SW logic simulation hot swapping VCD on demand
o Software instant replay
Correlate bus transaction with software instruction
ARM
DeveIopment
board
from Axis
105
AS C Verification Methods
Running Speed
10Hz
100Hz
1KHz
10KHz
100KHz
1MHz
10MHz
100MHz
SW Simulator
Investment
HW Emulator
Rapid Prototype
Real Silicon
HW Accelerator
Ideal Verification Ideal Verification
Solution Solution
Make it faster Make it faster
Make it cheaper Make it cheaper
106
iSAVE-MP (Dynalith)
iSAVE- MP main
iSAVE- MP Target I nterface
MPEG Board
Decoded image
GUI windows
107
FPGA
FPGA
Csessions
Design
in ED F
Design
in ED F
Transactor Transactor
Target board
/ F protocol / F protocol
nter-Lingual Communication
Design
in C
iSAVE-MP (Dynalith)
r All-in-one verification :
o Heterogeneous models including ARM SS, C hardware model, HDL
hardware description
o SW models run in linux-based PC
o HW models run in FPGA's
r Debugging with PSA
o Probe FPGA internal signals
values to SRAM memory
on the fly.
fastest operating speed,
wide and deep
sampling window
r Communicate with C model
using PC DMA
ARM sessions
Design
in C
Design
in C
Design
in C
108
Tools for SoC Design
CompIete customization is
not possibIe.
Debugging of I P
embedded in FPGA is not
easy.
Semi-customization using moduIes
is possibIe.
HW prototyping with ARM
ARM SW debugging through ETM &
ETB.
ARM I ntegrator
Low speed CosimuIation environment is
supported.
C and SystemC Ianguages
supported.
N2C
Low speed CosimuIation environment is
supported.
Many CPU types
SeamIess
No consideration about
debugging of HW I P's.
SW programming is easy on ARM-
based prototyping hardware or SoC.
ARM ReaI-Time
Debuggers
No consideration about
HW I P's.
Required tooI for ARM SW
deveIopment
ADS
Cons Pros TooIs
109
Tools for SoC Design
Long compiIation time
ManuaI setup required
HW I P debugging
ModuIe- based customization
CosimuIation environment
System ExpIorer
Long compiIation time
CosimuIation with ARM I SS
SW debugging through I SS
HW debugging is supported.
Low cost
iPROVE/ iSAVE
Long compiIation time
CosimuIation with ARM
ARM SW debugging though ETM &
ETB
HW I P debugging
XoC
Cons Pros TooIs
110
Agenda
r Why Verification ?
r Verification Alternatives
r Languages for System Modeling and Verification
r Verification with Progressive Refinement
r SoC Verification
r Concluding Remarks
111
Concluding Remarks
r Verification is challenging; t needs strategy!
r Strategy is to apply each method when appropriate
r Verify as early as possible; Catch the bug when it is
small and still isolated in a smaller region (Don't wait
until it grows and kills you)
r 1
st
step: Apply formal methods
o Static formal verification
o Assertion-based verification
r 2
nd
step: Simulate P with transaction level test-bench
o Test-bench automation tools
r 3
rd
step: Emulate design
o Emulate P operation in FPGA
o n-system P verification
o Cycle-level vs. transaction level test-bench
112
Concluding Remarks
r Main differences of SoC with AS C design are
o Planned P-reuse
o Reuse of pre-verified platform
o Focus on co-verification with software
r Newly added P's must be thoroughly verified utilizing
automated testbench and formal methods, if possible
r Well-established emulation platform helps
o Progressive refinement of newly added SoC components
o Early development and verification of software
r Powerful debugging features handling both hardware
part and software part are required
r Language, Tool/ Data nterfaces need standardization.
r DFV (Design for Verification); You lose in the beginning,
but will win later, like Design for Reuse

Anda mungkin juga menyukai