1 7 July 2008 Test and Verification Solutions ARM Based SOC Verification Mike Bartley, Avanish Sachan, Abhineet Sanghvi, Christdas Test and Verification Solutions
1 7 July 2008
Test and Verification Solutions
ARM Based SOC Verification
Mike Bartley, Avanish Sachan, Abhineet Sanghvi, Christdas
Test and Verification Solutions
2 14 March 2013 2 7 July 2008
Agenda
• System Verification Challenges
• SoC Verification Methodologies
• Formal
• HW/SW
• FPGA Prototyping
• Q&A
3 14 March 2013 3 7 July 2008
Typical ARM Based SoC Architecture
ARM Core
ARM Interconnect
TIMER
PLL
Boot Config
ARM Boot ROM
Debug & Trace
DMAController
Memory SubSystem
External Bus Interface
High Speed
Pheripheral
Bridge UART
I2C
GPIO
Low Speed Pheripheral
Test I/F Controller
On Chip Memory
DDR Cntrl SRAM Cntrl
Looks simple BUT ….
4 14 March 2013 4 7 July 2008
Why is SoC different? System Verification Challenges
High potential bug areas in SoC
Unexpected access conflict between the
shared resources.
Complexities arising out of interaction
between subsystems which were
verified stand alone.
Cache coherency in multi-core system.
Interrupt connectivity and Priority
scheme.
Arbitration priority related issues and
access dead-locks.
Unexpected HW/SW sequencing.
Exception handling conflicts and priority
scheme.
Multiple power domain region, clock
domain crossing.
Multiple reset and clock region.
5 5 29 April 2009
Top3 Verification Challenges
• Top1: Mastering Verification Complexity
– Continuous increase in number of IP’s and embedded
processors
• 2006: 30-40 IP’s, 1 CPU
• 2011: 80+ IP’s, 6+ CPU’s
• 2016: 120+ IP’s, 20 CPU’s ?
– The more IP’s the higher the risk of late spec &
implementation changes
– Driving towards true Hw/Sw Co-Verification
6 6 29 April 2009
2. Scalability
• Constrained-random simulation has been proven as a good bug-hunting flow, but... – How many cycles to verify 2 weeks at
target speed of 1GHz?
• Answer: 0.6 x 1015
• How will we scale simulation, emulation, FPGA to next generation of CPUs? SoCs?
• What are the alternatives?
Simulation
(KHz)
Emulation
(1 MHz)
FPGA
(10 MHz)
Si
(1 GHz)
Target cycles
1015
1,000,000 sim
slots
1000 emulation
slots
100 FPGA slots 1 chip
7 14 March 2013 7 7 July 2008
ARM SoC DV Methodology
This session describe the current verification methodology used
in SoC verification.
Formal Verification
Hardware Software Co Verification
FPGA Prototyping
8 14 March 2013 8 7 July 2008
Formal Verification
Formal verification
is a systematic process that uses mathematical
reasoning to verify the design.
works algorithmically and exhaustively explores all
possible input values over time.
no stimulus!
Why use formal?
100% coverage (if you set it up correctly)
difficult to figure out how stimulate the design
difficult to create checker
An ideal formal verification tool requires
capacity in order to handle complex designs
Simulation Depth-first vs. Formal Breadth-first
Where the nodes are states in the simulation
And the arcs are clocked transitions
But the trees are – Very wide
– Very deep
Model Checking – a very brief introduction
Inputs to the tool
• 3 inputs to the tool – A model of the design
– A property or set of properties representing the requirements
– A set of assumptions, expressed in the same language as the properties
• typically constraints on the inputs to the design
• For example – Usually RTL
– Items are transmitted to one of three destinations within 2 cycles of being accepted
• (req_in && gnt_in) |-> ##[1;2] (req_a || req_b || req_c)
– The request signal is stable until it is granted
• (req_in && !gnt_out) |-> ##1 req_in
• We would of course need a complete set of constraints
Apps allow you to auto-generate properties and constraints
11 14 March 2013 11 7 July 2008
Formal properties can be written to verify Connectivity between two IP’s within the SoC
hierarchy
Connectivity between the IP and DUT ports through the pads
The default reset values of all the DUT ports
Pad ring structure and control validation
Point-to-point and Point-to-multipoint
interconnectivity checks
Using Formal analysis for connectivity checking facilitates Controllability Completeness Generation of Formal Properties can be automated by running scripts on spreadsheets. Formal tools like IFV (Cadence) and Questa
(Mentor) support connectivity checking
Example
Block A
Block B
Block C
Port2
Port1
PortA1
IN1
Ctrl
assert_in1__blockc_port1: assert property ((dut.ctrl) throughout dut.in1 == dut.blockb.blockc.port1);
assert_blocka__blockc_port2: assert property (dut.blocka.porta1 == dut.blockb.blockc.port2 );
INTERCONNECTIVITY VERIFICATION
12 14 March 2013 12 7 July 2008
Protocol Compliance check using Formal Verification involves Development of a formal
specification of the protocol Bus Interface of each
component modelled as a FSM Protocol is then defined to be
the synchronous composition of these state machines
Finite state description of the protocol can be formally verified by a state space search
This helps in verifying the advanced features of SoC Bus Protocols like Pipelining - Between address/control and data phases Wait Cycles - Within the transfers Split Transfers – To facilitate bus arbitration
BUS PROTOCOL COMPLIANCE VERIFICATION
13 14 March 2013 13 7 July 2008
The Unified Power Format (UPF) is a low power specification standard that was recently approved by Accellera .
It captures the low power design specification in a portable form so that correct power management components
Can be implemented at the RTL
Inferred correctly during synthesis
Placed-and-routed efficiently and accurately in the physical design.
Formal Verification techniques can be used for
UPF specific assertions
Power control sequence-based assertions
Assertions to check incorrect and missing level shifters
Similar usage can also be deduced for designs incorporating Silicon Integration Initiative’s (Si2’s) Common Power Format (CPF)
LOW POWER VERIFICATION
14 14 March 2013 14 7 July 2008
DFT VERIFICATION
Scan Chain Connectivity Verification : Place-and-route tools change the order of the scan flops to minimize congestion. In this process, scan chains might be disconnected and lockup latches removed, thereby effecting test pattern generation or memory-BIST functionality Static scan-chain integrity checks allow for immediate verification that both the order and number of flops is as expected for different revisions of the netlist.
Formal properties can also be written to validate
Test Mode Entry Sequence
Test Mode exit values
Advantages : Reduced DFT verification cycles , Test Mode functional Validation , Equivalence checking among versions of netlists.
Model Checking – a very brief introduction
Outputs from the tool
• Proved
– the property holds for all valid sequences of inputs
• Failed(n)
– there is at least one valid sequence of inputs of length n cycles, as
defined by the design clock, for which the property does not hold.
– In this case, the tool gives a waveform demonstrating the failure.
– Most algorithms ensure that n is as small as possible, but some
more advanced algorithms don’t.
• Explored(n)
– there is no way to make the property fail with an input sequence of
n cycles or less
– For large designs, the algorithm can be expensive in both time and
memory and may not terminate
16 14 March 2013 16 7 July 2008
Some Limitations of Formal Verification
Size limit
Not always feasible
Better for control checking
Rather than data
17 14 March 2013 17 7 July 2008
Hardware Software Co Verification
Today we make products
Made up of hardware and software
The ability to achieve first silicon and first software success
relies on the capabilities of a verification environment to
support full-system hardware/software co-verification
Software engineers need to be able to access hardware design
to integrate software functionality with hardware.
In SoC verification, co-simulation provide the facility to verifying
hardware and software functionality together.
18 18
Top Level Test Generation for CPU
Bias tests to hit interesting
corner cases
– Scenario interleaving
– Target shared resources/’points
of convergence’
Non-repetitive useful tests
There should be an efficient
workflow
– Generation performance
– Target diverse platforms
– Ease of use
– Maintainability
– Reuse (of testing knowledge)
– Effective result checking:
Propagation of results
Trace comparison
Testbench
SoC
CPU
A
Mem.
B C
FABRIC FABRIC
BFM BFM
Scenario Test
Compiler
flow
Observe
results
Test
generator
Co
vera
ge
Ex
pe
cte
d
resu
lts
19 14 March 2013 19 7 July 2008
Hardware Software Co-Verification Flow
SW Tools
(Compiler, Linker,
Debugger)
Software Environment Hardware Environment
Executable Object
file DUT
HDL Simulation
Tools
Memory Model
Output for debugger
tools
20 20
How to go faster!
Compute Farm, Emulators, FPGA and test chips
21 21
The ‘tradeoffs’ for different platforms
Compute farm Emulator FPGA Test chip
Speed 10Hz - 100Hz
…per machine
1MHz 2MHz – 50MHz GHz
Observability Total Trace window +
host debug
Probes +
host debug
Host debug
Behavioural
testbench?
Yes Co-emulation
(speed penalty)
Co-emulation
(speed penalty)
No
Test in ‘real world’
systems
No Host debug +
ICE with speed
bridges
Mostly Yes
Are fails easily
reproducible in
simulation?
Yes Yes No No
Bring-up time Minutes Weeks hours Weeks Days Months
Partitioning!
Favours lots of
short tests!
Depends on
process maturity
Complex timing dependencies
… but also need to load tests
and dump test results!
22 14 March 2013 22 7 July 2008
FPGA Prototyping
It allows faster simulation and close to real time operation
performance
which could help in identifying a different class of bugs.
Integrated hardware-software testing.
Can be hard to map the design to the FPGA
Debug limited
Provides debug capability through JTAG and specialized
debug infrastructure which is built in to the FPGA.
23 14 March 2013 23 7 July 2008
Connecting the FPGA with simulation
FPGA
On board
BF
M
Logic Simulation
With Hardware
Design
Inter-Processor
Communication
(socket)
24 24
Standard Co-Emulation API (SCE-MI)
A standard for writing transactors that connect behavioural
test benches or models to emulators or FPGA platforms
Message or transaction rather than event oriented
Incorporates a synthesisable BFM
A subset of SystemVerilog DPI capabilities
Designed to integrate with SystemC
Behavioural
test bench
Hardware
Emulator
Custom Block
RTL
Monitor
SCE-MI Infrastructure
SCE-M
I
SW
link
25 25
SCE-MI: What are the issues?
Performance
– Need to consider both bandwidth and latency!
– Try to make operations non-blocking
– Performance of the behavioural testbench may limit the maximum speedup
Time
– The time for SCE-MI communications will depend on workstation performance
– Simulation time may be suspended during SCE-MI communications to maintain
determinism by consuming zero emulation time
Concurrency
– Concurrency is created by verification components operating independently of the DUT.
– A component in a process or thread outside the emulator time domain can prevent the
verification environment from being deterministic
Determinism
– Allowing non-determinism may increase performance
– However determinism is crucial for ease of debug
Maintenance
– Each protocol needs a SCE-MI transactor.
– These need to be verified and maintained.
26 14 March 2013 26 7 July 2008
FPGA Prototyping Limitations
• Many FPGAs are required for SoC partitioning,
• leading to prototype system complexity
• The target SoC may consist of many functional modules that are written at
different abstraction levels in the course of different development phases.
• Only synthesizable modules can be mapped into an FPGA and run for
debugging.
• Unable to partition multiple clocks and reset trees.
• FPGA provides limited debug capability and visibility during single iteration
• hence multiple iterations may be required to narrow down to the
specific bug.
27 14 March 2013 27 7 July 2008
Conclusion
• Increasing complexity
• Number of CPUs and Ips
• Multiple clock domains, multiple power domains,
• Coherent shared memory structures
• Scalability issues
• Is dynamic enough
• Number of cycles
• Writing complex tests and checkers
• Consider formal
• Product = hardware + software
• Hardware/Software co-verification
• Need longer simulations
• Consider FPGA
28 14 March 2013 28 7 July 2008
Benefits of working with T&VS
Faster time-to-market
Improved quality/reduced
product risk
Lower development
costs
Improved product features
Trusted partner
Cost Savings
o “TVS engineers saved 2 months on our 12 month schedule,
and reduced our costs by 20%”
Steve Neill, Managing Director of Infineon UK
Resource flexibility
o “TVS provided the OVM-compliant verification IP on
schedule and to budget, and were flexible enough to
incorporate change requests.” Simon Knowles, VP for
Strategy & DXP Technology, Icera
Increased quality of deliverables
o “TVS helped us incorporate the VIP into our test
environment in good time for our tape-out and left us with
complete documentation to allow us to repeat the work
should we ever need to on a future generation of our
technology.” Fred Homewood, CEO of Gnodal
Any Questions?
Benefits of working with T&VS