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