Retargetability With SCE-API 1.0

1. Retargetability With SCE-API 1.0 Per Bojsen Accellera ITC Meeting 11/14/03 San Jose, CA

2. Outline • Background • Retargetability goals • Retargetable transactors using SCE-API • Some results • Summary

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

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

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

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

7. O U T P U T S C H E D U L E R Input-0 IP-0 Input-1 Engine_0 OP-0 Input-2 Controller IP-1 Engine_1 Engine_2 Input-3 OP-1 IP-2 Engine_3 IP-3 Network SoC Output-0 Output-1 CPU Interface Pkt MEM Arbiter ARM Core Addr decoder AHB -1 AHB -2 Interrupt Control DMA AHB-APB Bridge DMA APB USB 2.0 Memory NetworkSOC

8. O U T P U T S C H E D U L E R IP-0 Engine_0 OP-0 Controller IP-1 Engine_1 Engine_2 OP-1 IP-2 Engine_3 IP-3 NSoC Verification Environment C Side HDL side BFM IP-0 Xactor IP-0 BFM OP-0 BFM IP-1 Xactor IP-1 BFM OP-1 BFM IP-2 Xactor IP-2 Xactor IP-3 BFM IP-3 Peek n Poke CPU Interface Pkt MEM Arbiter Xactor 0P-0 ARM Core Addr decoder SVC BFM ARM-AHB AHB -1 Xactor 0P-1 AHB -2 Interrupt Control DMA AHB-APB Bridge SVC ARM DMA APB SVC USB USB 2.0 Memory NetworkSOC Xactor P n P SVC BFM USB

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

10. PREP™ 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%)

11. PREP™ 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 …

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

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

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

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

16. Transactors 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

17. XIF 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

18. Benefits 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

19. Current 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

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

21. Software 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

22. Emulation Speedup Examples

23. 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 • SCE-API’s high-performance claim is valid