2. A Breakthrough Common Emulation API 15th November 2001 SCE-API

3. SCE-API Consortium, 2001 Outline SCE-API Objectives Members History & Roadmap Status The SCE-API 1.0 Modeling Interface (SCE-MI) Foundational Concepts Description Cell Phone Example Summary

4. SCE-API Consortium, 2001 The SCE-API Consortium The Standard Co-Emulation API (SCE-API) Consortium is a group of EDA customers and EDA vendors dedicated to the creation of a breakthrough high-performance common emulation API. The founding members are Aptix, CoWare, IKOS Systems, Mentor Graphics, STMicroelectronics, Synopsys, and TransEDA.

5. SCE-API Consortium, 2001 Emulation User Problems to be Solved by SCE-API All emulators on the market today have proprietary API’s. Restricts the availability of emulation solutions to users. Leads to low productivity and low ROI for emulation users who build their own solutions. The emulation ‘API’s’ which exist today are oriented to gate-level and not system-level verification. Users need an API which takes full advantage of emulation performance. Models written to emulation APIs do not run in simulation.

6. SCE-API Consortium, 2001 Emulation Supplier Problems to be Solved by SCE-API Users are reluctant to invest in building applications on proprietary API’s. Traditional simulator API’s like PLI and VHPI slow down emulators. Third parties are reluctant to invest in building applications on proprietary API’s.

7. SCE-API Consortium, 2001 C-based models Emulator Models Transaction Cycle Event UntimedTimed Where SCE-API Fits in the Modeling World RTL Gate Testbenches HW/SW PLI, OMI, FLI, SWIFT System Accuracy Abstraction SCE-API

8. SCE-API Consortium, 2001 SCE-MI A message passing interface Designed with system level communication in mind  C/System Design vs HDL  System Transactions vs Pin Events Simple terminals Multiple channels Designed for low latency and high bandwidth Up to full emulation speeds (1 MHz+) Based on IKOS’ ‘Co-Modeling’ technology

9. SCE-API Consortium, 2001 SCE-MI Bridges high-abstraction models to models with implementation detail ‘Untimed’ to ‘Timed’ bridging Reduces communications overhead between models Optimized for system-level transactions Cycle accurate models are possible with performance between that of transaction and PLI-like models. Allows increased performance up to full emulation speeds Supports multiple execution engines emulation simulation cycle and event

10. SCE-API Consortium, 2001 Applications of SCE-MI Software model to emulator or simulator interface Software model to software model interface Software model examples C/C variant models  E.g. SystemC Intelligent testbenches Processor/DSP ISS models HDL simulators

11. SCE-MI Foundational Concepts

12. SCE-API Consortium, 2001 Emulator Workstation System Model or Testbench DUT or Portions of the System IKOS Co-Modeling Concept BehaviorRTL Transaction Processing Transactions Per pin cycle accurate data Communications Overhead HW/SW Partition Point Control & Data Control

13. SCE-API Consortium, 2001 Co-Modeling Implementation Workstation Software Models RTL & Gate Models Co-modeling Interface EmulatorWorkstation RTL & Gate Models Software Models Implementation C Adapter SCE-MI SW Side SCE-MI HW Side RTL Transactor User View Emulator

14. SCE-MI Description

15. SCE-API Consortium, 2001 SCE-MI Functionality Multichannel Communication Multiple point to point connections between multiple C++ models running on a workstation and RTL models running on emulator. Distributed Clock Control Allows clock control to be distributed between multiple RTL models.

16. SCE-API Consortium, 2001 SCE-MI Run-Time Components

17. SCE-API Consortium, 2001 Communication Paradigm Transactors communicate with C models through Message Ports. A message port has a hand shake and a message. Message Ports are represented on the C side by Message Port Proxy Objects. C models send by function call. C models receive by call back. SCE-MI is unaware of thread structure. There is a ‘virtual channel’ between a message port and its message port proxy. There are flow control primitives for this virtual channel

18. SCE-API Consortium, 2001 Message Input Port A message input port has a dual-ready handshake, and a message. Dual ready handshake works just like the PCI IRDY, TRDY handshake. When both handshake signals are true on a given clock cycle, data moved. SW Side TransmitReady ReceiveReady Transactor Side Message

