zaiq’s transaction api proposal

A Design and Verification CompanyA Design and Verification Company

Zaiq’s Transaction API

Proposal

v2

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

OutlineOutline

• Zaiq background

• SCE-API 1.0

• Next steps

• Zaiq transaction API

• Minor SCE-API enhancements

• Summary


Zaiq TechnologiesZaiq Technologies

• Founded as ASIC Alliance Corp. in 1996– Focused on:

• Solutions to the most complex design engineering problems• Best in Class engineering resources• Filling the void above traditional EDA tools

– Completed more than 400 design verification engagements

• Our business– Design & Verification Services– Verification environments– Verification Intellectual Property

• Our headquarters are in Woburn, Mass.– With offices in NH, NJ and CA


Zaiq System-Level Verification MethodologyZaiq System-Level Verification Methodology

• Zaiq’s system-level verification methodology is transaction based

• Traditionally done using simulation

• Projects range from individual blocks through single ASIC/FPGA boards with multiple components, and multi board systems to hardware/software co-verification

• Projects reuse tests and DV library code as focus shifts from block-level through chip-level to system-level

• Projects reuse transactors and other DV components from other projects

• Large projects routinely have 50–100+ transactors, e.g., 24-port Ethernet switch with uplink ports and CPU interface


Zaiq PerspectiveZaiq Perspective

• User of EDA tools such as simulators and emulators

• Need to get our projects done on time and budget

• Productivity, efficiency, and performance are key

• Reusable and quickly deployable environments are important means

• Zaiq integrates EDA tools in the PREP verification platform

• Zaiq and Zaiq’s customers benefit from standardized APIs that enable reusable and portable transactors and verification components to be created


Verification ChallengesVerification Challenges

• Today’s complex systems present significant challenges to DV

• System-level verification using simulation is slow even when using transaction-level modeling

• System-level verification using acceleration/emulation has been hampered by the lack of common APIs

• System-level verification using acceleration/emulation in vector mode has exhibited disappointing performance

• BFMs written for different environments/tools/emulators are not portable/easily reusable

• No market for reusable and portable BFMs and verification components exists


SCE-API 1.0 FeaturesSCE-API 1.0 Features

+ Important step in the right direction to providing seamless transition between simulation and emulation

+ Enables portability across emulator platforms

+ 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’


Next StepsNext Steps

• Address real-world transactor implementation challenges by standardizing common solutions

– Collect commonly implemented infrastructure on top of SCE-API 1.0 and standardizing to enable re-use

– Capturing and standardizing additional usage details to allow easier movement or interoperability

• Should build upon the current SCE-API by adding a new layer

– Add new capabilities without losing or re-inventing the SCE-API 1.0 benefits

– Maintain backwards compatiblity


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

• 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


Common Transactor ComponentsCommon Transactor Components

• Common parts of transactors such as transaction segmentation/reassembly and clock control can be standardized

• With a standard interface BFMs can be made portable across simulators and emulators

• Future enhancements can be implemented transparently to all BFMs

• Hide SCE-API’s uncontrolled clock from the user because there is no direct equivalent in simulation and it complicates BFM development to have two types of clock


PortabilityPortability

• Verification IP (transactors, BFMs, tests and DV environment library code) must work on multiple simulation and emulation platforms without change

• Tests and test fragments must work across multiple transactors when they are functionally similar

• Verification IP from different sources must be interoperable and interchangable

• Support for multiple high-level verification languages (e.g. C, C++, SystemC, SystemVerilog, etc.) through consistent APIs


Transaction API RequirementsTransaction API Requirements

• Transition seamlessly from simulation to emulation

• Behavior of tests in simulation and emulation must be identical cycle-for-cycle

• Ability to reuse synthesizable BFMs from simulation in emulation

• Ability to reuse HDL portion of testbench from simulation in emulation assuming it is synthesizable

• Common interface for BFMs to transport layer infrastructure to allow portability and interoperability

