Warranty

Management
System

Electronic System Level (ESL)

System Modeling
Traditional SOC Design Flow
•Key algorithms
•Functionality of the
System •How many processors
•Key Interfaces •Any DSPs •Realize the SW
•Performance •HW / SW partition •OS, Drivers
•Power •Frequency •Middleware
•Bus-Fabric
•Application
•Memory and IO
throughput •Validate System

Spec Architecture SW Development

HW Design - RTL HW Imp HW Imp

•Micro-architecture spec •FPGA / Emulation

•RTL coding of HW
•Functional verification
•Logic Synthesis
•Test Insertion
•SP&R
•Static Timing Analysis
•DRC/LVS
•Tapeout
•IC Fab/packaging & Test
•Board prototyping

2
ESL Design Flow
Develop SW on Catch integration
high speed bugs early in the
models design cycle

SW Development

Spec Architecture

HW Design - RTL HW Imp

Get the Architecture

right by doing extensive
simulations in System
Eliminate necessity of
context
FPGA prototyping /
emulation

HLS: Go from Model to

RTL / Gates at 10x
productivity

3
Reasons for Using ESL Modeling
Accelerates product release schedule
Firmware / Software development
software

Fast enough
TLM
(Transaction Level Models) Architectural modeling
Ready before RTL

RTL
Hardware verification

Test bench TLM = golden model

4
Electronic System Level Modeling
ESL Modeling helps in Solving
Complex ASIC/ SoC Development Challenges
Challenges

Correct Architecture Reduce Time to Reduce Risk of More Effective

Design (Hardware Market (Parallel Failure (HW & Problem Debug
and Software) development of SW integration (HW +SW)
HW and SW) testing)

 Provides graphical environment for

capturing, configuring, simulating, and
analysing system level performance.
 ‘What if’ scenario simulation helps in
arriving at optimized architecture.
Evaluate and optimize the HW-SW
partitioning to achieve target
performance.
Measure interconnect performance of
complex bus architectures using traffic
generators.
Fast simulation with TLM models
provides rapid turnaround time; which
greatly improves analysis & decision
making process.
 Enables SW development as soon as Virtual
Prototype is ready.
Enables early detection of issues related to SW
and HW integration.
Provides system level visibility of hardware and
software enabling easier and quicker debugging.
 Fast simulation time.
Provides control over hardware state enabling
what if analysis and thus quicker debugging.
5
Faster Development Life cycle Challenges
1. The prototype required for
Software development is
enabled after implementing
the same in FPGA or
Emulator box (during RTL
phase )
2. Software debugging is
difficult on HW prototypes
and therefore development
may not be complete by the
time actual chip arrives
Using ESL, SW development start early in the after fabrication resulting
into longer post silicon
life-cycle of SoC phase.
Benefits
1. Software development starts
early as soon as SW VP
becomes available.
2. More time for software
development before chip
arrives.
3. SW VP provides better visibility
and control over the entire
system.
4. Faster edit & compile.
5. Faster debugging cycle for
implementing HW or SW
changes.
6. Software maturity is high when
6 chip arrives & hence quick post
silicon phase
Overall Advantages using ESL

SW developed concurrently with HW models

- Reduced time to market
Verify SW with visibility and speed
- Minimize time required in lab testing
Optimized HW design lifecycle
- Eliminates duplicate reference models
- Avoid costly re-spins
System Engineering
- Eliminates duplicate specifications
- Executable specification
- Ambiguities are resolved

“25% saving in HW/SW integration testing”

“20% saving in overall time to market”
“15% saving in design development
lifecycle”

7
ESL/EDA tools List
Vendor Tool

Synopsys (CoWare) Virtualizer / Platform Architect

TLM Modeling, Virtual Mentor Vista

