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

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


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.


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.


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.


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


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


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


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


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


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


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


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


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.


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.


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


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.


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


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.


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-MI Solution Architecture


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


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.


Examples and Capabilities Discussion

Interface to threads Implementation in hardware Implementation in software Implementation over event platform Implementation over cycle platform Variable sized transactions

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

Documents

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