1. SCE-MI Meeting 1 San Jose’, 14 th Nov 2003 1 Author: Andrea Castelnuovo SCE-MI Integrating Emulation in a system level design methodology San Jose’, 14/11/2003 Author: Andrea Castelnuovo Dynamic Verification Team Company STMicroelectronics

2. SCE-MI Meeting 2 San Jose’, 14 th Nov 2003 2 Author: Andrea CastelnuovoSummary Transaction level modeling The Interoperability Gap SCE-MI: where, when Some use models Expected Performances Conclusions

3. SCE-MI Meeting 3 San Jose’, 14 th Nov 2003 3 Author: Andrea Castelnuovo SoC Simulation for Embedded SW Development The Problem –Need SoC simulation platform even before RTL –Need simulation speed > 1000x faster than RTL –Need represent concurrency, interrupts etc –Cycle-Accurate (CA) model not appropriate Solution: Transaction-Level Model (TLM) Courtesy of F Ghenassia

4. SCE-MI Meeting 4 San Jose’, 14 th Nov 2003 4 Author: Andrea Castelnuovo Transaction Level Modeling Reference system model, including tesbench environment Fast executable description for a system under development Register accurate description for early and consistent software development Courtesy of F Ghenassia

5. SCE-MI Meeting 5 San Jose’, 14 th Nov 2003 5 Author: Andrea Castelnuovo A single SoC/IP executable reference model Single reference model enables –Rationalizing modeling efforts –Consistency between developments –Communication between teams TLM model algorithm teamdesign teamsoftware teamverification team Courtesy of F Ghenassia

6. SCE-MI Meeting 6 San Jose’, 14 th Nov 2003 6 Author: Andrea CastelnuovoMotivations Provide an infrastructure to support the Transaction Level Modeling methodology Objective of TLM models –Early embedded software development –Early (micro-)architecture analysis –Functional verification Rely on an open and tool-independent standard Activity started in ST/Central R&D in January 2000 (Frank Ghenassia) Courtesy of F Ghenassia

7. SCE-MI Meeting 7 San Jose’, 14 th Nov 2003 7 Author: Andrea Castelnuovo Transaction Level Model: Definitions A system model is composed of a set of modules, that: –Execute part of the expected system behavior thanks to one or several concurrent threads –Communicate data between each other. Each data set is called a transaction Data sets of variable size –Synchronize between each other. A system synchronization is an explicit action Courtesy of F Ghenassia

8. SCE-MI Meeting 8 San Jose’, 14 th Nov 2003 8 Author: Andrea Castelnuovo ARM 926 EJ ICache Sys.Ctrl. JTAG / Trace RTC Watchdog Timers DCache NAND/NOR FLASH Ctrl eSRAM Buffer DDR/SDRAM Controller Audio Smart Accelerator Video Smart Accelerator 16 Channel DMA Ctrl PLL1PLL2 Power Management GPIO x76 Interrupt Controller Bridge SSP UART x2 FIrDA MSP (AC97,I2S,SPI) SD/MMC I2C x2 Color LCD Ctrl Display I/F RAM/ROM Secured USB OTG Camera I/F TLM SoC development platform Courtesy of F Ghenassia

9. SCE-MI Meeting 9 San Jose’, 14 th Nov 2003 9 Author: Andrea Castelnuovo As soon as some RTL becomes available in the design flow, there is a need for interoperability between different abstraction layers. This is usually achieved by using proprietary interfaces, that allow linking two different environments. TLM: Interoperablility Transaction Any lower level decription: RTL, GATE, Cycle accurate behavioral ?API?

10. SCE-MI Meeting 10 San Jose’, 14 th Nov 2003 10 Author: Andrea Castelnuovo Aptix AXIS Celaro Specman Vera C++ TLM Coware Modeltech NcVerilog Palladium VStation Zebuvcs xsim TestBuilder Other Boxes… Interoperablility becomes an issue Interoperablility becomes an issue Other env BOOM !!

