break your soc with automatically generated c test cases...test.ctest.ctest.c 6. treksoc...

Break Your SoC with Automatically Generated C Test Cases

Frederic Krampac

Senior Applications Engineer

Breker Verification Systems, Inc.

Verification Futures 2012

• The IPs are well verified → the SoC will work

• The IPs, fabric and memory subsystem are well verified → the entire flow will work

• Each IP works → software will be able to stitch them together into use cases

• Power and clock management can be verified at the IP or subsystem level

Verification Futures 2012 © 2005 - 2012 Breker Verification Systems, Inc. All rights reserved.

The Myths of SoC Verification

2

• Schedules are tight, resources are limited

• Only limited chip-level verification is performed

• System bugs found by software team or customer

– Bus/fabric bandwidth is less than predicted

– Bus bridge hangs under stress

– Access by multiple IPs reveals address decode bug

– Memory fails on concurrent access to same bank

– Clocking change during execution hangs system


The Truth of SoC Verification

3

The SoC Verification “Iceberg”


Connectivity Tests

System and Power Management

Concurrency

Coherency

IP Integration Tests

Performance Verification

System Use Cases

4

Digital Camera SoC Example

Testbench

SoCRTL CPU Image

ProcessorMemory

CameraDisplay

Controller

Fabric

Fabric

BFM

SD CardController

BFM BFM

Systemand

PowerControl

Verification Futures 2012 © 2005 - 2012 Breker Verification Systems, Inc. All rights reserved. 5

Manually Developed SoC Tests

• Manual development and maintenance

• Difficult to manage:

• Multiple threads

• Multiple processors

• Multiple memories

• Interaction with I/O ports


Connectivity Tests

System & Power Management

Concurrency

Coherency



System Use Cases

Connectivity Tests


Concurrency

Coherency



System Use Cases

Testbench

SoCRTL CPU Image

ProcessorMemory

CameraDisplay

Controller

Fabric

Fabric

BFM

SD CardController

BFM BFM

Systemand

PowerControl

Compiler

test.ctest.ctest.ctest.ctest.ctest.c

6

test.ctest.ctest.cTrekSoC

TrekSoC Automatic Self-Verifying C Test Cases

Connectivity Tests

Register / Memory Map


System Scenarios

Concurrency

Coherency


Driver Scenarios


System Use Cases

Application Scenarios

Concurrency

Coherency

Compiler


Testbench

SoCRTL CPU Image

ProcessorMemory

CameraDisplay

Controller

Fabric

Fabric

BFM

SD CardController

BFM BFM

Systemand

PowerControl

test.ctest.cevents.rc

Tre

kBo

x

mailbox

7

test.ctest.ctest.cTrekSoC

TrekSoC Automatic Self-Verifying C Test Cases

Connectivity Tests


Concurrency

Coherency



System Use Cases

Concurrency

Coherency

Compiler


Testbench

SoCRTL CPU Image

ProcessorMemory

CameraDisplay

Controller

Fabric

Fabric

BFM

SD CardController

BFM BFM

Systemand

PowerControl

test.ctest.cevents.rc

Tre

kBo

x

mailbox

SD

SoC

IPScenarioModel

Cam

8

Scenario Model for Digital Camera: Data Flow Graph


SD CardController

Read

ImageProcessorDecode

DisplayController

Display

SDCard CCD

ImageProcessor

Encode

SD CardController

WriteCamera

SDCard

9

Self-Verifying C Test Case

• TrekSoC generates automatically from the scenario models

• Well commented

• Multi-threaded

• Multi-processor

• Does mean, nasty things to try to break the SoC

• Exercises deep corner cases

// System Configuration

void configure_system (void) {

static U32 state = 1;

switch(state) {

case (0x1):

active_threads = 4; // initialize thead counter

WREG8(0x00810003, 0x80); // UART_LCR: BREAK_CONTROL=0 ...

WREG8(0x00810001, 0x00); // UART_DIVISOR_MSB: MSB=0

WREG8(0x00810003, 0x06); // UART_LCR: BREAK_CONTROL=0 ...

WREG8(0x00810001, 0x00); // UART_IER: MODEM_STATUS=0 ...

WREG8(0x00810002, 0x46); // UART_FCR: RX_FIFO_CLR=1 ...

...

// Test Thread A

void test_thread_A (void) {

static U32 state = 0x1;

switch(state) {

case (0x1):

trek_do_expect(6); // Begin Thread A

state++;

trek_do_expect(7); // Waiting for UART0_tx to be idle...

case (0x2):

if ( UART0_tx_busy == 1 ) break;

UART0_tx_busy = 1;

trek_do_expect(9); // Begin UART0 uart_fill_tx

trek_write_fifo_mem8(0x00810000, MADDR(0x00000810), 4);

state++;

trek_do_expect(10); // Poll for UART0.UART_LSR.TX_FIFO_EMPTY

case (0x3):

if (!REGTEST8(0x00810005, 0x20, 0x20)) break;

trek_do_expect(11); // ... got UART0.UART_LSR.TX_FIFO_EMPTY

state++;

Verification Futures 2012 © 2005 - 2012 Breker Verification Systems, Inc. All rights reserved. 10

Multi-Threaded, Multi-Processor C Test Case

© 2005 - 2012 Breker Verification Systems, Inc. All rights reserved. 11Verification Futures 2012 © 2005 - 2012 Breker Verification Systems, Inc. All rights reserved. 11

• Why not SoC-level UVM?– No testbench-CPU links– Virtual sequencer too complex– Full-chip simulation too slow

• Why not hand-written C tests?– No testbench-CPU links– Multi-threaded tests impossible to write by hand

• Why not just run production code?– No testbench-CPU links– Full-chip simulation even slower with CPU running code– Production is well-behaved and does not hit corner cases– Production code is rarely available before SoC tape-out


TrekSoC vs. Alternatives

System Hookup

IP Integration

Multi-Master Concurrency

Multi-CPU Interactions

Data Ordering

Cache Coherency

Virtual Memory

Clocks and Power

Asynchronous Events

Application Use Cases

Performance Analysis

12

• Standalone IP verification is not sufficient for an SoC

• TrekSoC automatically generates C test cases

– Run on the embedded processors and link to testbench

– Exercise deep corner cases and measure performance

• Scenario models are easy and natural to create

– Incremental ROI: basic tests require minimal information

– Graphs efficiently capture verification knowledge

– Graphs help internal communication and teams

• TrekSoC finds more bugs with 2-3x productivity gain

Summary

© 2005 - 2012 Breker Verification Systems, Inc. All rights reserved.Verification Futures 2012 13


Thanks for Listening!

14

break your soc with automatically generated c test cases...test.ctest.ctest.c 6. treksoc...

Documents