Test and Verification Solutions
ARM Based SOC Design and Verification
7 July 2008 1
Agenda
• System Verification Challenges
• ARM SoC DV Methodology
• ARM SoC Test bench Construction
• Conclusion
• Q&A
7 July 2008
14 March 2
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.
7 July 2008
14 March 3
ARM Based SoC Architecture
Debug & Trace
Test I/F
ARM Boot ROM Controller
ARM Core
Boot Config
High Speed
Pheripheral
PLL
External Bus
Interface
TIMER
ARM Interconnect
Memory SubSystem On Chip
Memory Bridge UART
DMA
Controller DDR Cntrl SRAM Cntrl
I2C
GPIO
Low Speed
Pheri pheral
7 July 2008
14 March 4
ARM SoC DV Methodology
This session describe the current verification methodology
used in SoC verification.
Formal Verification
Hardware Software Co Verification
FPGA Prototyping
7 July 2008
14 March 5
Formal Verification
Formal verification is a systematic process that uses
mathematical reasoning to verify the design.
Formal verification works algorithmically and
exhaustively explores all possible input values over
time.
It is sometimes difficult to figure out how stimulate the
design or create multiple scenarios to high
observability to do that formal will come into the
picture.
7 July 2008
14 March 6
Formal Verification
• Typical Formal Verification Flow-1
ARM Core
ARM Interconnect(PL301)
IP IP
7 July 2008
14 March 7
Formal Verification
• Typical Formal Verification Flow -2
ARM Core
Master side Port
binding
Model
ARM Interconnect(PL301)
Score
Checking
engine Board
Slave side Port binding
IP
7 July 2008
14 March 8
Formal Verification
• Below is the technique to verify the AXI interface
using formal verification tools
– Construct the CSV file to describing the registers.
– Runs the conversation script to generate the SVAs.
– Bind the proof kit to DUT, run the tools to read DUT and
SVAs.
– Prove and Analyse the tool results and logs.
7 July 2008
14 March 9
Formal Verification
Property Check
• Develop a formal specification of the AXI protocol.
Various kinds of components
>1 Masters
Slave(s)
Example:-
property (@(posedge ACLK) disable iff (!ARESETn)
(ARVALID) |=>##n ( RVALID);
End property;
7 July 2008
14 March 10
Formal Verification
• Example: Connectivity/Integrity check
connect {clk_in} "CORTEX.CLK" \
connect {clk_out} "SOC.CLK" \
… …
… …
… …
connect {valid_in} "CORTEX.AWVALID &&
CORTEX.AWREADY“ \
connect {valid_out} "SOC.AWVALID &&
SOC.AWREADY"
7 July 2008
14 March 11
Formal Verification
Limitations of Formal
Size limit
Not always feasible
Good for control checking but not for data
7 July 2008
14 March 12
Hardware Software Co Verification
In SoC verification, co-simulation provide the facility to
verifying hardware and software functionality together.
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 engineer to access hardware design to integrate
software functionality with hardware.
Hardware engineer by providing additional stimulus.
7 July 2008
14 March 13
Hardware Software Co-Verification Flow
Software Environment Hardware Environment
SW Tools
(Compiler, Linker,
Debugger) HDL Simulation
Tools
Executable Object
file DUT
Memory Model
Output for debugger
tools
7 July 2008
14 March 14
FPGA Prototyping
It allows faster simulation and close to real time operation
performance which would help in identifying bugs.
Comprehensive Verification, Integrated hardware-software
testing.
Provides rapid debug capability through JTAG and
specialized debug infrastructure which is built in to the
FPGA.
7 July 2008
14 March 15
FPGA Prototyping
• Microprocessor evaluation board with logic simulation
Inter-Processor
Communication
(socket) Logic Simulation
BFM
Microprocessor
With Hardware
evaluation board
Design
Bus Transaction
read/write
7 July 2008
14 March 16
FPGA Prototyping Limitations
•Many FPGAs are required for SoC partitioning, leading to prototype
system complexity
•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 and hence multiple iterations may be required to narrow down to
the specific bug.
7 July 2008
14 March 17
ARM SoC Test Bench Construction
• The system verification environment planned in a way
such that it is able to classify the functionality in terms of
active and passive components
SoC Verification Env
Emulation Pins
TB
ARM
ARM
ARM TB
Core
Core configuration
Core other Pins
Active
ActiveBFM
ActiveBFM
BFM
Resets
DUT
Active
ActiveBFM
BFM
clocks Passive BFM
7 July 2008
14 March 18
Active component
An active component can be synthesizable or behavioral,
typically modeling functionalities required for supporting
the DUT. Active component can interact with DUT and
influences behavior of DUT.
Passive component
Passive components are observers in Test bench which
does not influence DUT behavior. Passive component are
usually behavioral model, extracting information and
validating the correctness of design behavior.
7 July 2008
14 March 19
Conclusion
As with the growing complexity of SoC designs,
verification strategies should evolve and mature
enough to handle the complex challenges of identifying
bugs and functional issue. A robust verification
environment planning which starts as early as the
design phase coupled with thoughtful usage of latest
tools and verification technologies, which help in
achieving the desired quality objective.
7 July 2008
14 March 20
Q&A
Q&A
7 July 2008
14 March 21
