Zaiq’s Transaction API Proposal

1. Zaiq’s Transaction API Proposal v2

2. Outline • Zaiq background • SCE-API 1.0 • Next steps • Zaiq transaction API • Minor SCE-API enhancements • Summary

3. 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

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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”); }

17. 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, 1000000); }

18. Emulation Mode

19. Simulation Mode

20. 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

21. Transaction Definition

22. 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

23. Transaction Interface Timing

24. 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

25. 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;

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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