A Design and Verification Company Zaiq’s Transaction API Proposal v2

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 2Zaiq’s Transaction API Outline Zaiq background SCE-API 1.0 Next steps Zaiq transaction API Minor SCE-API enhancements Summary

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 3Zaiq’s Transaction API Zaiq 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 4Zaiq’s Transaction API Zaiq 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 5Zaiq’s Transaction API Zaiq 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 6Zaiq’s Transaction API Verification 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 7Zaiq’s Transaction API SCE-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’

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 8Zaiq’s Transaction API Next 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 9Zaiq’s Transaction API Transactor 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 10Zaiq’s Transaction API Common 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 11Zaiq’s Transaction API Portability 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 12Zaiq’s Transaction API Transaction 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 13Zaiq’s Transaction API Zaiq 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 14Zaiq’s Transaction API Transaction 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 15Zaiq’s Transaction API Use 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 16Zaiq’s Transaction API Sample 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”); }

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 17Zaiq’s Transaction API Sample 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, ); }

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 18Zaiq’s Transaction API Emulation Mode

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 19Zaiq’s Transaction API Simulation Mode

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 20Zaiq’s Transaction API Transactors 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 21Zaiq’s Transaction API Transaction Definition Operation code Code that determines how the rest of the fields of the transaction operation data are to be interpreted AddressGeneralized address that can be considered out-of-band information DataTransaction data. This is an arbitrary sized block of bytes SizeThe size of the data field as measured in number of bytes StatusStatus information associated with transaction InterruptInterrupt vector used by the hardware side to indicate interrupts ResetReset information used by the hardware side to indicate hardware reset Idle countIdle count used to indicate the number of cycles the transactor should idle

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 22Zaiq’s Transaction API Transaction 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 23Zaiq’s Transaction API Transaction Interface Timing

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 24Zaiq’s Transaction API Contexts 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 25Zaiq’s Transaction API HLL 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;

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 26Zaiq’s Transaction API HLL 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 27Zaiq’s Transaction API HLL 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 28Zaiq’s Transaction API HLL 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 29Zaiq’s Transaction API HLL 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 30Zaiq’s Transaction API HLL 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 31Zaiq’s Transaction API Minor 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

© 2003 Zaiq Technologies, Inc. All Rights Reserved. 32Zaiq’s Transaction API Summary 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