11. SCE-MI Meeting 11 San Jose’, 14 th Nov 2003 11 Author: Andrea Castelnuovo Interoperability issue Every EDA vendor possibly provides a solution to interface its technology to external environments The effort needed to create interfaces is too high compared to the business improvement that it could generate. This translates into intrisicly inefficient interfaces. To efficiently interconnect hardware emulators to a transaction level environment, the user has to build synthesizable “transactors” for each specific interface. Transactors reusability is mandatory. -> the interface must be a standard

12. SCE-MI Meeting 12 San Jose’, 14 th Nov 2003 12 Author: Andrea Castelnuovo Aptix AXIS CelaroVeraC++ SystemC Coware Modeltech NcVerilog PalladiumVStation ZebuvcsxsimOther Boxes… Specman TestBuilder SCE-MI SCE-MI: a clean approach

13. SCE-MI Meeting 13 San Jose’, 14 th Nov 2003 13 Author: Andrea Castelnuovo SCE-MI SCE-MI Use model SW RTL DESIGN End User SCE-MI infrastructure EDA Vendors Transactors designers

14. SCE-MI Meeting 14 San Jose’, 14 th Nov 2003 14 Author: Andrea Castelnuovo Transactors development Transactors provide a translation gasket between a transaction level and the cycle-accurate pin level. They are composed of two blocks: –“Software” layer: is the transactional side of the interface, which is also the master of the communication –“Hardware” layer: it contains the implementation of the functionality that transports the transactional information to the pins. Transactors have a direct impact on the performances of the interface Reusability relies on SCE-MI standard, but also requires robustness and reliability of the transactors code. Transactor designer could be: –A soft IP vendor –A verification IP vendor –The user himself –A third party or consultant –An EDA vendor

15. SCE-MI Meeting 15 San Jose’, 14 th Nov 2003 15 Author: Andrea Castelnuovo IP integration through SCE-MI: A standard interface allows fast and easy integration of IPs The most suitable implementation for each IP can be plugged into the system. Simulation frequency suitable for early software development Transaction Cycle Accurate RTL Gate SCE-MI SCE-MI and TLM

16. SCE-MI Meeting 16 San Jose’, 14 th Nov 2003 16 Author: Andrea Castelnuovo SCE-MI System Validation (1) In a system description testbenches are often a relevant part of code. A standard interface allows strong re-usability of testbenches Using the same verification environment, improves consistency and reliability Transaction RTL Gate TB SCE-MI Silicon

17. SCE-MI Meeting 17 San Jose’, 14 th Nov 2003 17 Author: Andrea Castelnuovo Example1 ARM PXP A TLM model of PXP is simulating Software can be developed on this platform Custom Hardware block can be added in the TLM description Custom Block

18. SCE-MI Meeting 18 San Jose’, 14 th Nov 2003 18 Author: Andrea Castelnuovo Example 1 As soon as mature RTL is available for the block under development, it should be integrated into the system. The same TLM model of system (software and hardware) will be connected to the RTL model of the Custom block. Performances of the co-modeling platform will be affected by two main factors: –RTL model environment, being hardware emulation or software logic simulation. –Communication channel between TLM and RTL.

19. SCE-MI Meeting 19 San Jose’, 14 th Nov 2003 19 Author: Andrea Castelnuovo Example 1: SCE-MI layer A hardware emulation platform is used to map the RTL model To build a SCE-MI based environment the user needs to: –Provide a synthesizable SCE-MI compliant transactor for the custom block specific protocol (in this example APB bus) –Provide a software layer to link TLM to APB transactor. Note: Both software and Hardware side of the transactor written for a given protocol, are re-usable in a SCE-MI context Custom Block RTL Hardware Emulator System TLM Description Transactor SCE-MI SW link SCE-MI Infrastructure

20. SCE-MI Meeting 20 San Jose’, 14 th Nov 2003 20 Author: Andrea Castelnuovo Example 1: SCE-MI transactors library Creating transactors requires an extra design and validation effort SCE-MI based transactors are platform independent, thus strongly reusable For specific protocols such as AHB, APB, STBUS, PCI, Ethernet, MMC… an SCE-MI library will allow fast and easy transactional co-emulation. System TLM Description SCE-MI SW link Hardware Emulator Custom Block RTL Transactor SCE-MI Infrastructure Custom Block RTL Transactor Custom Block RTL Transactor Custom Block RTL Transactor

