Upload
malana
View
30
Download
0
Tags:
Embed Size (px)
DESCRIPTION
A Breakthrough Common Emulation API. SCE-API. 15th November 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. The SCE-API Consortium. - PowerPoint PPT Presentation
Citation preview
A BreakthroughCommonEmulationAPI
15th November 2001
SCE-APISCE-API
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
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.
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.
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.
SCE-API Consortium, 2001
C-based models
Em
ula
tor
Mo
del
s
Tra
nsa
ctio
nC
ycle
Eve
nt
Untimed Timed
Where SCE-API Fits in the Modeling World
RT
L
Gat
e
Tes
tben
ches
HW
/SW
PLI, OMI, FLI, SWIFT
Sys
tem
Accuracy
Ab
str
act
ion
SCE-API
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
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
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
SCE-MI Foundational ConceptsSCE-MI Foundational Concepts
SCE-API Consortium, 2001
EmulatorWorkstation
System ModelorTestbench
DUTor
Portions of the System
IKOS Co-Modeling Concept
Behavior RTL
TransactionProcessing
Transactions Per pin cycleaccurate data
CommunicationsOverhead
HW/SW Partition Point
Control& Data
Control
SCE-API Consortium, 2001
Co-Modeling Implementation
Workstation
SoftwareModels
RTL &Gate
ModelsCo
-mo
del
ing
In
terf
ace
EmulatorWorkstation
RTL &Gate
Models
SoftwareModels
Imp
lem
enta
tio
n
CAdapter
SCE-MISW Side
SCE-MIHW Side
RTLTransactor
Use
r V
iew Emulator
SCE-MI DescriptionSCE-MI Description
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.
SCE-API Consortium, 2001
SCE-MI Run-Time Components
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
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.
SWSide
TransmitReady
ReceiveReadyTransactor
SideMessage
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);
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.
SWSide
TransmitReady
ReceiveReadyTransactor
SideMessage
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.
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.
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.
SWSide
ReadyForCclock
CclockEnabledTransactor
SideUclock
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.
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.
SCE-MI Cell Phone ExampleSCE-MI Cell Phone Example
SCE-API Consortium, 2001
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
Digital Cell Phone Demo Diagram
SpeechInput
SpeechOutput
ChannelModel
On VStationModeling Legend:: VStation C ModelsModeling Legend:
Receiver
Transmitter
SlotBitsBuild
ConvolutionalEncoder
VoiceCypher
CRCGenerator
SRCFilter
DQPSKEncode
Interleaver
SlotConstruct
IQ_Split
SyncCorrelator
RxSRC
DQPSKDecoder
De-interleave
SlotExtract
CRCGenerator
VselpExtract
Viterbi
SlotBitsExtract
CoModelingInterfaces
SCE-API Consortium, 2001
SCE-MI Solution Architecture
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 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
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.
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