• Common software-side API to enable reusable verification environments and tests written in an HLL such as C, C++, SystemC, or SystemVerilog


Zaiq Transaction APIZaiq Transaction API

• Based on Zaiq’s PREP and TestBenchPlus technology

• TestBenchPlus is a transaction-based transport layer between C/C++ and Verilog/VHDL

• Has two major modes: simulation and emulation

• Simulation mode supports all major simulators

• Emulation mode is based on SCE-API and currently validated and supported on the Aptix System Explorer emulator

• Software side is threaded with threads corresponding to transactors and scheduling controlled by hardware side

• Tests are written in a style similar to diagnostics software


Transaction APITransaction API

• Transaction definition– Transactions are defined as a data structure with certain fields which

specify transaction protocol data and meta-data– Protocol data includes commonly used fields such as address and data– Meta-data includes transactor configuration/status data, error status, and

transaction start and end times

• High-level language transaction API– Callable from C, C++, SystemC– SystemVerilog support is planned

• Transport mechanism– Supports simulation and emulation mode– Supports Verilog and VHDL

• Hardware-side transaction interface– Standard interface for BFMs


Use ModelUse Model

• User– Writes tests– Runs tests in simulation and/or emulation mode– Tests are written in a high-level software (C, C++) or verification language

(SystemC, SystemVerilog)– Tests have parallel contexts for each DUT interface that must be driven in

parallel– Tests are written in a style similar to diagnostics software

• Modeler– Develops synthesizable BFMs

• Verification Component Developer– Develops complete DV components including BFMs, transactors, library

routines, and test suites


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);}


Emulation ModeEmulation Mode

Tra

nsac

tion

Leve

l Mod

elin

g A

PI

SCE-MI Transport

System Under Test

Context Context Context

Transaction Level Modeling API - HLL API

BFM

SCE-API

BFM BFM

TransactionInterface

OutIn

Clo

ckC

ontr

ol


OutIn

Clo

ckC

ontr

olTransaction

Interface

OutIn

Clo

ckC

ontr

ol

Transaction Level Modeling API - HDL Transaction Interface

Main ContextTest


Simulation ModeSimulation Mode

Tra

nsac

tion

Leve

l Mod

elin

g A

PI

System Under Test

Context Context Context


BFM BFM BFM


Main ContextTest

Simulator API - Verilog PLI,VHDL FLI, etc.





TransactorsTransactors

• Translates between transactions and protocol specific bus cycles

• Transactions are untimed representations of the protocol specific bus cycles

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

• Transactor driver– Software side transactor-specific

library code– Is simple or non-existent for many

common transactors because transaction API provides most common functionality

Tra

nsac

tion

Leve

lM

odel

ing

AP

I

SCE-MI Transport

System Under Test

Context Context


BFM

SCE-API

BFM


OutIn

Clo

ckC

ontr

ol


OutIn

Clo

ckC

ontr

ol


Main ContextTest

Driver


Transaction DefinitionTransaction Definition

Operation code

Code that determines how the rest of the fields of the transaction operation data are to be interpreted

Address Generalized address that can be considered out-of-band information

Data Transaction data. This is an arbitrary sized block of bytes

Size The size of the data field as measured in number of bytes

Status Status information associated with transaction

Interrupt Interrupt vector used by the hardware side to indicate interrupts

Reset Reset information used by the hardware side to indicate hardware reset

Idle count Idle count used to indicate the number of cycles the transactor should idle


Transaction InterfaceTransaction Interface

• Provides a Standard Interface for BFMs to the Infrastructure

• Encapsulates The SCE-MI Uncontrolled Clock

• Clocked by a User-Specified Controlled Clock Typically Brought in Via the Transactor Interface from the Testbench

• Transaction Data is Streamed With Flow Controlled by the BFM

• Transaction Data Port Width is Parameterized

• Handles Idling and Sleeping: BFM Sees Only NOP Commands

• Handles Configuration and Status Registers for BFM

• Supports Software and Hardware Initiated Transactors

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


