TKT-1410 Suunnittelun varmennus
SoC testaus
2013
What is SoC?
SOC is an integrated circuit that forms an electronic
system, which is usually programmable to a degree
It may contain digital, analog, mixed-signal and radiofrequency functions on a single chip substrate
SoC typically contains
Processors subsystem(s)
Many (possibly hundreds of) memory subsystems
Interface(s) for external memory
High-speed on-chip interconnect subsystem(s)
External communication interface(s)
On-chip power and error monitoring and management
subsystem(s)
A Possible SoC Architecture
Generic
I/O
USB
I/F
Ethernet
I/F
Display
DMA
Graphics
Accelerator
CPU
CPU
High-speed memory bus
Internal
Memory
Ext Mem
I/F
High-speed data bus
Touchscr
I/F
Internal
Memory
Bridge
High-speed data bus
Keyboard
I/F
Low-speed peripheral bus
Audio
I/F
Bridge
Internal
Memory
GPU
Camera
I/F
What Makes SoC Verification Different?
SoC follows the rules of system test:
System level functionality
Correct connectivity between the blocks
Interaction between the blocks
Each component is individually tested with a
component-specific testbench
Connectivity, interoperation and system functionality
must be tested on system level
Due to multiple processing elements, software driven
testing is necessary
SoC Verification Tasks
Interconnect tests
Connectivity
Configuration and parameterization
Arbitration and throughput
Memory subsystem tests
Address ranges and mapping
MMU and memory interface
Communication interface tests
Software driven tests
Register tests
Boot-up sequence
Interrupts
Interconnect Verification
Normally the first verification task in SoC verification
Connectivity
Correctness of wiring
Address mapping
Topology correctness in NoC architectures
Configuration and Parameterization
Allowed topologies
Different parameter combinations
Arbitration and throughput
All allowed arbitration schemes
Multi-master configurations
Maximum load (congestion management pressure test)
Interconnect Verification Setup
Bridge
Slave
Slave
Slave
Master
Master
Slave
Master
Master
High-speed memory bus
Memory
Stub
High-speed data bus
Slave
Memory
Stub
High-speed data bus
Slave
Low-speed peripheral bus
Slave
Bridge
Memory
Stub
Master
Slave
Slave
Interconnect Verification Setup
Interconnect subsystem is DUT
All components initiating communication are replaced
by master traffic generators (requesters)
Processors, DMA controllers, etc.
Generate statistically distributed requests to slaves
All slave components are replaced by
parameterizable slave traffic generators (responders)
No real functionality, but respond to requests with correct
amount of data or command acknowledgement
Memories replaced by functional models
No real data storage needed (except for power verification)
Responding with right amount of data
Worst case switching patterns 010101... for physical STA
Interconnect Verification Process
Configurable traffic generators are used to represent
data traffic in different use cases
Multiple traffic scenarios
Multiple interconnect configurations
Performance testing
Register and configuration settings can be done with
UVM register class or with a specific configuration
master component
Arbitration and throughput tests using different traffic
scenarios
End-to-end channel management
Memory Subsystem Verification
Verifying memory management and configuration, not
the physical memory arrays
Requires interconnect model
Master traffic generators must have direct access to
all bus segments that have memory components
directly connected
Testing different operation and addressing modes
Single data and burst mode
Different address mappings
MMU functionality
Cache coherency testing
Memory Subsystem Verification
Setup
Bridge
Master
Master
High-speed memory bus
Internal
Memory
Ext Mem
I/F
Memory
Stub
High-speed data bus
High-speed data bus
Low-speed peripheral bus
Internal
Memory
Bridge
Internal
Memory
Memory Subsystem Verification Process
Test setup requires enough masters to reach every
memory component
Masters scan memory address ranges in different
address mapping and access pattern modes
Operating mode testing (burst, single, etc.) verifies the
bus interface and internal access logic of the memory,
but not the memory array itself (except in case of
static memory)
External memory interface needs memory stub
Test MMU with most probably used parameter
configurations
Verifying Communication Interfaces
Communication interface verification needs
Interconnect to reach interface components
Master component capable of controlling interfaces
Memory stubs for testing internal DMA controllers
Test components to stimulate interface with realistic
information, e.g. USB data, keyboard signal, camera signal
Verification IP (VIP)
Pre-defined and tested data generator for standard interface
Verification focuses on
Parameterization through register interface
Data transfer to/from interface
Interaction between interface and other components, e.g.
DMA functionality
Communication Interface Verification
Setup
Generic
I/O
USB
I/F
Ethernet
I/F
Ethernet
VIP
Memory
Stub
Master
Master
High-speed memory bus
High-speed data bus
Touchscr
I/F
USB
VIP
Bridge
High-speed data bus
Keyboard
I/F
Low-speed peripheral bus
Audio
I/F
Bridge
Memory
Stub
Camera
VIP
Camera
I/F
Communication Interface Verification
Process
Master components initialize register configurations of
interface components
VIPs generate traffic and analyze output of the
interface blocks
Simple I/O interfaces are driven with streams
DMA transfers are tested using memory stubs
Verification IP
Verification IP is a standalone plug and play
verification component that enables verification of the
DUT at block, subsystem and SoC level
VIP can act as a Bus Functional Model (BFM) to drive
DUT signals or monitor the signals and validate them
for correctness and data integrity
It may have a set of protocol checkers and test
scenarios to confirm compliance with the standards or
cover groups identifying corner cases and test
completeness
Verification IP (2)
VIP is always target or standard specific
The common VIPs available include
Mobile Industry Processor Interface (MIPI) protocols like DSI,
CSI, HSI, SlimBus, Unipro, DigRF & RFFE
Bus protocols like AXI, AHB, APB, OCP & AMBA4
Interfaces like PCIexpress, USB2.0, USB3.0, Interlaken,
RapidIO, JTAG, CAN, I2C, I2S, UART & SPI
Memory models & protocol checkers for SD/SDIO, SATA,
SAS, ATAPI, DDR2/DDR3, LPDDR etc
Software Driven Verification
Processor based designs must run at least boot-up
tests
Processors are replaced with cycle accurate virtual
models (core of an instruction set simulator, ISS)
Internal memories are replaced with memory stubs
Processor models run real compiled SW images
Test limited to boot sequence and peripheral
initialization
Multiple use cases and setup scenarios
I/O optimized to the required minimum
Software Driven Verification Setup
Generic
I/O
USB
I/F
Ethernet
I/F
Display
DMA
Graphics
Accelerator
Virtual
CPU
Virtual
CPU
High-speed memory bus
Memory
Stub
Ext Mem
I/F
High-speed data bus
Touchscr
I/F
Memory
Stub
Bridge
High-speed data bus
Keyboard
I/F
Low-speed peripheral bus
Audio
I/F
Bridge
Memory
Stub
Virtual
GPU
Camera
I/F
System-Level Design and HW Verification
Electronic System Level Design (ESL)
Methodology that utilizes high-level programming languages
and multiple abstraction levels to model system architecture
and functionality with appropriate accuracy
Abstract modeling with SystemC, C++, Matlab, etc.
...to increase comprehension about a system, and to
enhance the probability of a successful implementation of
functionality in a cost-effective manner
ESL model of target hardware is aimed at early
functional and architectural simulation
High simulation speed for functional verification
Complete hardware functionality with bit accurate
implementation
Timing modeling with required accuracy
System-Level Design and HW Verification
(2)
ESL model enables verification and validation of
Hardware functionality
Interconnect throughput and arbitration
HW specification
ESL is NOT an additional design phase It is a
design methodology that merges into multiple phases
of design flow
Requirement capture
Specification
Hardware verification and validation
Software development and integration
System validation
Reusing ESL models in HW Verification
Most ESL models are written in SystemC/C++
Embedding ESL models into SystemVerilog is easy
Major SystemVerilog simulators support SystemC
Integrating ESL models into HW testbench
Use agent technology to embed functional TLM model into
UVM component with configurable interfaces
Integrate ESL signal generators in UVM streams
Embed ESL models into scoreboards as reference models
Reusing ESL models in HW Verification
(2)
Use abstract simulation models as much as possible
to speed up simulation
UVM/OVM provide capability to switch between different
implementations of component
Use as high abstraction level as possible Only DUT MUST
be RTL
Which HW components can be replaced with ESL
Processors
Interconnect (except in interconnect test!)
Memories
Interface peripherals
Use factory to switch between implementations
Summary
SoC verification expects that a thorough block-level
verification is done separately
SoC-level verification focuses on
system level HW functionality
connectivity
interaction between the blocks
Typical SoC-level tests are
Interconnect tests
Memory subsystem tests
Communication interface tests
Software driven tests
ESL models can be heavily reused in verification
