Retargetability With SCE-API 1.0

A Design and Verification CompanyA Design and Verification Company

Retargetability With SCE-API 1.0

Per Bojsen

Accellera ITC Meeting 11/14/03 San Jose, CA

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 2Zaiq’s Transaction API

OutlineOutline

• Background

• Retargetability goals

• Retargetable transactors using SCE-API

• Some results

• Summary


Zaiq BackgroundZaiq Background

• Verification using simulation at multiple levels

• Moved early on to C/C++ as the test language

• Pioneered transaction based verification in the mid-90s on simulators

– Reduce overhead of PLI– Free tests from having to worry about protocol details– Provide diagnostics style API to DUT– Enable portability of test code between transactors

handling similar protocols– Enable portability of test code between projects– Support software/hardware cosimulation– Support easy integration with ISS’s


PREP™ EnvironmentPREP™ Environment

• PREP™ Retargetable System Verification Environment™

– Captures experience from hundreds of projects– Builds on C/C++ verification methodology– Enables consistent verification methodology by

providing standard project and test templates– Enables reuse by providing standard APIs for common

verification tasks such as CPU accesses and packet generation and checking

– Provides standard transactor templates– Simplifies project setup by providing common makefiles

and other project support files– Supports commercial HDL simulators and allows easy

migration between HDL simulators


Sample TestSample Test

