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

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.

4
Emulation User Problems to be Solved by SCE-API

• All emulators on the market today have
  proprietary APIs.
• 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 APIs 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.

5
Emulation Supplier Problems to be Solved by
SCE-API

• Users are reluctant to invest in building
  applications on proprietary APIs.
• Traditional simulator APIs like PLI and VHPI
  slow down emulators.
• Third parties are reluctant to invest in building
  applications on proprietary APIs.

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

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

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

10
SCE-MI Foundational Concepts
11
IKOS Co-Modeling Concept

Emulator
Workstation
System ModelorTestbench
DUTorPortions of the System
12
Co-Modeling Implementation
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.

15
SCE-MI Run-Time Components
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

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
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.
• MessageInputProxysend(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)

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

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.

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

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.

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.

27
Digital Cell Phone Demo Diagram
Transmitter
SpeechInput
Convolutional Encoder
DQPSKEncode
SlotBitsBuild
Interleaver
ChannelModel
CRCGenerator
SRCFilter
SlotConstruct
VoiceCypher
Receiver
IQ_Split
SyncCorrelator
SlotExtract
CRCGenerator
SlotBitsExtract
RxSRC
SpeechOutput
De-interleave
DQPSKDecoder
VselpExtract
Viterbi
On VStation
Modeling Legend
VStation
C Models
CoModelingInterfaces
Modeling Legend
28
SCE-MI Solution Architecture
29
Cell Phone Example
Case Simulation Time Emulation Time Gate Count Emulation Speed
C Only 12 sec Na Na Na
Receive RTL 330 sec 11 sec 152657 700 khz
Phone RTL 700 sec 13 sec 393523 625 khz

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

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.

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