sce-mi meeting 1 san jose’, 14 th nov 2003 1 author: andrea castelnuovo sce-mi integrating...

SCE-MI Meeting 1

San Jose’, 14th Nov 2003

1

Author: Andrea Castelnuovo

SCE-MI SCE-MI Integrating Emulation in a system level design Integrating Emulation in a system level design

methodology methodology

San Jose’, 14/11/2003


Dynamic Verification Team

Company STMicroelectronics

SCE-MI Meeting 2


2


SummarySummary

• Transaction level modeling• The Interoperability Gap• SCE-MI: where, when• Some use models• Expected Performances• Conclusions

SCE-MI Meeting 3


3


SoC Simulation for SoC Simulation for Embedded SW DevelopmentEmbedded SW Development

• The Problem– Need SoC simulation platform even before RTL– Need simulation speed > 1000x faster than RTL– Need represent concurrency, interrupts etc– Cycle-Accurate (CA) model not appropriate

• Solution: Transaction-Level Model (TLM)

Courtesy of F Ghenassia

SCE-MI Meeting 4


4


Transaction Level ModelingTransaction Level Modeling

• Reference system model, including tesbench environment

• Fast executable description for a system under development

• Register accurate description for early and consistent software development


SCE-MI Meeting 5


5


A A singlesingle SoC/IP executable reference model SoC/IP executable reference model

• Single reference model enables– Rationalizing modeling efforts– Consistency between

developments– Communication between

teams

TLM model

algorithm team

design team

software team

verification team


SCE-MI Meeting 6


6


MotivationsMotivations

• Provide an infrastructure to support the Transaction Level Modeling methodology

• Objective of TLM models– Early embedded software development– Early (micro-)architecture analysis– Functional verification

• Rely on an open and tool-independent standard

• Activity started in ST/Central R&D in January 2000 (Frank Ghenassia)


SCE-MI Meeting 7


7


Transaction Level Model:Transaction Level Model:DefinitionsDefinitions

• A system model is composed of a set of modules, that:– Execute part of the expected system

behavior thanks to one or several concurrent threads

– Communicate data between each other. • Each data set is called a transaction• Data sets of variable size

– Synchronize between each other. A system synchronization is an explicit action


SCE-MI Meeting 8


8


ARM 926 EJ

ICacheSys.Ctrl.

JTAG / Trace

RTCWatchdog

Timers

DCache

NAND/NORFLASH Ctrl

eSRAMBuffer

DDR/SDRAMController

Audio SmartAccelerator

Video SmartAccelerator

16 ChannelDMA Ctrl

PLL1PLL2Power

Management

GPIO x76

InterruptController

Bridge

Bridge

SSPUART x2

FIrDA

MSP (AC97,I2S,SPI)

SD/MMCI2C x2

Color LCD CtrlDisplay I/F

RAM/ROM Secured USB OTG

Camera I/F

TLM SoC development platformTLM SoC development platform


SCE-MI Meeting 9


9


As soon as some RTL becomes available in the design flow, there is a need for interoperability between different abstraction layers. This is usually achieved by using proprietary interfaces, that allow linking two different environments.

TLM: InteroperablilityTLM: Interoperablility

Transaction

Any lower level decription: RTL, GATE, Cycle accurate behavioral

?API?

SCE-MI Meeting 10


10


Aptix

AXIS

Celaro

Specman

Vera

C++

TLM

Coware

Modeltech

NcVerilog

Palladium

VStationZebu

vcs

xsim

TestBuilder

Other Boxes…

Interoperablility becomes an issueInteroperablility becomes an issue

Other env

BOOM !!BOOM !!

SCE-MI Meeting 11


11


Interoperability issueInteroperability issue• Every EDA vendor possibly provides a solution to

interface its technology to external environments• The effort needed to create interfaces is too high

compared to the business improvement that it could generate. This translates into intrisicly inefficient interfaces.

• To efficiently interconnect hardware emulators to a transaction level environment, the user has to build synthesizable “transactors” for each specific interface.

Transactors reusability is mandatory.Transactors reusability is mandatory.-> the interface must be a standard-> the interface must be a standard

SCE-MI Meeting 12


12


Aptix

AXIS

Celaro

Vera

C++

SystemC

Coware

Modeltech

NcVerilog

Palladium

VStation

Zebu

vcs

xsim

Other Boxes…

Specman

TestBuilder

SC

E-M

I

SCE-MI: a clean approachSCE-MI: a clean approach

SCE-MI Meeting 13


13


SCE-MI

SCE-MI Use modelSCE-MI Use model

SW RTLDESIGN

End User

SCE-MI infrastructure

EDA VendorsTransactorsdesigners

SCE-MI Meeting 14


14


Transactors developmentTransactors development• Transactors provide a translation gasket between a transaction level

and the cycle-accurate pin level.• They are composed of two blocks:

– “Software” layer: is the transactional side of the interface, which is also the master of the communication

– “Hardware” layer: it contains the implementation of the functionality that transports the transactional information to the pins.

• Transactors have a direct impact on the performances of the interface• Reusability relies on SCE-MI standard, but also requires robustness and

reliability of the transactors code.• Transactor designer could be:

– A soft IP vendor – A verification IP vendor– The user himself– A third party or consultant– An EDA vendor

SCE-MI Meeting 15


15


IP integration through SCE-MI:• A standard interface allows fast

and easy integration of IPs• The most suitable

implementation for each IP can be plugged into the system.

• Simulation frequency suitable for early software development

Transaction

Cycle Accurate

RTL

Gate

SCE-MI

SCE-MI and TLMSCE-MI and TLM

SCE-MI Meeting 16


16


SCE-MI System Validation (1)SCE-MI System Validation (1)