Platform, Simulation, Cadence Virtual System Platform
Architecture
Mirabilis VisualSim
Exploration, System
Verification (HW/SW Co- Synopsys (VaST) CoMET
verification Carbon (ARM) SoC Designer Plus

Accellera / OSCI OSCI Reference Simulator

HDL to SystemC Carbon Model Studio

Synopsys (Synfora) Synphony C (PICO Express)

RTL Synthesis /
Behavioral Synthesis / NEC CyberWorkBench
High Level Synthesis Cadence C-to Silicon, Cynthesizer (Forte
(HLS)
Calypto (Mentor) CatapultC
SystemC

9
Introduction - SystemC

Background and history

Why C++ is inadequate
Introduction to SystemC
SystemC Language Architecture – basic, key concepts

10
 Background and history

SystemC has its roots in the idea of using C++ for modeling hardware and
software components of a system. SystemC was released (ver 0.9) in September
1999 and ownership put into the hands of the Open SystemC Initiative (OSCI).
Since then development of the language has been done by the language working
group of the OSCI. Development of SystemC prior to its OSCI ownership was
done at Synopsys, Frontier Design and CoWare (Now acquired by Synopsys).
Major releases have been version 1.0 in January 2000, which introduced a set of
macros for easier reading and writing and version 2.0 introduced in July 2001
which changed SystemC from a cycle based simulator to event based and
restructured the core language.
OSCI is now merged with Accellera in 2011 and now it is Accellera SystemC
Initiative http://www.accellera.org/
Latest version is SystemC 2.3.1

11
Why C++ is inadequate

Notion of time C++ doesn’t support SystemC supports

notion of time notion of time.
sequenced events.
There is no notion of
time.
Concurrency C++ supports In SystemC, processes
sequential execution. are defined which are
The notion of executed in parallel by
concurrency is not the simulator.
supported.
Hardware data type C++ native data types New hardware data
are inadequate for types are introduced
modeling hardware. for arbitrary precision,
There is no data type to 4 valued etc.
model a tri-state logic
value (Z).
12
SystemC Development Environment

13
Modeling Terms and Model Types

Or Register Transfer Level(RTL) accurate

14
SystemC Flows and Use

15
SystemC Flows and Use…… contd.

16
SystemC Language Architecture

17
Intro to SystemC

SystemC supports HW/SW co-design. It supports the description of

hardware, software, and interfaces in a C++ environment. Features are:
- Modules
- Processes
- Rich set of Ports & Signals
- Rich set of data types
- Clocks
- Event based simulation
- Multiple abstraction level
- Debugging Support
- Waveform Tracing
18
SystemC Scheduler

Scheduler
Delta Cycle
Working of SystemC scheduler
Initialization phase
Evaluate phase
Update phase

19
Scheduler Steps

20
Data Types

SystemC data types include the following:

• sc_bit – 2 value single bit type
• sc_logic – 4 value single bit type
• sc_int – 1 to 64 bit signed integer type
• sc_uint – 1 to 64 bit unsigned integer type
• sc_bigint – arbitrary sized signed integer type
• sc_biguint – arbitrary sized unsigned integer type
• sc_bv – arbitrary sized 2 value vector type
• sc_lv – arbitrary sized 4 value vector type
• sc_fixed - templated signed fixed point type
• sc_ufixed - templated unsigned fixed point type
• sc_fix - untemplated signed fixed point type
• sc_ufix - untemplated unsigned fixed point type
21
Modules & Constructors

Basic building blocks for partitioning the design.

Module contains
Ports: Through which the module communicates with
the environment
Processes: That describe the functionality of the
module
Internal Data and Channels: For maintenance of
model state and communication between the
module’s processes
Hierarchically, other modules. 22
Module Ports

Module ports pass data to and from the

processes of a module.

SC_MODULE(fifo) {
sc_in<bool> load;
sc_in<bool> read;
sc_inout<int> data;
sc_out<bool> full;
sc_out<bool> empty;
// rest of module not shown
};
23
Module Signals

Can be locals to a module, and are used to

connect ports of lower level modules together.
Signals carry data, while ports determine the
direction of data from one module to another.

24
Event and Processes

Event
Notify method

Process
Thread Process
Method Process

25
Event Type

An event is a basic synchronization object. It is used to synchronize

between processes.
It has no data type, and has only control. It is declared inside of a
module.
Syntax:
sc_event event_name1, event_name2;
Example:
SC_MODULE(ex) {
// ports not shown
//events
sc_event ev1, ev2;
// rest of the module not shown
};

26
Notify() method

To trigger or cause an event, notify() method of an event is called.

Syntax:
event_name.notify(args);
event_name.notify_delayed(args);
notify(args, event_name); // function notation
Notification of an event can be immediate, delta delayed or timed.
Immediate notification causes processes which are sensitive to
the event to be made ready in the current evaluation phase of the
current delta cycle.
Delayed notification causes process which are sensitive to the
event to be made ready in the evaluation phase of the next delta
cycle.
Timed notification causes processes which are sensitive to the
event to be made ready to run at a specified time in future.

27
Notify() method

Example

sc_event my_event ; // event declaration

sc_time t (10, SC_NS) // declaration of a 10 ns time
// interval . . .
my_event.notify(); // immediate notification ...
my_event.notify (SC_ZERO_TIME); // delta-delay
// notification ...
my_event.notify (t); // notification in 10 ns

28
Process

Processes are functions, which are called by the Kernel

based on its static and dynamic sensitivity list. They use
channels or events to communicate with one another.
SystemC supports 3 types of processes:
 Methods (SC_METHOD)
 Threads (SC_THREAD)
 Clocked threads (SC_CTHREAD) (deprecated)

29
Thread Process

A thread process is implemented in infinite loop. It may be invoked

based upon:
 Static sensitivity
 Dynamic sensitivity
It runs only when started by the systemc scheduler. It is re-activated
based on sensitivity to events. Once it is (re)activated, it is executed
until it encounters a wait() statement. At this, the process is
suspended till the next reactivation.
A thread process is initialized in the beginning of the simulation. The
dont_initialize() function forbids such initialization.

30
Thread Process

Wait() function
The wait() function suspends execution of the process
until it is invoked again.
If no wait() is encountered in thread process, it is
executed in zero time. This is often referred to in
simulation as “zero time loop”.

31
Method Process

It is similar to a thread process except that it may not be suspended.

It runs when started by the SystemC scheduler depending on
sensitivity list. Once invoked, the entire body of the process is
executed. Upon completion, it returns the control back to the
simulation kernel.
It is initialized during initialization phase of the scheduler. The
don’t_initialize() function can be used to avoid this initialization.
A method process may not be enclosed in infinite loop and it may
not contain wait() statements.
Local variables are redefined each time the process is invoked.

32
Transaction
OSCI TLM-2.0 Level Modeling (TLM)
standard of the
Open SystemC Initiative (OSCI)
Transaction Level Modeling

Functional
RTL
Model

Transaction
Pin accurate, level - function
cycle accurate call
write(address,data)

RTL Functional
Model

Simulate every event 100-10,000 X faster simulation

Reasons for Using TLM

Accelerates product release schedule

Firmware / Software development

software

Fast enough
TLM
Architectural modeling
Ready before RTL

RTL
Hardware verification
Test bench TLM = golden model
Typical Use Cases for TLM

Represents key architectural components of hardware platform

Architectural exploration, performance modeling

Software execution on virtual model of hardware platform

Golden model for hardware functional verification

Available before RTL

Simulates much faster than RTL

36
 Use Cases, Coding Styles and Mechanisms

Use cases
Software Software Architectural Hardware
development performance analysis verification

TLM-2 Coding styles

Loosely-timed (LT)

Approximately-timed (AT)

Mechanisms

Blocking Generic Non-blocking

DMI Quantum Sockets Phases
interface payload interface
 Coding Styles

Loosely-timed (LT) = “as fast as possible”

Only sufficient timing detail to boot O/S and run multi-core systems
Processes can run ahead of simulation time (temporal decoupling)
Each transaction has 2 timing points: begin and end
Uses direct memory interface (DMI)
Approximately-timed (AT) = “just accurate enough for performance modeling”
aka cycle-approximate or cycle-count-accurate
Sufficient for architectural exploration
Processes run in lock-step with simulation time
Each transaction has 4 timing points (extensible)
Guidelines only – not definitive

38
Interoperability Layer

1. Core interfaces
and sockets

Initiator Target

2. Generic payload 3. Base protocol

Command BEGIN_REQ
Address
Data END_REQ
Byte enables
Response status
BEGIN_RESP
Extensions
END_RESP

Maximal interoperability for memory-mapped bus models

Initiators and Targets

Initiator Target Initiator Target

socket socket socket socket

Forward Forward
path Interconnect path
Initiator component Target
0, 1 or many
Backward Backward
path path

Transaction
object

References to a single transaction object are passed along the forward and backward paths

40
Blocking versus Non-blocking Transport

Blocking transport interface

Includes timing annotation

Typically used with loosely-timed coding style
Forward path only
Non-blocking transport interface

Includes timing annotation and transaction phases

Typically used with approximately-timed coding style
Called on forward and backward paths

41
Base Protocol - Coding Styles

Loosely-timed is typically
Blocking transport interface, forward and return path
2 timing points
Temporal decoupling and the quantum keeper
Direct memory interface
Approximately-timed is typically
Non-blocking transport interface, forward and backward paths
4 phases
Payload event queues
Loosely-timed and approximately-timed are only coding styles
The base protocol defines rules for phases and call order

42
 Summary: Key Features of TLM 2.0

 Transport interfaces with timing annotation and phases

 DMI and debug interfaces

 Loosely-timed coding style and temporal decoupling for simulation speed

 Approximately-timed coding style for timing accuracy

 Sockets for convenience and strong connection checking

 Generic payload for memory-mapped bus modeling

 Base protocol for interoperability between TL- models

 Extensions for flexibility of modeling

43
For more FREE information

 SystemC 2.3.1 and TLM 2.0, please refer to

http://www.accellera.org
http://www.accellera.org/downloads/standards/systemc

44
 Thanks
Any Questions ? Please send queries to
akamboj@hcl.com
saravanan.n@hcl.com

45