void test_1_class_X(){ u_int64 addr = 0x0; u_int32 data, i, first;

first = data = my_rand(); for (i = 0; i < 10; i++) { SIM_Write32(addr, data); save_to_my_db(addr, data); data = my_rand() & 0xffff; addr += 1; }

data = SIM_Read32(0x0); if (data != first) MSG_Error(“0x0 lost %d\n", data);

SIM_SetSiganl(“Data_Written”); SIM_WaitSignal(“Finishing_Test”;

data = SIM_Read32(0x0); if (data != first) MSG_Error(“1:0x0 lost %d\n", data);

SIM_SetSignal(TEST_COMPLETE);}

void test_1_class_Y(){ u_int64 addr = 0x0; u_int32 data; u_int32 i;

SIM_WaitSignal(“Data_Written”);

for (i = 0; i < 10; i++) { data = SIM_Read32(addr); if (data != read_from_my_db(addr)) { MSG_Error("%d scrambled\n", addr); } addr += 1; }

SIM_SetSignal(“Finishing_Test”);}


Sample Test Main FunctionSample Test Main Function

void unit_test_1(){ global_sync = Starting_Test;

SIM_Attach(“path_to_x”, test_1_class_X, 0); SIM_Attach(“path_to_y”, test_1_class_Y, 0);

SIM_WaitTest(TEST_COMPLETE, 1000000);}


Output-0

Output-1

Input-0

Input-1

Input-2

Input-3

OP-0

IP-3

IP-2

IP-0

OP-1

IP-1

OUTPUT

SCHEDULER

Engine_0

Engine_1

Engine_2

Engine_3

Controller

NetworkNetwork SOCSOC

CPU Interface

AHB -1Addr

decoderARM Core

Arbiter

AHB -2

DMAInterruptControl

AHB-APBBridge

APB

MemoryUSB 2.0

DMA

Pkt MEM

Network SoCNetwork SoC


XactorIP-0

XactorIP-1

XactorIP-2

XactorIP-3

Xactor0P-0

Xactor0P-1

SVCARM

SVCUSB

XactorP n P

BFMOP-1

C Side HDL sideC Side HDL side

BFMIP-0

BFMIP-1

BFMIP-2

BFMIP-3

BFMOP-0

SVC BFMARM-AHB

Peekn

Poke

SVC BFMUSB

Network SOC

AHB -1Addr

decoderARM Core

AHB -2

DMAInterruptControl

AHB-APBBridge

APB

MemoryUSB 2.0

DMA

CPU InterfaceArbiter

IP-3

OUTPUT

SCHEDULER

Engine_0

Engine_1

Engine_2

Engine_3

Controller

IP-2

IP-0

IP-1

Pkt MEM

OP-0

OP-1

NSoC Verification EnvironmentNSoC Verification Environment


PREP™ Emulation Support GoalsPREP™ Emulation Support Goals

• Enable retargetable verification environments–Equivalency/congruency with simulation: Tests

must yield the same results–Repeatability: Tests must yield the same results

when rerun–Reusability of code: Tests, efficiency layers,

data generation and checking code, BFMs should not change

–Transparency: To the user, running in emulation mode should be no different than running in simulation mode, except faster


PREP™ Emulation Support GoalsPREP™ Emulation Support Goals

• Speedup over emulation should be at least 100X on average to make it worthwhile–≤10X speedup does not in general warrant the

effort of mapping the DUT and testbench to an emulator

–100X speedup reduces an overnight regression suite run to a few minutes

–100X speedup appeared doable for the NSoC design given the average observed CPU time split between software side and simulator (1%/99%)


PREP™ And SCE-API 1.0PREP™ And SCE-API 1.0

• Promises to end the proliferation of emulator APIs– Only need to port PREP once

• Fits reasonably well with PREP’s transaction based verification methodology

– Provides mechanism to pass fixed-width messages between software and hardware sides

– Provides clock control mechanism that allows cycle-for-cycle control over when transactions start and end

– Provides cycle stamp mechanism to determine ‘simulation time’

• Implementations exist …


PREP™ Emulation Support SolutionPREP™ Emulation Support Solution

• Transaction based because–Simulation mode is already transaction based–Necessary to achieve performance goals

• Drives the emulator directly using SCE-API–A simulator proxy would affect performance–However, transactors and BFMs must be

synthesizable


TransactorsTransactors

• HDL module containing bus functional model (BFM) and infrastructure interface

• Translates between transactions and protocol specific bus cycles

• Transactions are untimed representations of the protocol specific bus cycles

• Transactor driver– Software side transactor-

specific library code– Is simple or non-existent for

many common transactors because transaction API provides most common functionality

Transaction Transport Layer(Bridges Softw are and Hardw are Sides)

System Under Test

Context Context

Transport Layer HLL API

Transactor Transactor

Transport Layer HDL Transaction Interface

Main ContextTest

Driver


Transactor Implementation ChallengesTransactor Implementation Challenges

• Transactions are generally variable size–Fixed-width messages do not scale well to

variable sized large transactions such as burst PCI transactions and Ethernet frames

–Handling variable sized transactions efficiently requires assembling multiple messages that represents segments of transactions

Transaction segmentation/reassembly becomes important component of transactors based on SCE-API


Transactor Implementation ChallengesTransactor Implementation Challenges

• Clock control uses common pattern–Clocks are stopped only between transactors to

allow transactions to be exchanged between software and hardware sides

–Uncontrolled clock is exposed to the transactor developer

–Unclear how uncontrolled clock maps to simulation mode

Encapsulating clock control in common interface module is desirable to simplify BFM development


Transactors In Emulation ModeTransactors In Emulation Mode

• Transport layer is SCE-API

• Transactors must be synthesizable

• Common transaction interface is used on the HDL side to provide the services not directly presented by SCE-API

– Transaction segmentation/reassembly

– Common clock control

• Transaction API is used on the HLL (software) side to support transaction segmentation/reassembly and other housekeeping items

Tra

nsac

tion

Leve

lM

odel

ing

AP

I

SCE-MI Transport

System Under Test

Context Context

Transaction Level Modeling API - HLL API

BFM

SCE-API

BFM

TransactionInterface

OutIn

Clo

ckC

ontr

ol

TransactionInterface

OutIn

Clo

ckC

ontr

ol

Transaction Level Modeling API - HDL Transaction Interface

Main ContextTest

Driver


XIF Core Common Transaction InterfaceXIF Core Common Transaction Interface

• Allows synthesizable BFMs to be used in simulation and emulation unchanged

• Provides a standard interface for BFMs to the infrastructure

• Encapsulates the SCE-MI uncontrolled clock

• Clocked by a user-specified controlled clock passed in from the BFM

• Transaction data port width is parameterized

• Handles configuration and status registers for BFM

BFM_Clock

XIF_GetData

BFM_PutData

BFM_GetDatraNext

BFM_PutDataValid

XIF_GetOperation

XIF_GetAddress

XIF_GetSize

XIF_GetStatus

BFM_PutOperation

BFM_PutAddress

BFM_Size

BFM_Status

BFM_Reset

XIF_Reset

BFM_PutCopySWToHW

BFM_PutCopyHWToSW

BFM_XRun

BFM_Interrupt

XIF_GetCSData

BFM_PutCSData

Transaction Interface BFM

Transactor

Prot

ocol

Spe

cifi

c B

us I

nter

face


Benefits of the XIF CoreBenefits of the XIF Core

• Common parts of transactors such as transaction segmentation/reassembly and clock control is implemented once and behaves in a standard way

• BFMs are portable across simulators and emulators

• Future enhancements can be implemented transparently to all BFMs

• The XIF core is portable across simulators and emulators

– Simulation support is based on Verilog/PLI and VHDL/FLI

– Emulation support is based on SCE-API


Current Limitations of SCE-API Affecting the XIF CoreCurrent Limitations of SCE-API Affecting the XIF Core

• Lack of variable length messages–SCE-MI is considering adding support for

variable length messages in a future version of SCE-API

• Uncontrolled clock does not fit well with simulation–SCE-MI is considering adding a means to hide

the uncontrolled clock from the user


Some ResultsSome Results

• Zaiq benchmarked a network processor SoC containing 550K ASIC gates plus 2.5Mbits of RAM

• Test suite of chip and system level tests contains both short directed tests and long random tests

• The relative speedup of emulation mode versus simulation mode varies from 20X on some short tests to 25,000X on other tests with most tests falling in the range of 500X to 2,000X

• Speedup varies with type and size of the design and test suite with larger speedups for larger designs and longer tests


Software Side and Emulation PerformanceSoftware Side and Emulation Performance

Let s be the time spent in the software side, h the time spent in the simulation, and N the emulation speedup of the simulation, then the maximum speedup of the test is

(s + h)/(s + h/N)

If N goes to infinity, then this reduces to

(s + h)/s


Emulation Speedup ExamplesEmulation Speedup Examples

s h s (%) h (%) NSimulation Run Time

Min Emulation Run Time

Max Speedup

10 10 50.00% 50.00% 10 20 11.000 1.826 14 30.00% 70.00% 10 20 7.400 2.706 14 30.00% 70.00% 100 20 6.140 3.266 14 30.00% 70.00% 1000 20 6.014 3.337 14 33.33% 66.67% 1000 21 7.014 2.995 14 26.32% 73.68% 1000 19 5.014 3.794 14 22.22% 77.78% 1000 18 4.014 4.482 14 12.50% 87.50% 1000 16 2.014 7.94

1000 10000 9.09% 90.91% 1000 11000 1010.000 10.89500 10000 4.76% 95.24% 1000 10500 510.000 20.59100 10000 0.99% 99.01% 1000 10100 110.000 91.82

10 10000 0.10% 99.90% 1000 10010 20.000 500.501 10000 0.01% 99.99% 1000 10001 11.000 909.18


SummarySummary

• SCE-API 1.0 enables the creation of portable, transaction-level modeling environments for emulators

• SCE-API 1.0 is usable as a building block but is not sufficient for the creation of portable/reusable/interoperable transactors

• Zaiq’s transaction API allows DV environments to run on all major simulators and SCE-API compliant emulators

• SCE-API’s high-performance claim is valid

Retargetability With SCE-API 1.0

Documents

Transcript of Retargetability With SCE-API 1.0