19. SCE-API Consortium, 2001 Message Input Port Proxy The MessageInputPortProxy object is the workstation counterpart to the message input port. The MessageInputPortProxy object is constructed based on the name of the MessageInputPort. It allows two types of functionality: Send a message.  MessageInputProxy::send(MessageData &data, scemiEC *ec); Flow control / Deadlock avoidance The C model can Receive a call back when the MessageInputPort is ready for new data, based on the receiveReady signal.  Void (*isReady)(void *context);

20. SCE-API Consortium, 2001 Message Output Port A message output port has a dual-ready handshake, and a message. Dual ready handshake works just like the PCI IRDY, TRDY handshake. When both handshake signals are true on a given clock cycle, data moved. SW Side TransmitReady ReceiveReady Transactor Side Message

21. SCE-API Consortium, 2001 Message Output Port Proxy The message output port proxy is the workstation counterpart to the message output port. It is constructed based on the transactor message output port name. It provides one key functionality, receipt of message from the transactor. This is accomplished by callback. Void (*receive)(void *context, MessageData &data); A message send by the MessageOutputPort on the emulator, causes a callback to the registered receive function.

22. SCE-API Consortium, 2001 Distributed Clock Control Each participant is an equal peer in clock control. The infrastructure takes all inputs and does the clock control. Each participant indicates readiness for the next clock edge. When all participants are ready, the edge is generated and all participants are informed that it is running. For each participant, readiness and the feed back that an edge has occurred form a ‘dual-ready’ pair. Participants need not have any message input or output ports.

23. SCE-API Consortium, 2001 Clock Control Signals To each transactor the infrastructure provides three clock related signals. Uclock - the uncontrolled clock ReadyForCclock - The transactor uses this to indicate that it is ready for the next controlled edge. CclockEnabled - The SCE-MI uses this to tell the transactor that the Cclock edge is occurring. On an edge where CclockEnable is true, an edge of Cclock is occurring. SW Side ReadyForCclock CclockEnabled Transactor Side Uclock

24. SCE-API Consortium, 2001 SW Clock Advance Proxy A special clock control participant, called a SW Clock Advance Proxy or clock advancer can be built to give software explicit control over clock advance.

25. SCE-API Consortium, 2001 Service Loop ServiceLoop routine gives cycles to the interface. Can be used to integrate the API single thread environments. multithreaded environments without SCE-MI being required to know about the thread model or threading system.

26. SCE-MI Cell Phone Example

27. SCE-API Consortium, 2001 Cell Phone Experiment Experiments were run on models of a TI IS-54 US TDMA phone. This design was chosen because It is a real world design. Models exist at several levels of abstraction. The DUT is a cell phone and the environment models a channel and base station. Three configurations were used. C-only: The entire system is modeled in C using transaction based communication Transmit-RTL: The environment and receiver remain in C, while the transmitter is refined to RTL. Phone-RTL: The entire phone is refined to RTL, while the environment remains in C.

28. SCE-API Consortium, 2001 Digital Cell Phone Demo Diagram Speech Input Speech Output Channel Model On VStation Modeling Legend:: VStationC Models Modeling Legend: Receiver Transmitter SlotBits Build Convolutional Encoder Voice Cypher CRC Generator SRC Filter DQPSK Encode Interleaver Slot Construct IQ_Split Sync Correlator RxSRC DQPSK Decoder De-inter leave Slot Extract CRC Generator Vselp Extract Viterbi SlotBits Extract CoModeling Interfaces

29. SCE-API Consortium, 2001 SCE-MI Solution Architecture

30. SCE-API Consortium, 2001 Cell Phone Example Note that emulation speeds do not differ much from the speed of the high level C model. In emulation, speed is limited by execution speed of the C model, not communication. Case Simulation Time Emulation TimeGate CountEmulation Speed C Only 12 secNa Receive RTL 330 sec11 sec152657700 khz Phone RTL 700 sec13 sec393523625 khz

31. SCE-API Consortium, 2001 Cell Phone Experiment Conclusions The proposed architecture gives emulation levels of performance for combined C, RTL emulations. Models are portable between simulation and emulation. The key factors in obtaining this performance are: The use of transactions to bridge between abstract system- level models and RTL models, I.e. Transaction based modeling An efficient physical channel.

32. SCE-API Consortium, 2001 Examples and Capabilities Discussion Interface to threads Implementation in hardware Implementation in software Implementation over event platform Implementation over cycle platform Variable sized transactions