21. SCE-MI Meeting 21 San Jose’, 14 th Nov 2003 21 Author: Andrea Castelnuovo Transactor is not only a BFM Transactors can also be used to monitor traffic for protocol violation issues Once a protocol-error is detected, a message is sent to the software testbench. Monitors running in hardware do not impact significantly on performances. System TLM Description SCE-MI SW link Hardware Emulator Custom Block RTL Transactor SCE-MI Infrastructure Monitor

22. SCE-MI Meeting 22 San Jose’, 14 th Nov 2003 22 Author: Andrea Castelnuovo Example2 ARM PXP TLM model of PXP system is simulating The Testbench environment is developed at TLM level as well As soon as the full system is ready at RTL level, a test environment has to be provided TB Environment (DISPLAY MODEL) Other Blocks Other Blocks Other Blocks TB Environment (Peripherals)

23. SCE-MI Meeting 23 San Jose’, 14 th Nov 2003 23 Author: Andrea Castelnuovo Example 2: SCE-MI layer A hardware emulation platform is used to map the RTL model of the whole system Synthesizable SCE-MI compliant transactors for the testbench functionalities to generate stimuli for the system Provide a software layer to link TLM to APB transactor. Both software and Hardware side of the transactor written are re-usable in a SCE-MI context RTL SYSTEM Hardware Emulator TestBench TLM Description Transactor SCE-MI SW link SCE-MI Infrastructure Transactor Display…UART

24. SCE-MI Meeting 24 San Jose’, 14 th Nov 2003 24 Author: Andrea Castelnuovo Performance Analysis The link between TLM and emulation needs to be reasonably efficient in terms of performances A performance estimation should be available before putting any effort into modeling the interface The link is implemented if the trade off between expected performance and modeling effort is acceptable

25. SCE-MI Meeting 25 San Jose’, 14 th Nov 2003 25 Author: Andrea Castelnuovo Performance Estimation The following parameters are useful to estimate performances –RTL implementation speed (emulator) –TLM speed (software env) –Activity generated by a Context switch (type of transactions) –Number of blocking actions –SCE-MI infrastructure speed

26. SCE-MI Meeting 26 San Jose’, 14 th Nov 2003 26 Author: Andrea Castelnuovo Performance Estimation (2) RTL implementation speed (emulator) –Due to the hardware speed, this is usually not the limiting factor. –Only for some particular tests, where few interactions occur between hardware and software, hardware speed could result as the limiting factor

27. SCE-MI Meeting 27 San Jose’, 14 th Nov 2003 27 Author: Andrea Castelnuovo Performance Estimation (3) TLM speed (software env) –It becomes the limiting factor when the time spent in the hardware side is lower than the CPU time between two interaction –Use of blocking statements makes this parameter heavily impacting on performances

28. SCE-MI Meeting 28 San Jose’, 14 th Nov 2003 28 Author: Andrea Castelnuovo Performance Estimation (4) Activity generated by a Context switch (type of transactions) –Depending on the implementation, the time consumed for handshaking between hardware and software might be relevant –A good estimation can be achieved by measuring the handshaking time, using a profiler

29. SCE-MI Meeting 29 San Jose’, 14 th Nov 2003 29 Author: Andrea Castelnuovo Performance Estimation (5) Blocking actions –Blocking actions cause the software to stuck, waiting for some feedback from hardware –In such a context software becomes a limiting factor –In a transaction based co- emulation approach they should be avoided Example: This read function has to return a value, after some hardware cycles: int read(int data, int addr) { Int data_read; … Serviceloop(); … Return data_read; } The software will be waiting until the data_read will be available from the hardware side.

30. SCE-MI Meeting 30 San Jose’, 14 th Nov 2003 30 Author: Andrea CastelnuovoConclusions SCE-MI provides an efficient communication layer between transaction level modeling and emulation The cost for setting up such a link is mainly in the effort to create synthesizable transactor development Standardization allows for strong reusability of transactors, across multiple platforms Thanks!