1410 SoC Verification 2013 1v0

7/24/2019 1410 SoC Verification 2013 1v0

1/24

TKT-1410 Suunnittelun varmennus

SoC testaus

2013


2/24

What is SoC?

SOC is an integrated circuit that forms an electronicsystem, which is usually programmable to a degree

It may contain digital, analog, mixed-signal and radio-

frequency 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)


3/24

A Possible SoC Architecture

Low

-speedperipheralbus

H

igh-speeddatabu

s

CPU

H

igh-speeddatabu

s

CPU

High-speed memory bus

Internal

MemoryExt Mem

I/F

Display

GPU

Camera

I/F

Graphics

Accelerator

BridgeBridge

InternalMemory

USB

I/F

Ethernet

I/F

DMA

Keyboard

I/F

Touchscr

I/F

AudioI/F

InternalMemory

Generic

I/O


4/24

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 acomponent-specific testbench

Connectivity, interoperation and system functionality

must be tested on system level

Due to multiple processing elements, software driventesting is necessary


5/24

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


6/24

Interconnect Verif ication

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)


7/24

Interconnect Verif ication Setup

Low

-speedperipheral

bus

H

igh-speeddatabu

s

Master

H

igh-speeddatabu

s

Master


Memory

StubSlave

Slave

Master

Slave

Master

BridgeBridge

MemoryStub

Slave

Slave

Master

Slave

Slave

Slave MemoryStub

Slave


8/24

Interconnect Verif ication 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


9/24

Interconnect Verif ication Process

Configurable traffic generators are used to representdata 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 trafficscenarios

End-to-end channel management


10/24

Memory Subsystem Verification

Verifying memory management and configuration, notthe physical memory arrays

Requires interconnect model

Master traffic generators must have direct access to

all bus segments that have memory componentsdirectly connected

Testing different operation and addressing modes

Single data and burst mode

Different address mappings MMU functionality

Cache coherency testing


11/24

Memory Subsystem Verification

Setup

Low-speed

peripheralbus

High-sp

eeddatabus

Master

High-sp

eeddatabus

Master


InternalMemory

BridgeBridge

Internal

Memory

Internal

Memory

Ext MemI/F

Memory

Stub


12/24

Memory Subsystem Verification Process

Test setup requires enough masters to reach everymemory component

Masters scan memory address ranges in different

address mapping and access pattern modes

Operating mode testing (burst, single, etc.) verifies thebus 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


13/24

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 realisticinformation, 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


14/24

Communication Interface Verification

Setup

Low-sp

eedperipheralbu

s

High

-speeddatabus

Master

High

-speeddatabus

Master


Camera

VIP

CameraI/F

BridgeBridge

USB

VIP

USB

I/F

EthernetI/F

Keyboard

I/F

TouchscrI/F

Audio

I/F

Generic

I/O

MemoryStub

Ethernet

VIP

Memory

Stub


15/24

Communication Interface Verification

Process

Master components initialize register configurations ofinterface 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


16/24

Verification IP

Verification IP is a standalone plug and playverification 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 themfor 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 testcompleteness


17/24

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


18/24

Software Driven Verification

Processor based designs must run at least boot-uptests

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


19/24

Software Driven Verification Setup

Low

-speedperipheralbus

H

igh-speeddatabu

s

Virtual

CPU

H

igh-speeddatabu

s

Virtual

CPU


Memory

StubExt Mem

I/F

Display

Virtual

GPU

Camera

I/F

Graphics

Accelerator

BridgeBridge

MemoryStub

USB

I/F

Ethernet

I/F

DMA

Keyboard

I/F

Touchscr

I/F

AudioI/F

MemoryStub

Generic

I/O


20/24

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


21/24

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 adesign methodology that merges into multiple phases

of design flow

Requirement capture

Specification

Hardware verification and validation

Software development and integration

System validation


22/24

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 intoUVM component with configurable interfaces

Integrate ESL signal generators in UVM streams

Embed ESL models into scoreboards as reference models


23/24

Reusing ESL models in HW Verification

(2)

Use abstract simulation models as much as possibleto speed up simulation

UVM/OVM provide capability to switch between different

implementations of component

Use as high abstraction level as possibleOnly 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


24/24

Summary

SoC verification expects that a thorough block-levelverification 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

1410 SoC Verification 2013 1v0

Documents