Transaction Interface TimingTransaction Interface Timing

BFM_Clock

BFM_XRun

XIF_GetOperation

XIF_GetData

BFM_GetDataNext

BFM_PutStatus

T1 T2 T3 T4 T5 T6 T7 T8

O1 O2 O3 O4 O5 O6 O7 O8

D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11


ContextsContexts

• Transactors are associated with independent contexts in the software side

• Contexts provide parallel threads of execution mirroring the parallelism in the hardware side

• Context scheduling is controlled by the hardware side– In simulation mode scheduling is controlled by the simulator– In emulation mode scheduling is controlled by the hardware

• Scheduling is non-preemptive

• Contexts can safely share global variables including pointers without requiring semaphores or mutexes

• Contexts can synchronize using events


HLL API Transaction Data StructureHLL API Transaction Data Structure

typedef struct{ u_int32 opcode; u_int64 address; void * read_data; void * write_data; /* . . . */ u_int32 size; u_int32 status; u_int32 interrupt; /* . . . */ u_int64 start_time; u_int64 end_time; u_int32 buffer_size;} SIM_Transaction;


HLL API Transport FunctionsHLL API Transport Functions

• SIM_Attach()– Associates named HDL transactor instance with C/C++ transactor function– Creates context for the transactor function to run in– Allows parameters to be passed through to the transactor function

• SIM_GetTransaction()– Returns handle to transaction structure associated with current context

• SIM_SendTransaction()– Sends transaction to the current transactor and blocks until transactor

replies– Only the current context is blocked


HLL API Context SynchronizationHLL API Context Synchronization

• SIM_WaitEvent()– Wait for named event to be set, i.e., signaled– Does not wait if event has already been signaled

• SIM_SetEvent()– Set/signal named event– Will release the next waiter in line

• SIM_WaitEventState()– Wait for an event to acquire a given state– State values are 32-bit integers

• SIM_SetEventState()– Set a named event to a given state and release all waiters that are waiting for this

state

• SIM_WaitTest()– Launches attached contexts– Used by main context to wait for test to finish– A named event is used by other contexts to signal test completion


HLL API Convenience LayerHLL API Convenience Layer

• SIM_Write8(), SIM_Write16(), SIM_Write32(), SIM_Write64()– Send a write transaction with a given address where data is an integer of a specific

width to the transactor– Typically used with processor-style transactors

• SIM_Read8(), SIM_Read16(), SIM_Read32(), SIM_Read64()– Send a read transaction with a given address where data is an integer of a specific

width to the transactor– Returns the data value read from the DUT by the transactor– Typically used with processor-style transactors

• SIM_Write(), SIM_Read()– General write and read transactions where the size of the data block is specified by

the user– Used for burst accesses on processor-style busses– Used for packet/frames with packet transactors


HLL API Convenience Layer Cont’dHLL API Convenience Layer Cont’d

• SIM_Idle()– Cause the transactor to idle for a given number of cycles

• SIM_Sleep()– Put transactor to sleep until woken up

• SIM_CSWrite(), SIM_CSRead()– Write and read configuration and status data to/from transactor– Zero-time operations– Used to configure BFM’s behavior, e.g., wait states, flow control

enable/disable, etc.– Used to get error and statistics information from BFM

• SIM_UserOp()– Send transaction with a user-specified opcode to the transactor and wait

for the result– Provides access to all transaction fields


HLL API MessagingHLL API Messaging

• Error and status messaging functions

• Allows tests to report errors

• Allows tests to output debugging messages

• Filtering features allows noise-level of messages to be controlled

• Useful for disabling debugging messages in regression testing


Minor SCE-API EnhancmentsMinor SCE-API Enhancments

• Define the names of C/C++ header files– Requirment for making application code portable– Proposal

• C++ header file: SceMi• C header file: SceMi.h


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

• Built on SCE-API 1.0

• Proven on major simulators and the Aptix System Explorer emulator

zaiq’s transaction api proposal

Documents