• In a system description testbenches are often a relevant part of code.

• A standard interface allows strong re-usability of testbenches

• Using the same verification environment, improves consistency and reliability

Transaction

RTL

Gate

TB TB TB

SCE-MI

Silicon

SCE-MI Meeting 17


17


Example1 ARM PXPExample1 ARM PXP• A TLM model of PXP is simulating• Software can be developed on this platform• Custom Hardware block can be added in the TLM description

CustomBlock

SCE-MI Meeting 18


18


Example 1Example 1

• As soon as mature RTL is available for the block under development, it should be integrated into the system.

• The same TLM model of system (software and hardware) will be connected to the RTL model of the Custom block.

• Performances of the co-modeling platform will be affected by two main factors:– RTL model environment, being hardware emulation or

software logic simulation.– Communication channel between TLM and RTL .

SCE-MI Meeting 19


19


Example 1: SCE-MI layer Example 1: SCE-MI layer • A hardware emulation platform is used to map the RTL model• To build a SCE-MI based environment the user needs to:

– Provide a synthesizable SCE-MI compliant transactor for the custom block specific protocol (in this example APB bus)

– Provide a software layer to link TLM to APB transactor.• Note: Both software and Hardware side of the transactor written for

a given protocol, are re-usable in a SCE-MI context

Custom Block RTL

Hardware Emulator

SystemTLM

Description

Tra

nsac

t or

SC

E-M

IS

W lin

k

SCE-MI Infrastructure

SCE-MI Meeting 20


20


Example 1: SCE-MI transactors library Example 1: SCE-MI transactors library • Creating transactors requires an extra design and

validation effort• SCE-MI based transactors are platform independent,

thus strongly reusable• For specific protocols such as AHB, APB, STBUS, PCI,

Ethernet, MMC… an SCE-MI library will allow fast and easy transactional co-emulation.

SystemTLM

Description

SC

E-M

IS

W lin

k

Hardware Emulator

Custom Block RTL

Tra

nsac

t or

SCE-MI InfrastructureCustom Block

RTL

Tra

nsac

t or

Custom Block RTL

Tra

nsac

t or

Custom Block RTL

Tra

nsac

t or

SCE-MI Meeting 21


21


Transactor is not only a BFMTransactor is not only a BFM• Transactors can also be used to monitor traffic for protocol violation issues• Once a protocol-error is detected, a message is sent to the software

testbench.• Monitors running in hardware do not impact significantly on performances.

SystemTLM

Description

SC

E-M

IS

W lin

kHardware Emulator

Custom Block RTL

Tra

nsac

t or


Monitor

SCE-MI Meeting 22


22


Example2 ARM PXPExample2 ARM PXP

• TLM model of PXP system is simulating• The Testbench environment is developed at TLM level as well• As soon as the full system is ready at RTL level, a test environment has to be provided

TB Environment(DISPLAY MODEL)

Other BlocksOther

BlocksOther Blocks

TB Environment(Peripherals)

SCE-MI Meeting 23


23


Example 2: SCE-MI layer Example 2: SCE-MI layer • A hardware emulation platform is used to map the RTL model of

the whole system• Synthesizable SCE-MI compliant transactors for the testbench

functionalities to generate stimuli for the system• Provide a software layer to link TLM to APB transactor.• Both software and Hardware side of the transactor written are re-

usable in a SCE-MI context

RTLSYSTEM

Hardware Emulator

TestBenchTLM

Description

Tra

nsac

tor

SC

E-M

IS

W lin

k


Tra

nsac

tor

Tra

nsac

tor

Tra

nsac

tor

Display … UART

SCE-MI Meeting 24


24


Performance AnalysisPerformance Analysis

• The link between TLM and emulation needs to be reasonably efficient in terms of performances

• A performance estimation should be available before putting any effort into modeling the interface

• The link is implemented if the trade off between expected performance and modeling effort is acceptable

SCE-MI Meeting 25


25


Performance EstimationPerformance Estimation

• The following parameters are useful to estimate performances– RTL implementation speed (emulator)– TLM speed (software env)– Activity generated by a Context switch

(type of transactions)– Number of blocking actions– SCE-MI infrastructure speed

SCE-MI Meeting 26


26


Performance Estimation (2)Performance Estimation (2)

• RTL implementation speed (emulator)– Due to the hardware speed, this is usually

not the limiting factor.– Only for some particular tests, where few

interactions occur between hardware and software, hardware speed could result as the limiting factor

SCE-MI Meeting 27


27



• TLM speed (software env)– It becomes the limiting factor when the time

spent in the hardware side is lower than the CPU time between two interaction

– Use of blocking statements makes this parameter heavily impacting on performances

SCE-MI Meeting 28


28



• Activity generated by a Context switch (type of transactions)– Depending on the implementation, the time

consumed for handshaking between hardware and software might be relevant

– A good estimation can be achieved by measuring the handshaking time, using a profiler

SCE-MI Meeting 29


29



• Blocking actions– Blocking actions cause

the software to stuck, waiting for some feedback from hardware

– In such a context software becomes a limiting factor

– In a transaction based co-emulation approach they should be avoided

Example:This read function has to return a value, after some hardware cycles:

int read(int data, int addr) {Int data_read;

…Serviceloop();

…Return data_read;

}The software will be waiting until the data_read will be available from the hardware side.

SCE-MI Meeting 30


30


ConclusionsConclusions

• SCE-MI provides an efficient communication layer between transaction level modeling and emulation

• The cost for setting up such a link is mainly in the effort to create synthesizable transactor development

• Standardization allows for strong reusability of transactors, across multiple platforms

Thanks!

sce-mi meeting 1 san jose’, 14 th nov 2003 1 author: andrea castelnuovo sce-mi integrating...

Documents