Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Accellera-SystemC-Tutorial-2014 - Case Study

Download as pdf or txt
Download as pdf or txt
You are on page 1of 104
At a glance
Powered by AI
The key takeaways are about using different features of SystemC like sc_vectors, sc_event_or_list, sc_writer_policy, reset signals, and module constructors/destructors.

Sc_vectors allow grouping similar ports or signals together into a vector that can be indexed. They can contain ports, signals, or modules. Vectors of different types can be bound to each other for connectivity.

Sc_vectors can be bound to each other through vector-to-vector binding or by iterating through the vectors and binding elements individually. Binding can start from a specific iterator position.

Case Studies in SystemC

Hints and Tips for Exploiting


the Latest Features of SystemC
John Aynsley, Doulos
Agenda

 sc_vector
 sc_event_or_list
 sc_writer_policy
 reset_signal_is
 reset() and kill()

Features first introduced in IEEE 1666™-2011 and SystemC-2.3.0

SystemC-2.3.1 is about to be released

2 © 2014 Doulos March 3, 2014


sc_vector of Ports or Signals
struct Child: sc_module
{ Module
sc_vector< sc_out<int> > port_vec; m1

Child(sc_module_name n)
: port_vec("port_vec", 4) Elements are named Vector-of-ports
{ ...
struct Top: sc_module
{
sc_vector< sc_signal<int> > sig_vec;
Child* c;

Top(sc_module_name n)
: sig_vec("sig_vec", 4) Size passed to ctor
{
c = new Child("c");
c->port_vec.bind(sig_vec); Vector-to-vector bind
}
...
3 © 2014 Doulos March 3, 2014
sc_vector of Modules
struct Child: sc_module Module
Module
{ m2
Module
m2
Module
sc_out<int> p; m2
Module
m2
Module
... m2
Module
struct Top: sc_module m2
m2
Child
{
Anything derived from sc_object

sc_vector< Child > mod_vec;


sc_vector< sc_signal<int> > sig_vec;

Top(sc_module_name n)
: mod_vec("mod_vec")
, sig_vec("sig_vec") Elements are named
{
mod_vec.init(4);
sig_vec.init(4); Size deferred
for (int i = 0; i < 4; i++)
mod_vec[i].p.bind(sig_vec[i]);
}
...
4 © 2014 Doulos March 3, 2014
sc_vector methods sc_object
name()
kind()
struct M: sc_module
{
sc_vector< sc_signal<int> > vec; sc_vector_base
size()
M(sc_module_name n) get_elements()
: vec("vec", 4) {
SC_THREAD(proc)
} T
sc_vector
void proc() {
sc_vector(nm, N)
for (unsigned int i = 0; i < vec.size(); i++) init(N)
vec[i].write(i); ~sc_vector()

wait(SC_ZERO_TIME); begin()
end()
T& operator[]()
sc_vector< sc_signal<int> >::iterator it; T& at()
for (it = vec.begin(); it != vec.end(); it++)
cout << it->read() << endl; bind()
...

5 © 2014 Doulos March 3, 2014


Binding Vectors
size() = 4
Module
size() = 8 m2
Module
m1
size() = 4
Module
m3

sc_vector< sc_port<i_f> >::iterator it;


it = m1->port_vec.bind( m2->export_vec );

it = m1->port_vec.bind( m3->export_vec.begin(),
m3->export_vec.end(),
it );
1st unbound element Start binding here
6 © 2014 Doulos March 3, 2014
Constructor Arguments
struct Child: sc_module
{
Child(sc_module_name n, int a, bool b); Module ctor has args
...

sc_vector<Child> child_vec;

static Child* creator_func( const char* name, size_t s )


{
return new Child(name, 3, true); Pass args to constructor
}

child_vec.init(4, creator_func);

7 © 2014 Doulos March 3, 2014


Agenda

 sc_vector
 sc_event_or_list
 sc_writer_policy
 reset_signal_is
 reset() and kill()

8 © 2014 Doulos March 3, 2014


Event List Objects
struct Child: sc_module
{
sc_vector< sc_port<i_f> > ports;

Child(sc_module_name n, int n_ports) Ctor arg


: ports("ports", n_ports)
{
SC_HAS_PROCESS(Child);
SC_THREAD(thread);
}
void thread()
{ Setup once, keep it alive!
sc_event_or_list or_list;
sc_vector< sc_port<i_f> >::iterator it;
for (it = port.begin(); it != port.end(); it++)
or_list |= (*it)->default_event();
for (;;)
{
wait(or_list);
...
9 © 2014 Doulos March 3, 2014
Agenda

 sc_vector
 sc_event_or_list
 sc_writer_policy
 reset_signal_is
 reset() and kill()

10 © 2014 Doulos March 3, 2014


Modeling an Interrupt
struct M: sc_module
{
sc_vector< sc_signal<bool, SC_MANY_WRITERS> > interrupt;

M(sc_module_name n) : interrupt("interrupt", 4) {
SC_HAS_PROCESS(M);
SC_THREAD(proc1);
SC_THREAD(proc2);
}

void proc1() void proc2()


{ {
wait(100, SC_NS); wait(200, SC_NS);
interrupt[0].write(true); interrupt[0].write(true);
wait(1, SC_NS); wait(1, SC_NS);
interrupt[0].write(false); interrupt[0].write(false);
} }
11 © 2014 Doulos March 3, 2014
Agenda

 sc_vector
 sc_event_or_list
 sc_writer_policy
 reset_signal_is
 reset() and kill()

12 © 2014 Doulos March 3, 2014


Processes Unified!
SC_CTHREAD(T, clk.pos()); void T() {
reset_signal_is(r, true); if (r|ar)
q = 0;
async_reset_signal_is(ar, true);
while (1)
{
SC_THREAD(T); wait();
++q;
sensitive << clk.pos();
}
reset_signal_is(r, true); }
async_reset_signal_is(ar, true);
void M() {
SC_METHOD(M); if (r|ar)
q = 0;
sensitive << clk.pos();
else
reset_signal_is(r, true); ++q;
async_reset_signal_is(ar, true); }

Reset restores the static sensitivity


13 © 2014 Doulos March 3, 2014
Styles of Reset
SC_THREAD(target);
reset_signal_is(reset, active_level);
async_reset_signal_is(reset, active_level);

sc_spawn_options opt;
opt.reset_signal_is(reset, active_level);
opt.async_reset_signal_is(reset, true);

handle.reset();

handle.sync_reset_on();
...
handle.sync_reset_off();

14 © 2014 Doulos March 3, 2014


Agenda

 sc_vector
 sc_event_or_list
 sc_writer_policy
 reset_signal_is
 reset() and kill()

Process control methods

15 © 2014 Doulos March 3, 2014


reset and kill
SC_THREAD(calling);
SC_THREAD(target);
t = sc_get_current_process_handle(); int q;

void calling() void target()


{ {
wait(10, SC_NS);
q = 0;
ev.notify(); ++q
while (1)
wait(10, SC_NS); {
t.reset(); q=0 wait(ev);
assert( q == 0 );
++q;
wait(10, SC_NS); }
ev.notify(); ++q }
Wakes at 10 20 30
wait(10, SC_NS);
t.kill(); Terminated at 40
assert( t.terminated() );
16 © 2014 Doulos March 3, 2014
Unwinding the Call Stack
void target()
{
q = 0;
while (1)
{
try {
wait(ev); reset() kill()
++q;
}
catch (const sc_unwind_exception& e)
{

}
...
17 © 2014 Doulos March 3, 2014
Unwinding the Call Stack
void target()
{
q = 0;
while (1)
{
try {
wait(ev); reset() kill()
++q;
}
catch (const sc_unwind_exception& e)
{
sc_assert( sc_is_unwinding() );
if (e.is_reset()) cout << "target was reset";
else cout << "target was killed";

}
...
18 © 2014 Doulos March 3, 2014
Unwinding the Call Stack
void target()
{
q = 0;
while (1)
{
try {
wait(ev); reset() kill()
++q;
}
catch (const sc_unwind_exception& e)
{
sc_assert( sc_is_unwinding() );
if (e.is_reset()) cout << "target was reset";
else cout << "target was killed";
proc_handle.reset();
Resets some other process
throw e;
}
... Must be re-thrown

19 © 2014 Doulos March 3, 2014


reset_event & terminated_event
SC_THREAD(calling);
SC_THREAD(target);
t = sc_get_current_process_handle();

SC_METHOD(reset_handler);
dont_initialize();
sensitive << t.reset_event();

SC_METHOD(kill_handler);
dont_initialize();
sensitive << t.terminated_event(); void target()
{
...
void calling() while (1)
{ {
wait(10, SC_NS); wait(ev);
t.reset(); ...
wait(10, SC_NS); }
t.kill(); }
...
20 © 2014 Doulos March 3, 2014
For Further Information

http://www.doulos.com/knowhow/systemc/

http://www.accellera.org/community/systemc/

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

http://standards.ieee.org/getieee/1666/download/1666-2011.pdf

21 © 2014 Doulos March 3, 2014


Thank you
Case Studies in SystemC

TLM Use Cases at Ericsson AB


Henrik Svensson, PhD, Ericsson AB
1. Develop Base Stations

2 © 2014 Ericsson AB March 3, 2014


Radio Base Stations

2G 3G 4G

Ericsson base stations


support all major 3GPP
and 3GPP2 technology
tracks:
 GSM/EDGE
 WCDMA/HSPA
 CDMA
 LTE
 Antenna
 Radio
 Baseband

Radio Base Station

3 © 2014 Ericsson AB March 3, 2014


Radio Base Stations
Macro Main-Remote AIR

4 © 2014 Ericsson AB March 3, 2014


A look inside
System

Hardware Software

 Usually with the term


system or embedded
HW IP System-On-Chip System-On-Board System-In-Cabinet
system we refer to
hardware and software.

5 © 2014 Ericsson AB March 3, 2014


Develop base stations

System-On-Chip System-On-Board
Baseband, Radio, and Radio Unit and Digital Unit
Control SoCs

System-In-Cabinet
RBS 6000 series of multi-standard base stations

6 © 2014 Ericsson AB March 3, 2014


System Design Process
TLM Architect System

System
HW IP cores D&V
IP
Hardware Software
HW Chip D&V

HW Board D&V

THE DESIGN
PROCESS AS A SW TOOLS
FLOW OF
ACTIVITIES
Platform & App

7 © 2014 Ericsson AB March 3, 2014


TLM advantages
Primary:
 Early Hardware Verification Environment
 Early Software Development and System MAIN ADVANTAGES:
Verification WITH ABSTRACTION

 Enables early and massive System


Exploration
 Enables early System Dimensioning
Secondary: SECONDARY
ADVANTAGES: E.G.
 IEEE Standard SYSTEMC OVER
OTHER ABSTRACT
 C++ offers a extensive code base LANGUAGES.
 Speed of Development
 Simulation and Verification Speed

POTENTIAL ADVANTAGES
8 © 2014 Ericsson AB March 3, 2014
Board

Design flow with TLM


HW IP SoC Board HW IPSystem-In-Cabinet
SoC

Functional
LT model AT model RTL model
model
(SystemC) (SystemC) (VHDL/…)
(C++)

Alg. D&V Performance evaluation


SoC architects SW architects

SoC Design and Verification HW designers HW Board D&V


Algorithm
HW verifiers

HW emulation

Platform SW dev.
Virtual prototyping Prototype ver.

SW Tools
Appl. SW dev. (RANs)
Platform SW Application SW
(C/C++) (C/C++)

9 © 2014 Ericsson AB March 3, 2014


Ericsson AB TLM
Community
 Ericsson joined Accellera as associate corporate level during 2012
 Ericsson became corporate level member 2014

Co-operating across projects and organization


 TLM steering group meetings every second week

Projects
 Methodology project – Apollo 2010
 Pilot project TLM for early SW development – Helios 2010
 Pilot project TLM for Architectural exploration – Vulcan 2011
 Sharp project TLM for early SW development – Ghost 2012
 Sharp project TLM for early HW verification – Atom 2012

Master thesis
 Accuracy of AT TLM models. How to compare RTL and TLM.
 TLM for virtual platforms
 TLM for verification
 SW statistics collection from TLM for HW exploration and dimensioning

10 © 2014 Ericsson AB March 3, 2014


2. SW Development

11 © 2014 Ericsson AB March 3, 2014


SW users at Ericsson

Today…
 Ericsson uses a TLM-2.0
LT based virtual platform
for SW development
- Hundreds of users
- SW operates many months
before chip and board is
ready
- Replaced legacy Virtual
platform

12 © 2014 Ericsson AB March 3, 2014


SW Development

 Develop SW and run


regressions
- LT to get the speed
- Memory/register accurate

 SW users operate at chip and


board-level
 Standard debug tools are used GSM WCDMA LTE
independent if target is TLM or Platform SW
HW.
 More visibility with tools from
EDA vendors. Target TLM RTL

13 © 2014 Ericsson AB March 3, 2014


System virtualization platform,
single ASIC
SVP
Top
Test framework 3rd party Debug
support tool support ASIC (TLM2)
Accelerators

DspTools support Interfaces


(Ericsson internal) TCP/IP socket
Control

Debugger DSP cluster


MDI Test framework
I/O
support
Adapter

DspTools Core

TCP/IP socket
Debug Attribute Execute Factory
QSim
Legacy
Virtual platform
SVPIF server
SVPIF client
In-house CCI framework

14 © 2014 Ericsson AB March 3, 2014


System virtualization platform,
board
TCP/IP socket
SVP
Adapter Board
3rd party TLM2
Simulator support
I/O CPU TLM2 IP

p p
e
e
r ASIC r
i ASIC i
p ASIC p
h
h
e
(TLM2) e
r r
a a
l l
Test framework I/O
s s
support
FPGA (TLM2)

Debug Attribute Execute Factory

SVPIF server

In-house CCI framework

15 © 2014 Ericsson AB March 3, 2014


In house CCI Module

 Must include header file #include "svp.h"

 Should use svp_module


class Mymodule :
- provides attribute handler public svp_module { public:
- dynamic creation facilities
Mymodule(svp_modulename nm) :
 Otherwise regular sc_modules svp_module(nm)
{}
 Must comply
}
with modeling guidelines

16 © 2014 Ericsson AB March 3, 2014


In house CCI Attributes
 Store configuration data and state class my_module : public svp_module {
my_module(svp_module_name smn)
 Are data members of SVP modules
: svp_module(smn), a (123)
 Can be used like regular data { b = 456; }
members inside the module
 Accessible from outside the class SVP_BASIC_ATTRIBUTE(a, uint32_t);
 Two ways to deploy SVP_BASIC_ATTRIBUTE(b, uint32_t);
- Use ATTRIBUTE macro (preferred) };
- Explicitly instantiate attribute class
 Internally attributes are linked to
AttributeContainers
- Used to form attribute trees
- Orthogonal to sc hierarchy
- svp modules are attribute containers

17 © 2014 Ericsson AB March 3, 2014


In house CCI registers
 Store SW visible data and state // could be generated (MACRO|TOOL)
template <T> class RegXY
 Are members of SVP modules : public er_register<T> {

 Organized hierarchically er_register_field<T,sBit,eBit,RW> f1;


er_register_field<T,sBit,eBit,RW> f2;
- module.{bank.}register.field
 Support access restrictions (r/w/rw) myReg(RegisterName an, T resetVal)
: er_register<T>(an, resetVal)
, f1("f1", this), ...
 Accessible from outside the class {}
- by SVP handlers and tool clients };
 Provide APIs for
reset, field-wise acess, ... class my_module
- eases internal usage and access : public svp_module {
- full register or individual fields
RegXY<uint32_t> myReg;
 Optional creation from reg descriptions // er_register<uint32_t> noFieldsReg;
- SystemRDL, IP-XACT
my_module(svp_module_name smn)
- Handy for large register files (100s of regs)
: svp_module(smn)
, myReg("myReg", 0xffff)
// , noFieldsReg("noFieldsReg", 0x0)
{}
};
18 © 2014 Ericsson AB March 3, 2014
3. Performance evaluation

19 © 2014 Ericsson AB March 3, 2014


Performance evaluation

Today…
 TLM-2.0 AT models used for
HW IP level performance
exploration
 TLM-2.0 LT models used at
system-level to acquire SW
load models

20 © 2014 Ericsson AB March 3, 2014


Roadmap for architectural
exploration
 It is not in the current roadmap to develop AT models of complete
ASICs or boards
 AT modeling used at IP level or subsystem level to do exploration
or dimensioning
 LT level have shown accuracy enough to be used for
- System level exploration
- To acquire SW load model that is used in dimensioning or exploration

21 © 2014 Ericsson AB March 3, 2014


Performance Evaluation

Evaluation
 Performance Evaluation is purpose
to quantify the services
given by the system as a
function of scenarios Exploration Dimensioning
- Quantifying services = Metric or
performance metric
- Scenarios = Stimuli or load Stimuli Performance evaluation Metric
Goals are:
 Performance dimensioning
- Assure the selected system meets
performance goals.
- Metric high accuracy HW SW HW/SW
 Performance exploration
- Performance evaluation of multiple
HW IP System-On-Chip System-On-Board System-In-Cabinet
systems that are then compared.
- Metric medium accuracy (Relative
comparison)

22 © 2014 Ericsson AB March 3, 2014


SW load models acquired from
TLM LT
 Use SVP to collect samples from SW LTE
applications.
Platform SW
- Usage of buses
- Usage of memories
Processor Traffic gen
- Usage of HW cores
- etc.
 Make statistical analysis of the samples Interconnect

 Build a flexible TLM traffic generator


targeting performance evaluation. Memory EM

 Used also in static analysis

23 © 2014 Ericsson AB March 3, 2014


IP level exploration
1

0.8

0.6

0.4

0.2

0
AT Model vs. Original RTL
0 20 40 60 80 100

30% Performance boosting!


1 Later RTL vs. Original RTL
0.8 after boosting
0.6

0.4

0.2

0
0 20 40 60 80 100

24 © 2014 Ericsson AB March 3, 2014


4. HW functional verification

25 © 2014 Ericsson AB March 3, 2014


HW Verification at Ericsson

Today…
 TLM-2.0 LT models are
used as references at HW
IP level
 TLM-2.0 LT models used
as development platform
for chip level verification

26 © 2014 Ericsson AB March 3, 2014


Chip level verification
1. Development phase 2. Regression phase
Test case SW Test case SW

TLM RTL Emulator Target

Platform Relative load time + execution time


RTL 15000x (days)
HW emulation 80x (minutes)
TLM LT 1x (seconds)

 Advantages
- TLM available early and used as stable development platform for SW driven
test cases.
- Develop and run design loop is fast.
27 © 2014 Ericsson AB March 3, 2014
TLM in chip level verification
 Software driven Verification
 Same verification platform for all abstractions, TLM, RTL, Emulation and HW.
 This setup allows us as well to verify and debug software.
 TLM model used for test software development in this setup
 The verification environment supports both test software development and design verification.
 Possibilities to run real software will improve our confidence and pave the wave for a smooth software integration.
 Regressions are run on all abstractions

Top Level Verification

System Validation Framework

SoC SoC
SoC SoC
HW HW
TLM RTL
Emulation Prototype

28 © 2014 Ericsson AB March 3, 2014


HW IP verification
VER. ENV. VER. ENV.
SystemVerilog, e SystemVerilog, e

REF : TLM REF : TLM

DUT : TLM DUT : RTL

 Top-down design approach


- TLM as DUT and reference REF
- High abstraction level
- DUT later exchanged to matured RTL
- Low abstraction level

29 © 2014 Ericsson AB March 3, 2014


Challenges

 How smart should the scoreboard be to


identify the mismatch type?

 Is the observability enough?


› Internal state divergence due to different model
accuracy

30 © 2014 Ericsson AB March 3, 2014


HW verification: LT or AT?
Board
Develop time

Loosely
Timed For
Timing

HW verifiers Approximately For


HW IP SoC Timed Function

Abstraction Level

 How can we move the REF model to low abstraction level for
achieving the verification goal?
 How can we maximize the model reusability?

31 © 2014 Ericsson AB March 3, 2014


HW verification: reusable LT
module
 Drive TLM at critical condition.
F(x) G(x,t) H(x) - Increase detail level with less modeling effort

LT functional prototype  TLM behaves partly as a state observer


and checker.
- Increase observability for debugging
Interoperablility?

UVM control interface


Develop time

F(x) G1(x) G2(x) H(x) For


Timing

Event driven LT verification mode For


Function

Abstraction Level
32 © 2014 Ericsson AB March 3, 2014
Summarize LT and AT

APP PLATFORM
 LT adds value to several user LT SW SW
DEV DEV
groups in HW and SW.
100
LT -
 Verification requires refined LT 1000 HW
VERIFIERS
but not AT users

 LT models are useful for system


exploration and to acquire SW
load models
 AT models used for IP level or
AT
subsystem level exploration Performance
and dimensioning LT
10-100 evaluation
users

33 © 2014 Ericsson AB March 3, 2014


Thank you
Case Studies in SystemC

Efficient Abstractions for AMS


System-level Design
Martin Barnasconi, SystemC AMS WG chair
Outline

 Introduction
 Language standard overview
 AMS models of computation
 Dynamic and reactive extensions in SystemC AMS 2.0
 Example: DC motor control with Pulse Width Modulator
 Conclusions

2
SystemC AMS objectives

 System-level modeling standard and methodology for analog/mixed-


signal systems
 An architecture design language for AMS system-level design and
verification
 A platform that facilitates AMS model exchange and IP reuse
 SystemC-centric methodology to integrate (abstract) AMS and digital
HW/SW descriptions
 Efficient abstraction concepts and modeling formalisms using
dedicated models of computation (MoC)

3
SystemC AMS applications
Image courtesy of STMicroelectronics

Communication systems Imaging systems

Automotive systems
4
SystemC AMS – History
1999: Open SystemC Initiative (OSCI)
announced
2000: SystemC 1.0 released ~2000: First C-based AMS initiatives
(sourceforge.net) (AVSL, MixSigC)
2002: OSCI SystemC 1.0.2 2002: SystemC-AMS study group started
2005: IEEE Std 1666-2005 LRM 2005: First SystemC-AMS PoC
released by Fraunhofer
2005: SystemC Transaction level
modeling (TLM) 1.0 released 2006: OSCI AMSWG installed
2007: SystemC 2.2 released
2008: SystemC AMS Draft 1 LRM
2009: SystemC TLM 2.0 standard
2010: SystemC AMS 1.0 LRM standard
2009: SystemC Synthesizable Subset
Draft 1.3 2010: SystemC AMS 1.0 PoC released
by Fraunhofer IIS/EAS
2011: IEEE Std 1666-2011 LRM
2012: SystemC AMS 2.0 draft standard
2012: SystemC 2.3 PoC released by
2013: SystemC AMS 2.0 LRM standard
Accellera Systems Initiative
2013: SystemC AMS 2.0 PoC test version

5 2014: IEEE 1666.1 (SystemC AMS) started


Positioning SystemC AMS

Specification

RF
SoC
Functional AMS
Digital
Interface

Architecture SystemC AMS SystemC

Implementation VHDL-AMS, SystemVerilog,


Verilog-AMS VHDL, Verilog

6
Example: Communication System
Receiver
Serial Modulator/
ADC Host
Interface demod.
processor
DSP

Antenna
Calibration & Control Micro-
front-end
controller Imaging
Memory
DSP
Transmitter
DAC
to all blocks
High
Power Audio Speed
RF Temp. Oscillator Clock Manage- DSP Serial
detector sensor Generator ment Interface

 Tight interaction between digital HW/SW and AMS sub-systems


- Signal path: Communication protocol stack – modeling including PHY layer
- Control path: more and more HW/SW calibration and control of analog blocks

 Architecture modeling using SystemC, TLM and AMS

7
Industry requirements and needs

 Design of True Heterogeneous Systems-on-a-chip


- Analog, Mixed-signal, RF, digital HW/SW (processor) interaction
- Multi-domain, high frequencies, high bandwidth, configurable AMS components

 Support different levels of design abstraction


- Functional modeling, architecture design, (abstract) circuit representations

 Support different use cases – also for AMS!


- Executable specification, architecture exploration, virtual prototyping, integration
validation

Need for Virtual Prototype Environments which enable inclusion of


digital HW/SW and abstract AMS/RF system-level representations

8
SystemC AMS advantages

 SystemC, thus C++ based


- Enjoy the power of C++ (and its wealth of libraries)
- Object oriented – modular and extendable
- AMS class libraries available for basic building blocks (analog primitives)
- Tool independent / EDA-vendor neutral

 Modeling in multiple abstractions using one simulator


- No need for complex multi-kernel/co-simulation
- No difficult APIs
- Converter models and ports are part of the language
- Allows abstraction along four axis
- structure, behavior, communication and time/frequency

 Transparent modeling platform


- Access to simulation kernel to ease debugging and introspection
9
Model abstraction and formalisms
Use cases

Executable Virtual Architecture Integration


specification prototyping exploration validation

Model abstractions
Discrete-time Continuous-time
static non-linear dynamic linear

Non-conservative behavior Conservative behavior

Modeling formalism

Electrical Linear
Timed Data Flow (TDF) Linear Signal Flow (LSF)
Networks (ELN)

10
AMS models in Virtual Prototypes realistic?
Yes, as long as you use the right language and abstraction method

SystemC AMS
ELN LSF TDF
extensions
Verilog-AMS, electrical
signal real-
VHDL-AMS flow number

virtual
Verilog-A electrical
prototyping
top-level
Fast-spice electrical verification

circuit/block
Spice verification

1× 10× 100× 1000× 10000× 100000× 1000000×


week(s) day(s) hour(s) minute(s) second(s)
Expected simulation speed improvement [1]

[1] M. Barnasconi, SystemC AMS Extensions: Solving the Need for Speed,
http://www.accellera.org/community/articles/amsspeed/

11
SystemC AMS extensions LRM

 Language Reference Manual defines the


standard of the SystemC AMS extensions
 Contents
- Overview
- Terminology and conventions
- Core language definitions
- Predefined models of computation
- Predefined analyses
- Utility definitions
- Introduction to the SystemC AMS extensions
(Informative)
- Glossary (Informative)
- Deprecated features (Informative)
- Changes between SystemC AMS 1.0 and 2.0
standard (Informative)

12
SystemC AMS User’s Guide

 Comprehensive guide explaining the


basics of the AMS extensions
- TDF, LSF and ELN modeling
- Small-signal frequency-domain modeling
- Simulation and tracing
- Modeling strategy and refinement methodology

 Many code examples


 Application examples
- Binary Amplitude Shift Keying (BASK)
- Plain-Old-Telephone-System (POTS)
- Analog filters and networks

 Has proven it’s value: reference guide for


many new users

13
SystemC AMS language features
Mixed-Signal Virtual Prototypes
written by the end user

SystemC AMS methodology-specific elements


methodology- elements for AMS design refinement, etc.
specific
elements Timed Data Linear Signal Electrical Linear
Transaction-level Flow (TDF) Flow (LSF) Networks (ELN)
modeling (TLM), modules modules modules
Cycle/Bit-accurate ports ports terminals
modeling, etc. signals signals nodes

Scheduler Linear DAE solver

Time-domain and small-signal frequency-domain


simulation infrastructure (synchronization layer)

SystemC Language Standard (IEEE Std. 1666-2011)

14
SystemC AMS methodology elements
 Support design refinement using different models of computation
- Timed Data Flow (TDF) - efficient simulation of discrete-time behavior
- Linear Signal Flow (LSF) - simulation of continuous-time behavior
- Electrical Linear Networks (ELN) - simulation of network topology & primitives

 Using namespaces
- Clearly identify the used model of computation
- Unified and common set of predefined classes, (converter) ports and signals

 Examples
- Module sca_tdf::sca_module sca_lsf::sca_module
- Input port sca_tdf::sca_in sca_lsf::sca_in
- Output port sca_tdf::sca_out sca_lsf::sca_out
- Signals sca_tdf::sca_signal sca_lsf::sca_signal
- Nodes (electrical only) sca_eln::sca_node
- Terminal (in/output port, electrical only) sca_eln::sca_terminal

15
Timed Data Flow (TDF)
V(t)

t
A B outC

Possible schedule: {A→B→C}

TDF module TDF signal TDF port TDF cluster

 TDF is based on synchronous dataflow


- A module is executed if enough samples are available at its input ports
- The number of read/written samples are constant for each module activation
- The scheduling order follows the signal flow direction
 The function of a TDF module is performed by
- reading from the input ports (thus consuming samples)
- processing the calculations
- writing the results to the output ports
 The TDF model of computation is a discrete-time modeling style

16
Linear Signal Flow (LSF)
LSF port LSF module LSF signal LSF equation system

d
x(t) k1 k y(t)
dt
x(t)

k2
t

 Continuous-time behavior described in the form of block diagrams


- LSF primitives describe relations between variables of a set of linear algebraic
equations

 Only a single quantity is used to represent the signal


- There is no dependency between flow (e.g. current) and potential
(e.g. voltage) quantities
- Uses directed real-valued signals, resulting in a non-conservative system
description

17
Electrical Linear Networks (ELN)
ELN equation system ELN node ELN terminal

va C vb

i1 R1 R2 ELN reference node


(ground)

 ELN modeling style allows the instantiation of electrical primitives


- Connected ELN primitive modules will form an electrical network

 The electrical network is represented by a set of differential


algebraic equations
- following Kirchhoff’s voltage law (KVL) and Kirchhoff’s current law (KCL)

 ELN captures conservative, continuous-time behavior

18
Dynamic Timed Data Flow modeling

 Abstract modelling of sporadically changing signals


- E.g. power management that switches on/off AMS subsystems

 Abstract description of reactive behaviour


- AMS computations driven by events or transactions

 Capture behaviour where frequencies (and time steps) change


dynamically
- Often the case for clock recovery circuits or capturing jitter

 Modelling systems with varying (data) rates


- E.g. multi-standard / software-defined radio (SDR) systems

This requires a dynamic and reactive Timed Data Flow modeling style
- Basically introduce variable time step instead of fixed/constant time step

19
Example: DC motor control
difference PI controller PWM Driver + DC motor
iref k vdrv
kp + i out
s
h0
imeas s
1+
ω0

 Functional model in the Laplace domain modelled in SystemC AMS


 To achieve high accuracy, many module activations are necessary
when using fixed time steps (AMS 1.0)
 Introducing Dynamic TDF to only compute when necessary, due to
dynamic time step mechanism (AMS 2.0)

20
DC motor control loop behavior
10
imeas (t) iref
8
2 3
6

2 1 4 1
t_ramp
0 t_duty t/sec
0 0.01 0.02 0.03 0.04 0.05t_period
0.06 0.07 0.08 0.09 0.1

vdrv (t) 1
0.5

0 t/sec
0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1

21
Example of Pulse Width Modulator (1)
// pwm_dynamic.h

#include <cmath>
#include <systemc-ams>

SCA_TDF_MODULE(pwm) // for dynamic TDF, we can use the same helper macro to define the module class
{
sca_tdf::sca_in<double> in;
sca_tdf::sca_out<double> out;

pwm( sc_core::sc_module_name nm, ... )


: in("in"), out("out") {}

void set_attributes()
{
does_attribute_changes(); // module allowed to make changes to TDF attributes
accept_attribute_changes(); // module allows attribute changes made by other modules
}

void change_attributes() // new callback to change attributes during simulation


{
double t = get_time().to_seconds(); // current time
double t_pos = std::fmod( t, t_period); // time position inside pulse period
...

22
Example of Pulse Width Modulator (2)
if ( t_pos < t_ramp ) {
// rising edge
request_next_activation( t_ramp - t_pos, sc_core::SC_SEC );
1
} else if ( t_pos < t_ramp + t_duty ) {
// plateau
request_next_activation( ( t_ramp + t_duty ) - t_pos, sc_core::SC_SEC ); 2
} else if ( t_pos < t_ramp + t_duty + t_ramp ) {
// falling edge
request_next_activation( ( t_ramp + t_duty + t_ramp ) - t_pos, sc_core::SC_SEC ); 3
} else {
// return to initial value
request_next_activation( t_period - t_pos, sc_core::SC_SEC ); 4
}
}
2 3
void processing()
{
... // PWM behavior
1 4 1
}
t_ramp
t_duty
private:
t_period
... // member variables
};

23
TDF vs. Dynamic TDF comparison
TDF model of t_step t_ramp t_period Time accuracy #activations
computation variant (ms) (ms) (ms) (ms) per period
0.01
Conventional TDF 0.05 5.0 0.01 ( = t_step) 500
(fixed)
defined by
Dynamic TDF variable 0.05 5.0 4
sc_set_time_resolution()

 Comparison of the two variants of the TDF model of computation


- Conventional PWM TDF model uses a fixed time step that triggers too many
unnecessary computations
- When using Dynamic TDF, the PWM model is only activated if necessary.

24
Summary and outlook

 SystemC AMS developments are fully driven and supported by


European industry: NXP, ST, Infineon, and Continental
- Applications: communication, automotive and imaging systems design

 SystemC AMS is a mature and proven standard


- SystemC AMS 1.0 was released in March 2010, introducing efficient AMS
modeling and system-level simulation
- SystemC AMS 2.0 was released in March 2013, introducing reactive and
dynamic behavior for AMS computations

 Third party Proof-of-Concept implementation for SystemC AMS 1.0


available under Apache 2.0 license
- Thanks to Fraunhofer IIS/EAS Dresden

 Commercial design environments supporting SystemC AMS are


available in the market
25
More information

 www.accellera.org
 www.accellera.org/downloads/standards/systemc/ams
 www.accellera.org/community/articles/amsspeed
 www.accellera.org/community/articles/amsdynamictdf
 www.systemc-ams.org

26
Thank you
Case Studies in SystemC

UVM for SystemC Users


John Stickley, Mentor Graphics
Gordon Allan, Mentor Graphics
UVM for SystemC users
 The case for hybrid testbenches

 Standards for hybrid testbenches

 What is UVM-Connect?

 UVM-Connect primer

 Reuse of legacy IP models

 Interchangeable testbench heads

 Dual use UVM drivers

 Hybrid testbench examples

 Summary
2 March 3, 2014 © 2014 Mentor Graphics Corp.
The case for hybrid testbenches
 Mounting use of TLM 2 as the common interconnect for multi-language HVL
testbench environments:
- TLM-2 standard is already “baked in” to IEEE 1666 SystemC and SV-UVM standards
- Open-source public donations for “cross language connectivity fabric” are TLM-2
based and are already out there:
- UVM-Connect - from Mentor Graphics
- UVM-ML - from Accellera MLWG

 It makes sense to combine the strengths of 2 verification methodologies


(SV-UVM, SystemC) into hybrid testbenches
- Power of SystemVerilog UVM:
- Constrained random traffic/sequence generation
- Coverage, scoreboarding
- Power of SystemC:
- Good Linux host system interfacing capability which it gets for free simply by being written in C++
- Direct access to host resources disks, networks, device drivers, X-windows displays, etc.
- Stimulus via real host machine system interfaces and virtual platforms

3 March 3, 2014 © 2014 Mentor Graphics Corp.


The case for hybrid testbenches
 Types of hybrid testbenches:
- Reuse of legacy IP models
- Often RTL verification IP models come with C/C++ based APIs based on
SystemVerilog P1800 DPI standard
- Desirable to integrate this IP into SV-UVM testbench environments
- Interchangeable testbench heads
- A single source verification IP model can get reuse from multiple testbench modeling
methodologies
- Providing a TLM compliant socket API allows “interchangeable testbench heads”
- Dual use UVM drivers
- UVM drivers that provide interfaces to RTL models can be equipped with a 2nd TLM
port (in addition to traditional sequencer port) to provide an extra inbound traffic
channel from peer TLM compliant models – possibly cross language ones
- Virtual platform (VP) hybrid testbenches
- Starting to see a number of QEMU derivatives out there which pair fast host based
virtual platforms with RTL designs under test (DUTs)

4 March 3, 2014 © 2014 Mentor Graphics Corp.


Standards for hybrid testbenches:
Achieving Interop with Standard Interfaces
 To interoperate two components must agree on
- information to exchange (i.e., the data type)
- means of exchanging that information (i.e., the interface)

 To be reusable, easy to use, components must be


- Independent of their context, not expose implementation

 Analogy: Media Server and TV


- They don’t know about each other; independent design
- They agree on common data (video) & interface (HDMI)
- Both can be connected to many other devices

Cable Box TV
HDMI

5 March 3, 2014 © 2014 Mentor Graphics Corp.


What is UVM-Connect?
Enabling Technology
 Enables TLM communication between SV+SC
- Using native TLM calls
- Implemented over SystemVerilog P1800 DPI standard

 Leverages UVM TLM 2.0 implementation


- Also supports TLM 1.0 and Analysis ports

 Provided as separate SV and SC packages


 Cross language binding “rendezvous” via a uvmc::connect() method
- Uses a string to identify corresponding sockets

UVM TLM 2.0 SC TLM 2.0


Initiator Socket Target Socket
UVMC

UVM TLM 2.0 SC TLM 2.0


Target Socket Initiator Socket

SV/UVM SystemC
6 March 3, 2014 © 2014 Mentor Graphics Corp.
What is UVM-Connect?
Trans-language TLM connections
• Connect SysC & SV-UVM models using
standard TLM1, TLM2 interface ports TLM1
SysC SV-UVM
• TLM GP handled automatically
• Access and control UVM from SystemC
via command API
• Messaging, configuration, and factory TLM2
methods supported SysC SV-UVM
• Synchronize SystemC to UVM phases
• Standards based, available today
• Vendor-independent
UVM
• Fully open-sourced, Apache licensed SysC Command
SV-UVM
package just like the UVM 1.1b base C / C++
package is
Can obtain from Mentor’s Verification Academy here:
http://verificationacademy.com/verification-methodology/uvm-connect

7 March 3, 2014 © 2014 Mentor Graphics Corp.


UVM-Connect primer
TLM Connection – SV using UVMC
Add a scoreboard, SV-to-SC-to-SV foo
add a connection.
producer consumer

SV SC

import uvm_pkg::*;
import uvmc_pkg::*; SC-to-SV
scoreboard
`include "producer.sv"
`include "scoreboard.sv" compare bar
SV

module sv_main; #include "uvmc.h"


producer prod = new("prod"); using namespace uvmc;
scoreboard sb = new("sb"); #include "consumer.h"
initial begin
prod.ap.connect(sb.expect_in); int sc_main(int argc,char* argv[])
uvmc_tlm #():: {
connect(prod.out, "foo"); consumer cons("consumer");
uvmc_tlm1 #(uvm_tlm_gp):: uvmc_connect(cons.in,"foo");
connect(sb.actual_in, "bar"); uvmc_connect(cons.ap,"bar");
run_test(); sc_start();
end return 0;
endmodule }
8 March 3, 2014 © 2014 Mentor Graphics Corp.
UVM-Connect primer
TLM Connection – UVM-Aware SC  SV
#include <systemc.h> producer consumer
using namespace sc_core;
#include "producer.h" SC SV
#include "uvmc.h"
using namespace uvmc;

struct prod_alt : public producer { extend base producer


prod_alt(sc_module_name nm) :
producer(nm) { background thread
SC_THREAD(objector);
} raise objection, wait for “done”, drop objection
SC_HAS_PROCESS(prod_uvm)
void objector() {
uvmc_raise_objection("run"); import uvm_pkg::*;
wait(done); import uvmc_pkg::*;
uvmc_drop_objection("run"); `include "consumer.sv"
}
}; module sv_main;
consumer cons = new("cons");
int sc_main(int argc,char* argv[]) { initial begin
prod_alt prod("producer"); uvmc_tlm #()::connect(cons.in,"42");
uvmc_connect(prod.in,"42"); uvmc_init();
sc_start(-1); run_test(); SV side must
return 0; end initialize UVMC
} endmodule command API

9 March 3, 2014 © 2014 Mentor Graphics Corp.


Reuse of legacy IP models
DPI based API
RandWriteReadSeq
SV-UVM Test

TestbenchEnv
Scoreboard apbUvc Agent APB Master Top
Compare
actualQ == ApbTalker TlmDriver APB
ApbCover APB Master Master
expectQ Monitor Driver DPI Xactor
DpiDriver

APB Bus
APB
APB Slave
UVM-Connect’ions DPI Slave
DpiDriver
Xactor

APB
APB Monitor Monitor
DPI
TlmDriver Xactor

SystemC Testbench

= TLM-2.0 initiator -> target socket

= TLM analysis port -> subscribers

= Legacy DPI driver


10 March 3, 2014 © 2014 Mentor Graphics Corp.
Reuse of legacy IP models
TLM-2 initiator <-> target sockets
TLM-2 initiator
TLM-2 target
RandWriteReadSeq
SV-UVM Test

TestbenchEnv
Scoreboard apbUvc Agent APB Master Top
Compare
actualQ == ApbTalker TlmDriver APB
ApbCover APB Master Master
expectQ Monitor Driver DPI Xactor
DpiDriver

// UVM-Connect’ed SystemC “target”

APB Bus
class APB {
Testbench : public sc_module
// UVM-Connect’ed SV-UVM uvm_driver “initiator” APB Slave
UVM-Connect’ions DPI
ApbMasterTlmDriver Slave
*apbMaster;
class ApbBusMasterDriver DpiDriver
Testbench( sc_module_nameXactor
name );
extends uvm_driver };
#( uvm_tlm_generic_payload ); // {
class ApbMasterTlmDriver : public sc_module,
`uvm_component_utils(ApbBusMasterDriver) public virtual tlm::tlm_fw_transport_if<>
protected string peerId; // UVM-Connect ID { tlm::tlm_target_socket<32>APB
socket;
uvm_tlm_b_initiator_socket #(uvm_tlm_generic_payload)
initiatorSocket;
ApbMasterTlmDriver(
APB Monitor Monitor
DPI name, const char
sc_module_name *transactorPath );
TlmDriver Xactor
void b_transport(
function new( string name, uvm_component parent );
SystemC Testbench
tlm::tlm_generic_payload &trans,
sc_time &delay );
function void connect_phase( uvm_phase phase ); }

task run_phase( uvm_phase phase ); = TLM-2.0 initiator -> target socket


endclass // }
= TLM analysis port -> subscribers

= Legacy DPI driver


11 March 3, 2014 © 2014 Mentor Graphics Corp.
Reuse of legacy IP models
TLM-2 initiator <-> target sockets
SV-UVM Testbench TestbenchEnv
apbUvc Agent APB Master SystemC Testbench
ApbTalker TlmDriver
ApbCover
Monitor Driver
APB Master
DpiDriver

// UVM-Connect’ed SV-UVM uvm_driver “initiator”


class ApbBusMasterDriver
extends uvm_driver #(uvm_tlm_generic_payload); // {
// UVM-Connect’ed SystemC “target”
`uvm_component_utils(ApbBusMasterdriver)
class Testbench : public sc_module { Construction …
protected string peerId; // UVM-Connect ID
ApbMasterTlmDriver *apbMaster;
uvm_tlm_b_initiator_socket#( uvm_tlm_generic_payload
initiatorSocket; Testbench( sc_module_name name ) : sc_module(name)
Construction …
function new(string name, uvm_component parent); apbMaster = new ApbMasterTlmDriver(
"apbMaster", "Top.apbMasterTransactor" );
super.new(name, parent);
initiatorSocket = new( “initiatorSocket", this ); uvmc_connect( apbMaster->socket, “master" );
endfunction
… Connection … } … Connection …
function void connect_phase( uvm_phase phase ); };
super.connect_phase( phase ); class ApbMasterTlmDriver
// Retrieve HDL path from UVM config DB : public sc_module,
assert( get_config_string( "peerId", peerId ) ) public virtual tlm_fw_transport_if<>
uvmc_tlm #( uvm_tlm_generic_payload, { tlm_target_socket<32> socket;
uvm_tlm_phase_e );
ApbMasterTlmDriver(
::connect( initiatorSocket, peerId );
sc_module_name name, const char *transactorPath )
endfunction
: sc_module( name ), socket(“socket”), …
task run_phase( uvm_phase phase ); … Operation
dTransactorPath( transactorPath )
uvm_tlm_generic_payload request; { socket( *this ); … }
forever begin … Operation
void b_transport(
seq_item_port.get( request );
tlm_generic_payload &trans, sc_time &delay){
initiatorSocket.b_transport( request, delay );
seq_item_port.put( request // Extract fields of TLM GP and convert to DPI calls
endfunction }
12endclass // } March 3, 2014 } © 2014 Mentor Graphics Corp.
Reuse of legacy IP models
TLM-2 analysis broadcasters -> subscribers
TLM-2 analysis export // UVM-Connect’ed SystemC “broadcaster”
(subscriber) class Testbench : public sc_module {
DPI based API
ApbMonitorTlmDriver *apbMonitor;
RandWriteReadSeq
SV-UVM Test Testbench( sc_module_name name );
};
TestbenchEnv class ApbMonitorTlmDriver : public sc_module,
Scoreboard apbUvc Agent public
APB Master Top
tlm::tlm_analysis_port<tlm::tlm_generic_payload>
Compare
actualQ == ApbTalker
{ TlmDriver APB
tlm::tlm_generic_payload dMonitorRecordTrans;
ApbCover ApbMonitorTlmDriver(
APB Master Master
expectQ Monitor Driver sc_module_nameDPI
name, const char *transactorPath );
DpiDriver Xactor
void write( const svBitVecVal *monitorRecord );
}
// Import "DPI-C" function
extern "C" void ApbMonitorWrite(
// UVM-Connect’ed SV-UVM “subscriber”

APB Bus
APB){
const svBitVecVal *monitorRecord
class ApbBusMonitor APB Slave
Slave
DPI*me = (ApbMonitorTlmDriver
extends uvm_subscriber UVM-Connect’ions
ApbMonitorTlmDriver *)
DpiDriver
svGetUserData( svGetScope(),
#(uvm_tlm_generic_payload); // { Xactor
(void *)(&ApbMonitorWrite) );
`uvm_component_utils(ApbBusMonitor) me->write( monitorRecord );
}
protected string peerId; // UVM-Connect ID
uvm_analysis_port #( uvm_tlm_generic_payload ) APB
analysisPort;
APB Monitor Monitor
DPI
TlmDriver Xactor
function new(string name, uvm_component parent);
SystemC Testbench
function void connect_phase( uvm_phase phase );

function void write( uvm_tlm_generic_payload t );


TLM-2 analysis port = TLM-2.0 initiator -> target socket
endclass // }
(broadcaster)
= TLM analysis port -> subscribers

= Legacy DPI driver


13 March 3, 2014 © 2014 Mentor Graphics Corp.
Reuse of legacy IP models
TLM-2 analysis broadcasters -> subscribers
SV-UVM Testbench TestbenchEnv // UVM-Connect’ed SystemC “broadcaster”
apbUvc Agent class Testbench : public sc_module {
ApbMonitorTlmDriver *apbMonitor; Construction …
ApbTalker

ApbCover Testbench( sc_module_name name ) : sc_module(name)


Monitor Driver
apbMonitor = new ApbMonitorTlmDriver(
"apbMonitor", "Top.apbMonitor" ); … Connection …
// UVM-Connect’ed SV-UVM “subscriber” uvmc_connect( *apbMonitor, "monitor" );
class ApbBusMonitor
extends uvm_subscriber }
#(uvm_tlm_generic_payload); // { };
`uvm_component_utils(ApbBusMonitor) class ApbMonitorTlmDriver
protected string peerId; // UVM-Connect ID : public sc_module,
uvm_analysis_port #( uvm_tlm_generic_payload public tlm::tlm_analysis_port<tlm::tlm_generic_payload>
analysisPort; Construction … { tlm::tlm_generic_payload dMonitorRecordTrans;
function new(string name, uvm_component parent); ApbMonitorTlmDriver(
super.new(name, parent); sc_module_name name, const char *transactorPath )
analysisPort = new( "analysisPort", this ); : sc_module( name ),
endfunction … Connection … tlm::tlm_analysis_port<
function void connect_phase( uvm_phase phase ); tlm::tlm_generic_payload>(name),
dTransactorPath( transactorPath ) { } … Operation
super.connect_phase( phase );
// Retrieve peer ID from UVM config DB. If cannot void write( const svBitVecVal *monitorRecord ){
// be found, assume this TB is not interested in dMonitorRecordTrans.set_data_ptr(
// hooking up the monitor. Else, UVM-Connect it. const_cast<unsigned char *>(
// Note reference to 'analysis_export' data member reinterpret_cast< const unsigned char *>(
// of base class uvm_subscriber. monitorRecord) ) );
if( get_config_string( "peerId", peerId ) ) tlm::tlm_analysis_port<
uvmc_tlm1 #(uvm_tlm_generic_payload) tlm::tlm_generic_payload>::write(
::connect( analysis_export, peerId ); dMonitorRecordTrans );
endfunction … Operation }
function void write( uvm_tlm_generic_payload t ); }
analysisPort.write( t ); APB Monitor
endfunction TlmDriver
14endclass // } March 3, 2014 SystemC
© 2014 Testbench
Mentor Graphics Corp.
Interchangeable testbench heads
UART transactor example
= TLM-2.0 initiator -> target socket

::b_transport()
::nb_transport_fw() = UVM-Connect “hidden”
TLM conduit infrastructure

UartTargetTransactor has 4
::nb_transport_bw() interchangeable initiator clients:
::nb_transport_bw()
::b_transport()  SV-UVM TLM 2 test sequence client
::nb_transport_fw()
UartFileIo
 SV-UVM TLM 2 file i/o client
Client  SystemC TLM-2.0 xterm client
(SV/UVM)  SystemC TLM-2.0 file i/o client

::b_transport()
::nb_transport_bw()
::nb_transport_fw()
UartFileIo
Client
(SysC)

::b_transport()
::nb_transport_bw() ::nb_transport_fw()
UartXterm UartTarget
Client Transactor
(SysC)

15 March 3, 2014 © 2014 Mentor Graphics Corp.


15
Dual use UVM drivers
RandWriteReadSeq SV-UVM
TestbenchEnv Testbench
Top
Scoreboard
Compare
actualQ ==
AxiUvc
AXI “Front-door”
expectQ
DPI AXI Master
Master path
Xactor
Driver SCE-MI 2

AXI Bus
Pipes

SystemC Testbench
TLM-2 ports SysC+Tlm AXI Slave
are unused AXI Slave Xactor
Memory Memory
Driver DPI
Xactor

 This configuration demonstrates a dual use SV-UVM


= TLM-2 fabric
driver equipped with both a sequencer port and a TLM-
2 port = TLM-2.0 initiator -> target socket

 In this case the TLM-2 port in both the SV-UVM driver = TLM analysis port -> subscribers
and the slave memory (back-door port) are unused
16 March 3, 2014 © 2014 Mentor Graphics Corp.
Dual use UVM drivers Sequencer port
is unused

SV-UVM Testbench
TestbenchEnv
SystemC Top
Testbench
AxiUvc
FrontBack “Front-door”
Tester AXI DPI AXI Master
Master path
Xactor
Driver SCE-MI 2

AXI Bus
Pipes

“masterSocket” UVM-Connect’ion

SysC+Tlm AXI Slave


TlmMemory “back-door socket” AXI Slave Xactor
UVM-Connect’ion
Xactor Memory Memory
BackDoor Driver DPI
Xactor
Driver

“Back-door”
path
= TLM-2 fabric
 This configuration demonstrates a dual use
= TLM-2.0 initiator -> target socket
SV-UVM driver equipped with both a
sequencer port and a TLM-2 port = TLM analysis port -> subscribers

 In this case the sequencer port is unused


17 March 3, 2014 © 2014 Mentor Graphics Corp.
Hybrid testbenches: Virtual platform example
Guest OS (Android/Linux)
Virtual Machine (FastModel FVP Simulator)
HVL Testbench (SystemC and/or SystemVerilog) Co-Model Host

TestbenchEnv soc_hdl_top Veloce


AXI Agent

AxiTalker
AxiCover
soc_dut_wrapper
Monitor Driver

SV-UVM
Coverage Harness

AXI “Agent”
axi_dut_wrapper
AXI Master clocks, reset
Driver+Xactor Clock & Reset
AXI Generation
Bridge AXI_IF
Tlm2Rtl AXI Slave
Graphics
Driver+Xactor Subsystem
Interrupt
Monitor
SystemC
ARM FastModel TBX
Virtual Platform Co-model
Channel (DPI)

18 March 3, 2014 © 2014 Mentor Graphics Corp.


Hybrid testbenches: Ethernet packet router example
... an SV
scoreboard, ...

... a SystemC golden


reference model, ...

... an SV constraint ... and an SV


solver, ... coverage analyzer.

Each “dotted line” TLM


crossing is a UVM-Connect’ion !
This configuration uses SystemC
DPI based legacy models, ...

19 March 3, 2014 © 2014 Mentor Graphics Corp.


Summary
 There is a good case to made for hybrid SV-UVM SystemC
testbenches:
- Supporting legacy IP models
- Interchangeable testbenches can be coupled with reusable verification IP
models
- UVM drivers can be designed for "dual use" to accomodate alternative TLM
channels for input
- Hybrid testbenches allow taking combining of strengths of SystemC …
− Virtual platforms, "real system" interfaces
… with those of SV
− Constrained random sequences, coverage, scoreboarding

 The TLM 1 and 2 standards are well supported by both SV-UVM and
SystemC methodologies
- There are now open-source "cross-language" TLM connectivity packages
readily available - and being considered for standardization

20 March 3, 2014 © 2014 Mentor Graphics Corp.


Thank you

You might also like