A Breakthrough Common Emulation API

1. A BreakthroughCommonEmulationAPI SCE-API 15th November 2001

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

3. 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. SCE-API Consortium, 2001

4. 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. SCE-API Consortium, 2001

5. 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. SCE-API Consortium, 2001

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

7. SCE-MI • A message passing interface • Designed with system level communication in mind • C/System Design vs HDL • SystemTransactions 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 SCE-API Consortium, 2001

8. 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 SCE-API Consortium, 2001

9. 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 SCE-API Consortium, 2001

10. SCE-MI Foundational Concepts

11. TransactionProcessing Behavior RTL Control & Data Control Per pin cycleaccurate data Transactions Communications Overhead HW/SW Partition Point IKOS Co-Modeling Concept Emulator Workstation System ModelorTestbench DUTorPortions of the System SCE-API Consortium, 2001

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

13. SCE-MI Description

14. 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. SCE-API Consortium, 2001

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

16. 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 SCE-API Consortium, 2001

17. 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. TransmitReady SW Side Transactor Side ReceiveReady Message SCE-API Consortium, 2001

18. 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); SCE-API Consortium, 2001

19. 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. TransmitReady SW Side Transactor Side ReceiveReady Message SCE-API Consortium, 2001

20. 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. SCE-API Consortium, 2001

21. 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. SCE-API Consortium, 2001

22. 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. ReadyForCclock SW Side Transactor Side CclockEnabled Uclock SCE-API Consortium, 2001

23. 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. SCE-API Consortium, 2001

24. 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. SCE-API Consortium, 2001

25. SCE-MI Cell Phone Example

26. Cell Phone Experiment • Experiments were run on models of aTI 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. SCE-API Consortium, 2001

27. Digital Cell Phone Demo Diagram Transmitter SpeechInput Convolutional Encoder DQPSKEncode SlotBitsBuild Interleaver ChannelModel CRCGenerator SlotConstruct SRCFilter VoiceCypher Receiver IQ_Split SyncCorrelator CRCGenerator SlotExtract SlotBitsExtract RxSRC SpeechOutput De-interleave DQPSKDecoder VselpExtract Viterbi Modeling Legend:: VStation On VStation C Models CoModelingInterfaces Modeling Legend: SCE-API Consortium, 2001

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

29. 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. SCE-API Consortium, 2001

30. 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. SCE-API Consortium, 2001

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