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