SystemC Tutorial - Microelectronic Systems Laboratory

Using SystemC for 

SoC modelling and design 

Marc Pauwels - Ates Berna 

Fatma Özdemir - Yves Vanderperren 

marc.pauwels@mie.alcatel.be 

15.01.2002 

All rights reserved 

© 2002 - Alcatel 

Microelectronics

Outline 

t I. Introduction to SystemC 

t II. The AME System Design Methodology 

t III. The SystemC Language and its features in practice 

t IV. The AME System Design Methodology in practice 

t V. AME’s Experience with SystemC based design 

t VI. Summary and Conclusions 

15.01.2002 SystemC Tutorial © 2002 - Alcatel Microelectronics 

Part I - slide 2

Part I. 

Introduction to SystemC 


Part I - slide 3

Outline 

Part I. Introduction to SystemC 

t 

t 

t 

t 

t 

What is SystemC ? Target and basic features 

OSCI : Open Source SystemC Initiative 

Roadmap and evolution 

The AME User perspective 

Summary and Conclusion 


Part I - slide 4

Intro to SystemC 

( What is SystemC ? ) 

t 

t 

t 

System design language for HW/SW co-design 

A library of C++ classes 

• Processes (for concurrency) 

• Clocks (for time) 

• Hardware (finite) data types [bit vectors, 4-valued 4 

logic, fixed- 

point types, arbitrary precision integers] and infinite data types 

• Waiting and watching (for reactivity) 

• Modules, ports, signals (for hierarchy) 

• Abstract ports and protocols (abstract communication) 

A light-weight simulation kernel 

t 

Allows to make an “Executable Specification” 


Part I - slide 5



t 

SystemC enables System design and verification 

HW 

Implementation 

Verification & 

Analysis 

SW 


System 

System 

Level IP 

RTL 

Soft IP 

C-CompilerCompiler 

Physical 

Hard IP 

( Courtesy: OSCI ) 


Part I - slide 6



t 

Levels of 

Abstraction : 

SystemC 

UTF 

Functional decomposition 

Untimed Functional 

• UTF 

• TF 

• BCA 

• CA 

Design Exploration 

Performance Analysis 

HW/SW partitioning 

TF 

Assign ‘execution time’ 

Timed Functional 

HW / SW Partition 

Architectural mapping 

Refine communication 

Task Partitioning 

Abstr. 

RTOS 

BCA 

Bus Cycle Accurate 

Refine behavior 

Target RTOS/Core 

RTOS 

RTL 

Cycle Accurate 


Software 

Hardware 


Part I - slide 7



t 

Gradual Refinement 

• Key of methodology is : 

design may be refined in 

gradual step-wise fashion, 

rather than one giant step. 

It is not “all or nothing”. 

UTF UTF UTF 

UTF UTF 

UTF UTF TF 

Simulation 

Simulation 

• UTF 

• TF 

• BCA 

• CA 

Details added 

to portions of 

the system. 

UTF 

TF 

TF BCA RTL 

UTF RTL 

Simulation 



Part I - slide 8

The OSCI 

( Open initiative ) 

t 

SystemC is “Open Source Initiative” 

• Open Source License : code & usersGuide 

• Language and Reference Simulator : www.systemC 

systemC.org 

• Platforms : Unix ( gcc v2.95 ) - Linux - WinNT/2000 

t 

OSCI : became non-profit 

organization 

• OSCI board and steering group 

• OSCI working groups 

t language, reference implementation, dataflow, , IP 

integration, verification 

• User Discussion Forum : Q&A via www.systemC 

systemC.org 

• User Meetings 

t 4th ESCUG (Oct 5 2001 - Copenhagen) 

t www-ti 

ti.informatik.uni-tuebingen.de/~ 

.de/~systemc 


Part I - slide 9

The OSCI 

( Steering Committee ) 

t 

Open SystemC Initiative Steering Group 



Part I - slide 10

The OSCI 

( User Community ) 

t 

SystemC User Community : Alcatel amongst the early adopters 



Part I - slide 11

The OSCI 

( User Community ) 

t 

Continued Strong SystemC Adoption : Big momentum... 

Users/Downloads 

20000 

15000 

10000 

5000 

Downloads 

Licensed Users 

SystemC v1.0/1.1beta 

Released 

0 

sep/99 

nov/99 

jan/00 

mrt/00 

mei/00 

jul/00 

sep/00 

nov/00 

jan/01 

mrt/01 

mei/01 



Part I - slide 12

Roadmap 

( Evolution ) 

t 

History and evolution of SystemC 

Scenery 

Sep. 99 

1997 DAC Paper 


v0.90 

Apr. 00 

Backwards 

Compatible 

Fixed Point Types 


v1.0 

Jun. 00 

RPC 

Abstract 

Protocols - 

Master Slave 

Ports 


v1.1 

Feb. 01 


v1.2b 

Sep. 01 


v2.0b2 


Part I - slide 13

Roadmap 

( Current versions ) 

t 1.0 - Hardware Design Flow 

• RTL and Behavioral Hardware Modelling 

t 1.x - Master-Slave Communication Library 

• Extension to system-level 

Modelling and 

different levels of abstraction 

• RPC-based 

untimed & timed functional modelling 

down to RTL for bus protocol based systems 

t 2.0 - System Design Flow 

• General purpose communication and synchronization 

• Communication Refinement 

• Multiple, customizable models of computation 


Part I - slide 14

Roadmap 

( Future versions ) 

Foreseen for the future … 

t 2.X - Extensions to System Design Flow 

• Dynamic thread creation, fork / join 

• Interrupt / abort for behavioral hierarchy 

• Performance modelling support 

• Timing specification and constraints 

t 3.X - Software Design Flow 

• Abstract RTOS modelling 

• Scheduler modelling 

t 4.X - Analog / Mixed Signal Systems Modelling 


Part I - slide 15

AME User Perspective 

( Used versions and aspects ) 

t 1.0 - Hardware Design Flow 

t 1.x - Master-Slave Communication Library 

• Extension to system-level 

Modelling and 

different levels of abstraction 

• RPC-based 

untimed & timed functional modelling 

down to RTL for bus protocol based systems 

t 2.0 - System Design Flow 

t 2.X - Extensions to System Design Flow 

• Interrupt / abort for behavioral hierarchy 

interruptsi 

• Performance modelling support 

performance 

• Timing specification and constraints 


v1.2b 

timing 

t 3.X - Software Design Flow 

Firmware 


Part I - slide 16

AME User Perspective 

( Design Flow ) 

t 

Used Levels of 

Abstraction : 

• TF 

• CA 


Matlab 

UTF 

TF 

Algorithmic 

Design and 

Validation 

System 

Design and 

Validation 

Function 

Abstr. 

RTOS 

BCA 

BCA 

RTOS 

CA 

C 

Software 

Hardware 

Firmware 

Software 

Design and 

Validation 

Hardware 

Design and 

Validation 

Firmware 

Design and 

Validation 

Target 


Part I - slide 17

Summary 

t 

From OSCI 

• SystemC language & ref.simulator available 

• Long-term Roadmap : continuity in versions 

t 

At Alcatel Microelectronics 

• Early adoption of SystemC v1.1β since 2000 

• Started with no other tools than reference simulator (but 

C++…) 


Part I - slide 18

Conclusion 

t 

At Alcatel Microelectronics 

• Language is not sufficient : one needs vision on Methodology 

• Used v1.2β in real life SoC design project (OWL , since 

Jan2001) from which Methodology was derived 

• Target: Executable model of system under design 

as reference and baseline for design phase 

• Tools supporting the design flow are yet to follow 

t 

SystemC and OSCI are the seed for : 

• System Design Methodology 

• Tools (simulation, co-simulation, synthesis, verification…) 

• Standardization ( IEEE, SpecC, , VSIA, … ) 


Part I - slide 19

Part II. 

Alcatel Microelectronics’ 

System Design Methodology 

O 

W 

L 

Ofdm 

Wireless 

Lan 

The WLAN-OWL project 


Part II - slide 1

Outline 

Part II. AME’s System Design Methodology 

t 

t 

t 

Evolution from ASICs towards SoC 

SoC example : AME’s OWL project 

AME’s System-on 

on-Chip Design Methodology 


Part II - slide 2

Evolution towards SoC 

( In general … ) 

t Evolution of IC (Manufacturing) Technology : 

t 

t 

• getting smaller 

• with possibility of larger functions on the die 

Evolution of System Designs 

• get System on ChipSet or ultimately single chip ( SoC ) for reasons of 

t 

t 

cost saving 

compactibility 

SoC are complex and contain many components : 

Hw,Fw 

Fw,Sw… 

• all must inter-operate correctly and 

• must fit to Customer specifications 

• must be developed with faster-time 

time-to-market 

è Need for System-on 

on-Chip (SoC( 

SoC) ) Design Methodology 


Part II - slide 3


( In general … ) 

( Source: IMEC ) 

http://www.imec.be/desics 


Part II - slide 4


( At AME … ) 

Example : evolution within Alcatel Microelectronics : 

t 1985 : ASIC Design 

t 1995 : Start of ASSP 

Start of System design (bottom-up) 

• ADSL : going from “chips” … [ 

: ic’s ] 

up to “boards” and ... [demonstrators : hw + fw + bom] 

up to “PC-drivers” … [ : sw ] 

Start of System conception (top-down) 

• WLAN-OWL Project of today 

t initially just ‘matlab’‘ 

coding 

t introduction of ‘SystemC’‘ 

and the ‘System Design Methodology’ 


Part II - slide 5

The OWL Project 

( The product in general ... ) 

t 

t 

t 

High Speed Wireless LAN: Wireless networking at speeds > 10 Mbps 

Applications 

t 

t 

home environment: wireless video and multi-medea 

medea (TV-set, VCR, 

external video link), wireless LAN, VoIP, , access to internet, ... 

business environment: wireless LAN, video-conferencing, multi- 

media,... 

Units and 

communication 

(DL, DiL, , UL) 

AP 

CC 

MT1 

MT2 

MT3 

MT4 

MAC-Frame(2ms): 

BC-Phase DL-Phase DiL-Phase UL-Phase RA-Phase BC-Ph ... 


Part II - slide 6


( The product in general ... ) 

t 

The ETSI HiperLAN-2 2 Standard 

• Network Layers 

E.g.: Ethernet FireWire ... 

Core 

Network 

Core 

Network 

CL - Specific Part 

Network Convergence Layer 

CL - Common Part 

Data Link Control Layer 

[ MAC - DLC ] 

Physical Layer 

[ PHY ] 

HiperLAN-2 

Core 

Network 

• Different flavours 

t Business- 

environment 

t Home- 

environment 

è Hardware 

è Firmware 

è Software 


Part II - slide 7

t 


( AME’s view on the product ... ) 

AME’s HiperLAN-2 SoC ( The OWL Chipset ) 

Core 

Network 

Core 

Network 




Core 

Network 

Analog 

Digital 


[ MAC - DLC ] 

RF Layer BaseBand PHY Layer MAC / DLC Layer CL Layer 


[ PHY ] 

HiperLAN-2 

RF 

front 

end 

PCB Board and 

Components 

Transmit Data-Path 

& 

Local Controller 

HardWare 

Receive Data-Path 

& 


FirmWare/SoftWare 

Global 

Controller 

SDRAM 

(Fw/Sw) 

(E)PROM 

(Fw/Sw) 

Program 

CL 

User 

SAP 

CL 

Control 

SAP 

Application 

SoftWare 


Part II - slide 8

Outline 

Part II. AME’s System Design Methodology 

t 

t 

t 

Evolution from ASICs towards SoC 

SoC example : AME’s OWL project 

AME’s System-on 

on-Chip Design Methodology 

• Methods and tools : merging HW and SW worlds... 

• Iterative and model-based design 

• SystemC based executable model 

• SystemC based testbench reuse 

• SystemC reference for Hw and Fw/Sw 

design (Co-simulation) 


Part II - slide 9

Hw Design 

• Classical Design 

ð Vhdl Synthesis 

ð Simulation 

ð P&R 

• Re-use to reduce complexity 

ð uCore platform 

ð IP-block re-use 

SoC Design Methodology 

( Methods and tools … ) 

System Design 

• Iterative Design RUP 

• Matlab modelling ML 

• SystemC modelling SC 

SOC 

System Validation 

& Qualification 

• Co-simulation 

SC/ISS/Vhdl 

Sw Design 

• Iterative Design RUP 

ð Requir.capture CQ 

& tracking 

ð Use Cases UC 

ð Modelling UML 


Part II - slide 10


( Iterative design methodology ... ) 

t 

OWL Case : R&D Trajectory is ITERATIVE & MODEL based 

• Re-use of SW methodology coming from RUP in project context 

• Main target : reduce Risks in order to get ASAP Working product 

• Early feedback from Executable SystemC model in First iteration 

• Models are not “throw-away” but re-used throughout iterations 

• SystemC is baseline for next iterations : testbench reusage 

• keep models well-documented, high-quality and consistent ! 

S 

It.0 

It.1 

It.2 

It.3 

matlab 

systemC 

VHDL\ISS 

FPGA 

Silicon 


Part II - slide 11

t 

t 


( SystemC modelling ... : targets ) 

OWL - Iteration 0 : Big SystemC modelling effort 

• From 

To 

Matlab 


[algorithms] 

Objectives of the SystemC model 

[behaviour,, system/hw 

hw/fw 

, architecture ] 

• The model is the executable specification 

• The model is a tool during iteration 0 (definition phase) to 

t verify the over-all system behaviour and architecture 

t detail the architecture for critical blocks 

t do finite-precision design 

t generate test-benches 

• The model is a reference for the next iterations: 

t test benches are the starting point for all other test benches (RT( 

RT- 

level,…) and system test plans ( Lab qualification ) 

t The model is a tool during debugging to analyze “where it 

goes wrong” 


Part II - slide 12


( OWL System ... ) 

t 


Analog 

Digital 


RF 

front 

end 

Transmit Data-Path 

& 



& 


CL 

User 

SAP 

Global 

Controller 

CL 

Control 

SAP 

Program 

SDRAM 

(Fw/Sw) 

(E)PROM 

(Fw/Sw) 


Part II - slide 13


( OWL Architecture ... ) 

t 

OWL HW and FW partitioning 

RF 

Rx 

TimeD 

F 

I 

F 

O 

CMPY 

F 

I 

F 

O 

FFT 

F 

I 

F 

O 

FreqD1 

F 

I 

F 

O 

FreqD2 

CL 

Rx 

Hw 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

DPRam 

DPRam 

DPRam 

DPRam 

DPRam 

RF Cmd 

& Status 

Processor 

CL Cmd 

& Status 

Fw 


Part II - slide 14


( OWL SystemC modelling ... ) 

t 

SystemC model of “Hw 

+ Fw/Sw 

+ System” 

TimeD 

F 

I 

F 

O 

CMPY 

F 

I 

F 

O 

FFT 

F 

I 

F 

O 

FreqD1 

F 

I 

F 

O 

FreqD2 

Hw 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

DPRam 

DPRam 

DPRam 

DPRam 

DPRam 

Processor 

Fw 

Operational & TestBench FirmWare 

t 

Spec to start Hw-Design and Fw-Design … 


Part II - slide 15


( OWL SystemC modelling ... ) 

t 

Used Levels of 

Abstraction : 

• TF 

• CA 


Matlab 

UTF 

TF 

Algorithmic 

Design and 

Validation 

System 

Design and 

Validation 

Function 

SYSTEM 

Abstr. 

RTOS 

BCA 

BCA 

TF CA TF 


Sim. 

RTOS 

CA 

C 

CA 

HW 

Design 

HW 

TF 

FW 

Design 

FW/SW 


Co-Sim. 

Software 

Software 

Design and 

Validation 

Hardware 

Hardware 

Design and 

Validation 

Firmware 

Firmware 

Design and 

Validation 

Target 


Part II - slide 16


( OWL design and co-simulation … ) 

t 

OWL - Iteration 1 : start of “Design” 

• Start of HW design (vhdl( 

vhdl) 

• Start of FW design (C on ARM-processor platform) 

t 

t 

SystemC as Specification and Golden Reference 

Co-simulation as validation 

• SystemC co-simulation with ISS 

• SystemC co-simulation with vhdl 

TARGET: FW validation 

TARGET: HW validation 


Part II - slide 17



t 

SystemC model as reference for “Hw 

(Vhdl)) design” 

TimeD 

DPath 

LCtrl 

TimeDomain 

F 

I 

F 

O 

CMPY 

DPath 

LCtrl 

Complex MPY 

F 

I 

F 

O 

DPath 

LCtrl 

FFT 

FFT 

F 

I 

F 

O 

FreqD1 

F 

I 

F 

O 

FreqD2 

DPath 

LCtrl 

Freq Dom 2 

Section 

Hw 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

DPRam 

DPRam 

DPRam 

DPRam 

DPRam 

Processor 

Fw 


t 

SystemC and Vhdl Co-simulation 


Part II - slide 18



t 

SystemC model as reference for “FW (C-code) design” 

TimeD 

F 

I 

F 

O 

CMPY 

F 

I 

F 

O 

FFT 

F 

I 

F 

O 

FreqD1 

F 

I 

F 

O 

FreqD2 

Hw 

LCtrl 

DPRam 

LCtrl 

DPRam 

LCtrl 

DPRam 

LCtrl 

DPRam 

LCtrl 

DPRam 

D 

SRAM 

I 

SRAM 

CPU Core 

ARM Processor 

MAC 

Processor 

ISS : 

Instruction 

Set 

Simulator 


Fw 

t 

SystemC and ISS Co-simulation 


Part II - slide 19



t 

SystemC and vhdl and ISS Co-simulation 

TimeD 

DPath 

LCtrl 

TimeDomain 

LCtrl 

DPRam 

F 

I 

F 

O 

CMPY 

LCtrl 

DPRam 

F 

I 

F 

O 

DPath 

LCtrl 

FFT 

FFT 

LCtrl 

DPRam 

F 

I 

F 

O 

FreqD1 

LCtrl 

DPRam 

F 

I 

F 

O 

FreqD2 

LCtrl 

DPRam 

Hw 

D 

SRAM 

I 

SRAM 

CPU Core 

ARM Processor 

MAC 

Processor 

ISS : 

Instruction 

Set 

Simulator 


Fw 


Part II - slide 20


( SystemC modelling ... ) 

t 

Cf. . Part-IV : The Complex-MPY section as Tutorial example 

TimeD 

F 

I 

F 

O 

CMPY 

F 

I 

F 

O 

FFT 

F 

I 

F 

O 

FreqD1 

F 

I 

F 

O 

FreqD2 

Hw 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

DPRam 

DPRam 

DPRam 

DPRam 

DPRam 

Processor 

Fw 



Part II - slide 21

Summary and Conclusion 

t 


• Merging HW and SW worlds… 

t From conception till Lab-qualification 

• Iterative 

• Model based 

• Derived from OWL : a real-life life project 

t 

SystemC model in Iteration-0 

• Executable spec (with early feedback) 

• Baseline for next Iterations (HW and FW design) 

• Co-simulation with re-use of test-benches 


Part II - slide 22

Part III. 

SystemC language in practice 


Part III - slide 1

Outline 

Part III. 

SystemC Language in practice 

t 

Context 


v1.2b 

• SystemC from AME-user perspective 

• For complete User-Guide and Syntax : cfr. . www.systemC 

systemC.org 

• SystemC is extendable ( library of C++ classes ) 

t 

SystemC as from the web 

t 

Alcatel Microelectronics extensions 

t 

Summary 


Part III - slide 2

Part III. 

t 

t 

t 

t 

Context 

Outline 



• System design 

• Modules and hierarchy 

• Processes and concurrency 

• Data types 


• The C++ behind SystemC 

• Matlab front-end 

• Fixed and floating point models 

Summary 


Part III - slide 3

t Abstract view on a system : 

System design 

Module 1 Module 2 

Process A 

ports 

System 

Process B 

signals 

Process C 

t 

SystemC adds specific features on top of C++ 

• behaviour (modules/processes) and 

communication (ports/signals) are split 

• concurrent and sequential behaviour 

• different time-models models (abstraction levels) 

• mapped on single thread of execution 

• implementation specific features (e.g. fixed-point data-types types ) 


Part III - slide 4

System design 

t 

SystemC design flow: 

* Procedural language 

with path towards 

implementation 

* Executable 

Specification 

* 4 Levels of 

Abstraction : 

• UTF : System level 

• TF 

: System level 

• BCA : Behavioural 

• CA 

: RTL 

Software 

Matlab 


Design Exploration 

Performance Analysis 

HW/SW partitioning 

Task Partitioning 

Abstract RTOS 

Inter process comm. 

Scheduling/priority 

Target RTOS/Core 

Silage 

Abstr. 

RTOS 

RTOS 

SDL Esterel Others 

UTF 

TF 

Functional decomposition 

Untimed Functional 

Assign ‘execution time’ 

Timed Functional 

HW / SW Partition 

Architectural mapping 

Refine communication 

BCA 

RTL 

Bus Cycle Accurate 

Refine behavior 

Cycle Accurate 

Hardware 


Part III - slide 5

System design 

t 

Gradual Refinement 

• Key of methodology is : 

design may be refined in 

gradual step-wise fashion, 

rather than one giant step. 

It is not “all or nothing”. 

UTF UTF UTF 

UTF UTF 

simulation 

Simulation 

• UTF 

• TF 

• BCA 

• CA 

Details 

gradually 

added to 

portions of the 

system. 

UTF UTF TF 

UTF 

TF 

TF BCA RTL 

UTF RTL 

simulation 

simulation 

Simulation 

Simulation 


Part III - slide 6

Part III. 

t 

t 

t 

t 

Context 

Outline 











Summary 


Part III - slide 7

t 

t 

Module is a structural entity 

• helps to split complex designs 

Module can contain 

• ports 

• processes 

• user defined C++ functions 

• internal member data 

• constructor 

• modules and signals 

In 

Clk 

Rst 

accumulator 

Acc_ 

Modules 

Out 


Part III - slide 8 

t 

Note: valid for 

è Hardware 

è 

Firmware/Software 

è System 

SC_MODULE(accumulator) 


{ 

{ 

// 

// 

ports 

ports 

(input) 

(input) 

sc_in 

sc_in 

In; 

In; 

sc_in 

sc_in 

Rst; 

Rst; 

sc_in_clk 

sc_in_clk 

Clk; 

Clk; 

// 

// 

ports 

ports 

(output) 

(output) 

sc_out 

sc_out 

Out; 

Out; 

// 

// 

local 

local 

member 

member 

functions 

functions 

void 

void 

accumulate(); 

accumulate(); 

void 

void 

display(ostream& 


= 

= 

cout); 

cout); 

// 

// 

local 

local 

member 

member 

data 

data 

int 

int 

Acc_; 

Acc_; 

// 

// 

constructor 

constructor 

SC_CTOR(accumulator) 


{ 

{ 

SC_METHOD(accumulate); 


sensitive_pos 

sensitive_pos 

Modules 

t 

Module Ports 

• Pass data between module-boundary 

and internal module-processes 

• Direction 

t in : read 

t out : write 

t inout : read & write 

• Type 

t > , > , etc. 

t special : clock 

port direction 



{ 

{ 

// 

// 

ports 

ports 

(input) 

port type 

(input) 

sc_in 

sc_in 

In; 

In; 

sc_in 

sc_in 

Rst; 

Rst; 

sc_in_clk 

sc_in_clk 

Clk; 

Clk; 

... 

...// // 

ports 

ports 

(output) 

// (output) 

sc_out // 

input 

input 

ports 

ports 

sc_out 

Out; 

sc_in Out; 

sc_in 

In; 

In; 

sc_in // 

// 

local 

local 

member 

member 

functions 

sc_in 

Rst; 

Rst; functions 

sc_in_clk void 

void 

accumulate(); 

sc_in_clk accumulate(); 

Clk; 

Clk; 

void 

void 



= 

= 

cout); 

cout); 

// // 

output 

// 

local output 

ports 

local 

member ports 

member 

data 

sc_out data 

sc_out 

Out; 

int 

Acc_; Out; 

Acc_; 

// // 

// 

constructor 

// 

inout 

inout constructor 

ports; 

ports; 

sc_inout SC_CTOR(accumulator) 


{ 

sc_inout 

InOut; 

InOut; { 

... SC_METHOD(accumulate); 

... SC_METHOD(accumulate); 

sensitive_pos 

sensitive_pos 

Modules 

t 

Module Member functions 

o 

o 

Processes 

• functions registered with the SystemC kernel (see next) 

User defined functions 

• can be called within processes 

void 

void 

accumulator::accumulate() 

accumulator::accumulate() 

{ 

{ 

if 

if 

(Rst.read()) 

(Rst.read()) 

Acc_ 

Acc_ 

= 

= 

0; 

0; 

else 

else 

Acc_ 

Acc_ 

+= 

+= 

In.read(); 

In.read(); 

} 

} 

display(); 

display(); 

Out.write(Acc_); 

Out.write(Acc_); 

void 

void 

accumulator::display(ostream& 

accumulator::display(ostream& 

os) 

os) 

{ 

{ 

os 

os 

Modules 

t 

t 

Module Member data 

• to keep local state variable 

• not to be used for communication 

between processes 

Constructor 

• registers processes with 

the SystemC kernel 

• initializes whatever is needed 

(local member data) 

• to create and initialize an 

instance of a sub-module 

(connections, instance name) 

SC_MODULE(accumulator) SC_MODULE(accumulator) { 

{ 

// // ports ports (input) 

(input) 

sc_in sc_in In; 

In; 

sc_in sc_in Rst; 

Rst; 

sc_in_clk sc_in_clk Clk; 

Clk; 

// // ports ports (output) 

(output) 

sc_out sc_out Out; 

Out; 

// // local local member member functions 

functions 

void void accumulate(); 

accumulate(); 

void void display(ostream& display(ostream& = = cout); 

cout); 

// // local local member member data 

data 

int int Acc_; 

Acc_; 

// // constructor 

constructor 

SC_CTOR(accumulator) SC_CTOR(accumulator) { 

{ 



sensitive_pos sensitive_pos

Modules 

t 

Hierarchy of Modules 

o 

o 

In 

Th 

Module instances 

Signals 

• carry data between modules 

and between processes 

top 

accumulator 

A 

Intern 

comparator 

C 

submodules 

internal signal 

Out 

SC_MODULE(top) 

SC_MODULE(top) 

{ 

{ 

// 

// 

ports 

ports 

sc_in 

sc_in 

In; 

In; 

... 

... 

// 

// 

module 

module 

instances 

instances 

accumulator 

accumulator 

A; 

A; 

comparator 

comparator 

C; 

C; 

// 

// 

signals 

signals 

sc_signal 

sc_signal 

Intern; 

Intern; 

submodule 

name 

// 

// 

constructor 

constructor 

SC_CTOR(top): 

SC_CTOR(top): 

A(“A”), 

A(“A”), 

C(“C”) 

C(“C”) 

{ 

{ 

A.In(In); 

A.In(In); 

A.Out(Intern); 

A.Out(Intern); 

... 

... 

} 

} 

}; 

}; 

connections 


Part III - slide 12

Modules 

t Top level “sc“ 

sc_main()” 

SystemInput 

• instances of modules 

• connectivity at top-level 

• clock object 

clk 

In 

Out 

top 

A 

tb 

Gererator Analyzer 

W 

accumulator 

Intern 

R 

comparator 

C 

In 

SystemOutput 

Out 

sc_main() 

sc_main() 

{ 

{ 

sc_clock 

sc_clock 

clk(“clk”, 

clk(“clk”, 

20, 

20, 

0.5, 

0.5, 

2, 

2, 

true); 

true); 

testbench 

testbench 

TB(“TB”); 

TB(“TB”); 

TB.In(SystemOutput); 

TB.In(SystemOutput); 

... 

... 

top 

top 

Top(“Top”); 

Top(“Top”); 

Top.In(SystemInput); 

Top.In(SystemInput); 

... 

... 

sc_start(-1); 

sc_start(-1); 

} 

} 

clock 

Simulation 

start 

instances at 

top-level 

Th 


Part III - slide 13

Part III. 

t 

t 

t 

t 

Context 

Outline 











Summary 


Part III - slide 14

Processes 

t 

t 

t 

t 

t 

t 

Basic unit of execution 

Contained inside modules 

Functions with a specific type 

• method 

• thread 

• clocked thread 

• RPC 

SC_METHOD(name) 

SC_THREAD(name) 

SC_CTHREAD(name,clock) 

Not hierarchical 

communication done via signals, module ports 

SystemC takes care of scheduling the concurrent processes 

• sensitivity list 

• event on a signal in the list triggers the process 

è SystemC = Language (C++ Library) + Scheduler 


Part III - slide 15

Processes 

t 

Method 

• entire process executed once when a signal in its sensitivity list 

changes 

• can not be suspended 

• local variables loose their values between successive calls 

• most similar to a usual C++ function 

• fastest 

void 

void 

comparator::compare() 

comparator::compare() 

{ 

{ 

if 

if 

(Val.read() 

(Val.read() 

> 

> 

Th.read()) 

Th.read()) 

Result.write(true); 

Result.write(true); 

else 

else 

Result.write(false); 

Result.write(false); 

} 

} 

method process 

declaration 

.cc file 

sensitivity list 

SC_MODULE(comparator) 

SC_MODULE(comparator) 

{ 

{ 

// 

// 

ports 

ports 

sc_in 

sc_in 

Val; 

Val; 

sc_in 

sc_in 

Th; 

Th; 

sc_out 

sc_out 

Result; 

Result; 

// 

// 

processes 

processes 

void 

void 

compare(); 

compare(); 

// 

// 

constructor 

constructor 

SC_CTOR(comparator) 

SC_CTOR(comparator) 

{ 

{ 

SC_METHOD(compare); 

SC_METHOD(compare); 

sensitive 

sensitive 

Processes 

t 

Thread 

• infinite loop limited by event boundaries: execution suspended by a 

wait() statement(s) 

• (re-)activated when any of the signals in the sensitivity list changes 

• local variables are saved (similar to static variables in C++ 

functions) 

• slower than method with module data members to store the ‘state’ 

void 

void 

decision::fsm() 

decision::fsm() 

{ 

{ 

int 

int 

a, 

a, 

b; 

b; 

// 

// 

local 

local 

variables 

variables 

state_ 

state_ 

= 

= 

…; 

…; 

// 

// 

initial 

initial 

state 

state 

while(true) 

while(true) 

{ 

{ 

wait(); 

wait(); 

a 

a 

= 

= 

a_in.read(); 

a_in.read(); 

b 

b 

= 

= 

b_in.read(); 

b_in.read(); 

if 

if 

(…) 

(…) 

state_ 

state_ 

= 

= 

…; 

…; 

elseif 

elseif 

(…) 

(…) 

state_ 

state_ 

= 

= 

…; 

…; 

else 

else 

state_ 

state_ 

= 

= 

…; 

…; 

} 

} 

infinite loop 

thread process 

declaration 

sensitivity list 

SC_MODULE(decision) 


{ 

{ 

// 

// 

ports 

ports 

sc_in 

sc_in 

Sensor_in; 

Sensor_in; 

sc_in 

sc_in 

a_in; 

a_in; 

sc_in 

sc_in 

b_in; 

b_in; 

// 

// 

processes 

processes 

void 

void 

fsm(); 

fsm(); 

thread 

process 

name 

// 

// 

constructor 

constructor 

SC_CTOR(decision) 


{ 

{ 

SC_THREAD(fsm); 

SC_THREAD(fsm); 

sensitive 

sensitive 

Processes 

t 

Clocked thread 

• particular thread : 

infinite loop, 

sensitive only to one edge of one clock 

• suspended by 

t wait() or 

t wait(int 

int) ) or 

t wait_until() 

• only synchronous systems 

• slowest 



{ 

{ 

// 

// 

ports 

ports 

sc_in_clk 

sc_in_clk 

clk; 

clk; 

... 

... 

}; 

}; 

// 

// 

processes 

processes 

void 

void 

fsm(); 

fsm(); 

clocked thread 

process declaration 

// 

// 

constructor 

constructor 



{ 

{ 

SC_CTHREAD(fsm, 

SC_CTHREAD(fsm, 

clk.pos()); 

clk.pos()); 

} 

} 

... 

... 

thread 

process 

name 


Part III - slide 18

Processes 

t 

Remote procedure call (RPC) 

• abstract communication and 

execution semantics for functional level 

• master/slave ports and processes 

• RPC chain 

master 

process 

master 

port 

link 

process 1 process 2 

slave 

port 

slave 

process 

SC_MODULE(M1) 

SC_MODULE(M1) 

{ 

{ 

sc_outmaster 

sc_outmaster 

Out; 

Out; 

... 

... 

void 

void 

process1(); 

process1(); 

SC_CTOR(M1) 

SC_CTOR(M1) 

{ 

{ 

SC_METHOD(process1); 

SC_METHOD(process1); 

sensitive 

sensitive 

Processes 

t 


• Equivalent to function call but without function pointer 

• Structure is key for re-use (split behaviour of modules) 

• Concurrent RPC chains 

concurrent 

processes 

slave 

processes 

process A1 

process A2 

process B1 process B2 process B3 


Part III - slide 20

Processes 

t 


• Equivalent to function call but without function pointer 

• Structure is key for re-use (split behaviour of modules) 

• Concurrent RPC chains 

concurrent 

processes 

slave 

processes 

Producer() Write() ; Read() Consumer() 


Part III - slide 21

Part III. 

t 

t 

t 

t 

Context 

Outline 











Summary 


Part III - slide 22

Data types 

t 

t 

t 

C++ data types 

• int , double , etc… 

SystemC data types (slower, but … link to implementation) 

• scalar types 

sc_bit {0,1} 

- sc_logic {0,1,X,Z} 

• bit and logic vector types 

sc_bv 

bv 

- sc_lv 

lv 

• integer types 

sc_int 

- sc_uint 

: 64 or 32-bit 

sc_bigint 

- sc_biguint 

: > 64-bit 

• fixed point types 

sc_fixed 

User defined data types 

(faster) 

- sc_ufixed 

- sc_fix 

- sc_ufix 

e.g. Symbol64C = { 64 complex samples of sc_fixed } 


Part III - slide 23

Data types 

t 

Fixed point types 

Parameters 

sc_fixed ( wl , iwl , q_mode , o_mode [, n_bits] ) sig ; 

Example 

sc_fixed ( 3 , 2 , SC_TRN , SC_WRAP ) Cnt ; 

Cnt = 

CntF 

+1,5 = "01.1" 1,500 

-0,5 = "11.1" -0,500 

+0,5 = "00.1" 0,832 

+1,5 = "01.1" 1,500 

fixed point 

value Cnt 

01.1 

01.0 

00.1 

00.0 

11.1 

floating point 

value CntF 

Cnt = 

Cnt + Cnt 

-2,0 = "10.0" "01.1"+"00.1" 

11.0 

10.1 

10.0 


Part III - slide 24

Part III. 

t 

t 

t 

t 

Context 

Outline 











Summary 


Part III - slide 25

SystemC and C++ 

t 

SystemC is based on C++ 

• Standard Template Library (vector, map, strings, etc.) 

• streams 

• templates 

• constructors and destructors 

• inheritance and composition 

• function and operator overloading 

• exception handling 

• C++ data type: bool 

• casting operators 

• … 

è Easy to add features to SystemC 

Example 1 

Example 2 

Example 3 


Part III - slide 26


t 

Example 1: template modules 

// 

// 

template 

template 

module: 

module: 

definition 

definition 

of 

of 

a 

a 

mux 

mux 

with 

with 

any 

any 

// 

// 

desirable 

desirable 

type 

type 

of 

of 

signal 

signal 

template 

template 

 

class 

class 

mux: 

mux: 

sc_module 

sc_module 

{ 

{ 

// 

// 

inputs 

inputs 

sc_in 

sc_in 

Input1; 

Input1; 

sc_in 

sc_in 

Input2; 

Input2; 

sc_in 

sc_in 

Selector; 

Selector; 

// 

// 

outputs 

outputs 

sc_out 

sc_out 

Output; 

Output; 

void 

void 

process() 

process() 

{ 

{ 

if 

if 

(Selector.read()) 

(Selector.read()) 

Output 

Output 

= 

= 

Input2.read(); 


else 

else 

Output 

Output 

= 

= 



} 

} 

SC_CTOR(mux) 

SC_CTOR(mux) 

{ 

{ 

SC_METHOD(process); 


sensitive 

sensitive 


t 

Example 2: inheritance 

definition of 

base module 

definition of derived module 

SC_MODULE(ResetFF): 

SC_MODULE(ResetFF): 

public 

public 

FF 

FF 

{ 

{ 

// 

// 

ports 

ports 

sc_in 

sc_in 

Rst; 

Rst; 

// 

// 

process 

process 

void 

void 

process_reset() 

process_reset() 

{ 

{ 

if 

if 

(Rst.read()) 

(Rst.read()) 

Q.write(0); 

Q.write(0); 

} 

} 

// 

// 

constructor 

constructor 

SC_CTOR(ResetFF): 

SC_CTOR(ResetFF): 

FF(“FF”) 

FF(“FF”) 

{ 

{ 

SC_METHOD(process_reset); 

SC_METHOD(process_reset); 

sensitive 

sensitive 


t Example 3: destructor 

• useful in testbench 

t dump simulation results 

• useful for high-level models 

t dynamic memory allocation 

at constructor 

time 

at simulation 

time 

SC_MODULE(testbench) 

SC_MODULE(testbench) 

{ 

{ 

... 

... 

SC_CTOR(testbench) 

SC_CTOR(testbench) 

{ 

{ 

// 

// 

load 

load 

stimuli 

stimuli 

for 

for 

DUT 

DUT 

} 

} 

~testbench() 

~testbench() 

{ 

{ 

// 

// 

dump 

dump 

outputs 

outputs 

of 

of 

DUT 

DUT 

} 

} 

}; 

}; 

DUT 

at destructor 

time 

TB 


Part III - slide 29

Part III. 

t 

t 

t 

t 

Context 

Outline 











Summary 


Part III - slide 30

Matlab front-end 

t Facts : 

t 

• Matlab is used for algorithmic development 

• SystemC from the web has no GUI 

Use Matlab to create : 

• as main goal : 

Seamless design development 

from Matlab ( system:algorithmic level ) 

to SystemC ( system:architectural level ) 

• as side-effect effect : 

a mathematical & graphical analysis environment 

in SystemC 


Matlab 

UTF 

TF 

Algorithmic 

Design and 

Validation 

System 

Design and 

Validation 

è Use Matlab API-functions in SystemC testbenches 


Part III - slide 31


t 

from Matlab (system:algorithmic level) 

to SystemC (system:architectural level) 

SystemC model 

DUT 

matlab 

.mat 

.mat 

matlab 

TB 

matlab API 


Part III - slide 32


t 

Matlab used as mathematical & graphical analysis 

environment 

.mat 

DUT 

v1 

TB 

DUT 

v2 

.mat 

v1 

matlab 

TB 

.mat 

v2 


Part III - slide 33


t Example : 


Part III - slide 34

Part III. 

t 

t 

t 

t 

Context 

Outline 











Summary 


Part III - slide 35

Fixed and floating point 

t Features of fixed point representation : 

• numerical range 

• required precision 

• for operations : quantization and overflow behaviour 


Part III - slide 36


t Features of fixed point representation : 

• slope/bias scaling: 

fixed and floating point values are linked 

via a scaling factor and a bias 

Q 

fix. point 

value ~ V 

0.01 

0.10 

0.11 

slope S 

0.00 

1.10 

1.11 

fl. point 

value V 

1.01 

1.00 

B = 0 


Part III - slide 37

t Example : 


• sensor measuring water temperature 

• range is limited: 0 to 100 ºC 

• bias is 0 

• to be mapped onto 8 bits unsigned 

6 1 bit ⇔ 1 C leads to a waste of precision 

4 1 bit ⇔ 100/255 C is better 

fixed point value 

(bits) 

00000110 00000000 0°C 0°C 

00000101 

00000100 

00000011 

00000010 

00000001 

00000000 

slope = 100/255 [ C/bit] 

fl. point value 

(degrees) 

00000001 1°C 0.4°C 

00000010 2°C 0.8°C 

… 

6 

4 

01100100 100°C 39.2°C 

… 

11111111 imposs. 100°C 


Part III - slide 38


t 

SystemC enables fixed point or floating point models 

float 

DUT 

floating 

point 

gradual 

refinement 

.mat 

TB 

.mat 

float 

matlab 

DUT 

fixed 

point 

fixed 

TB 

.mat 

fixed 


Part III - slide 39


t Example : 



{ 

{ 

// 

// 

input 

input 

ports 

ports 

sc_in 

sc_in 

In; 

In; 

sc_in 

sc_in 

Rst; 

Rst; 

sc_in_clk 

sc_in_clk 

Clk; 

Clk; 

// 

// 

output 

output 

ports 

ports 

sc_out 

sc_out 

Out; 

Out; 

// 

// 

processes 

processes 

void 

void 

process(); 

process(); 

// 

// 

constructor 

constructor 



{ 

{ 



sensitive_pos 

sensitive_pos 


t 

t 

Our goal: have single model 

which can easily simulate both precisions 

Easy solution: pre-processor 

processor 

DUT 

floating 

point 

.mat 

TB 

.mat 

float 

matlab 

selection 

by means of 

pre-processor 

DUT 

fixed 

point 

TB 

.mat 

fixed 


Part III - slide 41


t 

Easy solution: pre-processor 

processor 

either floating point or fixed point; 

selection by means of preprocessor 

t 

SC_MODULE(SR_shift_reg) 


{ 

{ 

// 

// 

inputs 

inputs 

sc_in 

Sample_In; 

Sample_In; 

}; 

}; 

// 

// 

outputs 

outputs 

sc_out 

SamplesForSR_1_Out; 


sc_out 



... 

... 

But … 

and but … 

and but ... 

precision dependent 

operations 

#if 

#if 

FINITE 

FINITE 

cout 

cout 


t 

AME solution: new data type 

• carrying BOTH floating and fixed point value, 

and the associated slope 

• conditions evaluated using the fixed or the floating point value, 

depending on a precision mode flag 

DUT 

fl. point 

TB 

DUT 

fx. point 

.mat 

DUT 

floating & 

fixed point 

TB 

.mat 

fl&fx 

matlab 

TB 


Part III - slide 43


t 

Definition 

fx_double 

floating point value 

scale 

fixed point value 

fixed point parameters 

precision mode 

double 

double 

bits 

word length, quantization mode, overflow mode 

flag: floating or fixed point mode 

t 

Example of arithmetic operation 

25.36 [°C] 

100/255 [°C/bit] 

b#01000000 (⇔ 25.1 [°C]) 

 

Floating mode 

45 [°C] 

100/255 [°C/bit] 

b#01110010 (⇔ 44.7 [°C]) 

 

Floating mode 

+ = 

70.36 [°C] 

100/255 [°C/bit] 

b#10110010 (⇔ 69.8 [°C]) 

 

Floating mode 

note: 70.36 [°C] / (100/255 [°C/bit] ) = b#10110011 

propagation 

of rounding 

errors 


Part III - slide 44


t 

Example of relational operation 

25.36 [°C] 

100/255 [°C/bit] 

b#01000000 (⇔ 25.1 [°C]) 

 

Floating point mode 

> 

25.2 [°C] 

100/255 [°C/bit] 

b#01000000 (⇔ 25.1 [°C]) 

 

Floating point mode 

Yes 

25.36 [°C] 

100/255 [°C/bit] 

b#01000000 (⇔ 25.1 [°C]) 

 

Fixed point mode 

> 

25.2 [°C] 

100/255 [°C/bit] 

b#01000000 (⇔ 25.1 [°C]) 

 

Fixed point mode 

No 


Part III - slide 45


t Example : 

both floating point and fixed point 



{ 

{ 

// 

// 

inputs 

inputs 

sc_in 

Sample_In; 

Sample_In; 

// 

// 

outputs 

outputs 

sc_out 



sc_out 



… 

… 

}; 

}; 

precision independent 

operations 

cout 

cout 


t 

Pros of AME’s solution : 

• single executable model for both precisions 

• dynamic and automatically computed slopes 

(e.g. multiplication : slopes are multiplied ) 

• strong type checking 

(e.g. addition : forbidden to have a scaling factor mismatch) 

• single data type → single operations for fixed and floating point 

• no discrepancy in code while using debugger 

(since pre-processor processor is not used) 

• clean module interfaces, all based on the AME proprietary type 

• single function in the testbench dumping any received signal 


Part III - slide 47

Summary 

t 

t 


• has necessary features to describe Systems (Hw( 

Hw, Fw, Sw) 

• procedural language with path to implementation 

• different levels of abstraction 

• together with the language also reference simulator 

• C++ based and therefore easily extendable 






Part III - slide 48

Part IV. 

AME’s System Design 

Methodology in Practice 

30.01.2002 SystemC Tutorial © 2002 - Alcatel Microelectronics Part IV - slide 1

Outline 

Part IV. AME’s System Design Methodology in Practice 

t 

Simplified section tutorial example 

• The complex multiplier example 

t 

SystemC executable spec: modelling and simulation 

t 

SystemC co-simulation 

t 

Summary 


Tutorial Example 

The Complex MPY Section 

Complex Multiplier 

TimeD 

LCtrl 

DPRam 

F 

I 

FF 

OI 

F 

O 

Parameter Passing through Pointers 

Master/Slave 

CMPY 

LCtrl 

DPRam 

(Invisible at the 

block boundaries) 

Link 

F 

I 

F 

O 

Coeff 

Coeff 

FFT 

LCtrl 

DPRam 

Processor 

UpdateConfig 

F 

I 

F 

O 

Result 

DataPath 

LCtrl 

FreqD1 

LCtrl 

DPRam 

Master/Slave 

Link 

ConfigUpdated 


Processor 

F 

I 

F 

O 

Operational FW & TestBench 

Through Pointers 

F 

I 

F 

O 

FreqD2 

LCtrl 

DPRam 

HW 

FW 



The Complex MPY Section 

F 

I 

F 

O 


Master/Slave 



Link 

UpdateConfig 


Coeff 

Coeff 

Result 

DataPath 

LCtrl 

Processor 


SC_MODULE(CMPY_LCtrl) 


{ 

{ 

// 

// 

... 

... 

SC_MODULE(CMPY_LCtrl) } 

SC_MODULE(CMPY_LCtrl) } 

{ 

{ 

// 

Master/Slave // 

ports 

Fports 

SC_MODULE(CMPY_DPath) sc_inmaster SC_MODULE(CMPY_DPath) 

SC_MODULE(CMPY_DPath) 

{ 

sc_inmaster 

UpdateConfig; 


{ 

Link I 

{ UpdateConfig; { 

// sc_outmaster 

sc_outmaster 

// 

// 

... 

... 

ConfigUpdated; 

// 

ports 

ports ConfigUpdated; 

sc_inmaster sc_outmaster } 

sc_outmaster } F Update; 

sc_inmaster Update; D_In; 

D_In; 

sc_outmaster 

sc_outmaster 

D_Out; 

O D_Out; 

sc_inslave sc_inmaster // 

// 

FIFO 

FIFO 

type 

type 

is 

is 

Symbol64C. 

sc_inmaster Symbol64C. 

notEmpty, 

notEmpty, 

notFull; 

sc_inslave 

Enable; 

Enable; notFull; 

sc_inslave sc_outmaster // 

// 

Multiplication 

Multiplication 

is 

is 

performed 

performed 

for 

for 

64 

sc_outmaster 

Enable; 

sc_inslave Enable; Update; 64 

// 

// 

complex 

complex 

samples 

samples 

in 

Update; 

... ... 

in 

just 

just 

one 

one 

Enable. 

... ... 

Enable. 

// SC_MODULE(CMPY) 

SC_MODULE(CMPY) 

{ 

// 

local 

local 

member 

member 

data 

data{ 

Symbol64C void 

void 

// 

// 

control(); ports 

control(); ports 

// 

// 

process 

Symbol64C 

coef_; 

coef_; process 

// sc_inmaster 

sc_inmaster 

 

 

Full_In; 

// 

configuration 

configuration 

access 

access 

via 

via Full_In; pointer 

pointer 

config_CMPY& SC_CTOR(CMPY_LCtrl) sc_inmaster 

sc_inmaster 

 

 

Empty_In; 

SC_CTOR(CMPY_LCtrl) 

{ 

config_CMPY& 

configClass_; 

configClass_; { Empty_In; 

SC_THREAD(control); 


... sc_inmaster sensitive_pos 

sc_inmaster 

 

 

Mult_In; 

sensitive_pos 

Outline 


t 


t 

t 

t 


• Top Level Integration 

• Master/Slave Library 

• Documented methodology 

• Testbench Strategy 

• Different levels of abstraction 


Summary 


SystemC Executable Spec 

Top level integration 

t 

The Complex-MPY as one of the sections at top level 

F I F 

O 

TimeD 

TimeD 

LCtrl 

DPRAM 

F 

I 

F 

O 

F 

I 

F 

O 

CMPY 


LCtrl 

DPRAM 

F 

I 

F 

O 

Master/Slave 



Link 

UpdateConfig 


FFT 

Coeff 

Coeff 

LCtrl 

DPRAM 

Processor 

F 

I 

F 

O 

Result 

DataPath 

LCtrl 

Processor 

Master/Slave 

Link 

FreqD1 

LCtrl 

DPRAM 

ConfigUpdated 



F 

I 

F 

O 

FreqD2 

LCtrl 

FFT 

DPRAM 

HW 

FW 

F I F 

O 

Complex Multiplier Example 


Integration Methodology 

HW/FW interface-1 

t 

t 

t 

The communication is 

always with M/S ports 

The communication is 

based on a 

configuration which is 

a C++ class 

FW accesses HW 

using C++ pointers. 

Configuration access 

is based on C++ 

pointers. 

F 

I 

F 

O 


Master/Slave 



Link 

UpdateConfig 


Coeff 

Coeff 

Result 

DataPath 

LCtrl 

Processor 

Master/Slave 

Link 

ConfigUpdated 


F 

I 

F 

O 



HW/FW interface-2 

t 

t 

Soft reset is a 

command sent to HW 

by FW and has the 

highest priority 

among other 

commands. 

“watching” 

mechanism can also 

be used for IRQ 

modelling, , FW to FW 

and/or HW to FW. 

• Check first if your 

cosim tool supports 

this feature! 

F 

I 

F 

O 


Master/Slave 



Link 

UpdateConfig 


Coeff 

Coeff 

Result 

DataPath 

LCtrl 

Processor 

Master/Slave 

Link 

ConfigUpdated 


F 

I 

F 

O 



M/S Ports-1 

t 

HW-FW interface at the top-level 

• Always M/S communication is used 

Advantage! 

t 

COMMUNICATION IS SEPARATED FROM BEHAVIOR 

Advantage of using different abstraction levels 

• All abstraction levels communicate using M/S communication 

TF 

CA 

TF 

CA 

TF 



M/S Ports-2 

t 

t 

Well suited to FW-FW, 

FW, 

HW-FW and HW-HW 

interfaces 

Facilitates the communication 

between modules. Hides 

unnecessary implementation 

details. 

• Allows quick model 

development 

• Trade-off analysis for HW-FW 

partitioning 

F 

I 

F 

O 


Master/Slave 



Link 

UpdateConfig 


Coeff 

Coeff 

Result 

DataPath 

LCtrl 

Processor 

Master/Slave 

Link 

ConfigUpdated 


F 

I 

F 

O 

• Resource allocation decisions 



M/S Ports-3 

t 

t 

t 

Ability to refine functional 

communication at the later 

stages of the design to BCA 

Benefits of separation of 

communication from behaviour 

• Embedding of IP blocks 

• Refining communication 

Only “sc_link_mp” is supported 

by our CoSim tool 

F 

I 

F 

O 


Master/Slave 



Link 

UpdateConfig 


Coeff 

Coeff 

Result 

DataPath 

LCtrl 

Processor 

Master/Slave 

Link 

ConfigUpdated 


F 

I 

F 

O 



M/S Library 


F 

I 

F 

O 

Link 

Coeff 

Result 

Link 

F 

I 

F 

O 

Master/Slave 

Master/Slave 



{ 

{ 

// 

// 

... 

... 

} 

} 



{ 

{ 

// 

// 

... 

... 

} 

} 



{ 

{ 

// 

// 

ports 

ports 

sc_inmaster 

sc_inmaster 

 

 

Full_In; 

Full_In; 

sc_inmaster 

sc_inmaster 

 

 

Empty_In; 

Empty_In; 

sc_inmaster 

sc_inmaster 

 

 

Mult_In; 

Mult_In; 

sc_outmaster 

sc_outmaster 

Mult_Out; 

Mult_Out; 




UpdateConfig 

Coeff 

DataPath 

LCtrl 

Processor 

ConfigUpdated 


sc_inmaster 

sc_inmaster 

 

 

UpdateConfig_In; 

UpdateConfig_In; 

sc_outmaster 

sc_outmaster 

ConfigUpdated_Out; 

ConfigUpdated_Out; 

// 

// 

... 

... 

} 

} 



Documented Methodology 

t 

t 

t 

t 

t 

t 

SystemC Coding Style 

• A design guidelines and rules document to be used by the SystemC teams. 

Naming conventions, directory structure, code layout, etc. 

Block Diagram Conventions 

• Standardizes the drawing conventions. 

SystemC Coding Generics 

• Includes coding generics to facilitate the top-level integration at a later 

phase. 

Test Plan and Test Status 

README files 

Comments in the code 



What would happen... 

t 

...if we did not have SystemC Coding Style? 

• Everyone would use a different naming convention. 

• There will be no common directory structure when releasing the 

models. 

• When the codes are passed to the implementation team it would be 

a puzzle for them to figure out the followed conventions. 

• Problems would arise when sharing codes. 

t 

...if we did not have Block Diagram Conventions? 

• Everyone would use a different drawing convention. 

• This would create misunderstandings between the modelling teams 

and later for the implementation team. 

• As a result drawing a block diagram would lose its meaning as its 

aim is to facilitate of understanding the model later by someone else. 



Block Diagram Conventions 

Signal connection 

Processes in 

SC_CTOR like 

SC_CTHREAD, 

SC_THREAD, 

SC_METHOD. (Don't 

place process bubles 

for SC_SLAVE and 

other methods!) 

Instance Name 

Module Name 

master port name 

process_name() 

slave port name 

LAT 

THRxClk 

Latency of the 

process 

Throughput of the 

process 

Clock Name 

ConfigSR 

ShiftReg 

PortName_In 

PortName_Out 

Port Name 

Internal named signal 

Class_In 

Internal signal 

Classes with thick 

lines 

Write the external 

port name inside this. 

Hierarchical port 

connection. This port 

connects to upper 

level module. 



Complex Multiplier Block Diagram 

RxS3 

rx_s3 

mult 

multiplier 

Mult_In 

Mult_Out 

FIFO2 

fifo 

Enable_In 

SoftRst_In 

Update_In 

FIFO3 

fifo 

Data_In 

Data_Out 

Data_In 

Data_Out 

Full_Out 

Empty_Out 

UpdateConfig_In 

lctr 

lctrl_chproc 

Empty_In 

Enable_Out 

SoftRst_Out 

Update_Out 

Full_In 

Full_Out 

Empty_Out 



generate_enable 

1xClk20 

ConfigUpdated_Out 

RxS3CR1 

control_reg 

(C) 

C 

C 

RxS3CR2 

control_reg 

(C) 

testbench 

testbench 

RxFIFO2UpdateConfig_Out 

RxS3UpdateConfig_Out 

RxS3ConfigUpdated_In 

RxFIFO3UpdateConfig_Out 

Empty_In 

IRQ_GEN 

irq_gen 

Full_In 

Data_Out 

test_sequence 

1xClk200 

Data_In 

IRQ_In 

GPIO_In 

IRQ_Out 

GPIO_Out 

irq_gen() 

1xClk200 




t 

...if we did not have SystemC Coding Generics? 

• Top level integration would be a nightmare! 

• A lot of things like common definitions, duplicate port, signal, 

module names had to be changed in the codes. 

• The changes would be done by the top level integrators, which is 

error prone, as they don’t know the details of the codes. 

• Or the section coders would make the changes to their codes, which 

would consume the project time. 

• There won’t be a reference document for the section coders, to 

consider top-level integration issues. 




t 

...if we did not have Test Plan documents? 

• Supervisors would not easily understand how the model will be 

tested. They would not easily add or remove tests. 

• There would not be a track list during the testing of a model. This T 

would probably result in some of the tests to be forgotten. 

• There would not be a reference to see the results of the tests. 

• If later someone wanted to rerun the tests, he/she would go into the 

details of the testbench to learn how to run it. Time Consuming! 


Outline 


t 

t 

t 

t 







t TF#1 - TF#2 - CA#1 - 



Summary 

CA#2 


SystemC Executable Spec. 

TF#1 Model of ComplexMPY 

F 

I 

F 

O 


Master/Slave 



Link 

UpdateConfig 


Coeff 

Coeff 

Result 

DataPath 

LCtrl 

Processor 




{ 

{ 

// 

// 

ports 

ports 

SC_MODULE(CMPY_DPath) sc_inmaster 

Master/Slave sc_inmaster 

UpdateConfig; 


{ 

F { UpdateConfig; 


sc_outmaster 


// 

ports 

ports 

Link I 


sc_inmaster sc_outmaster 

sc_outmaster 

Update; 

sc_inmaster Update; D_In; 

D_In; 

sc_outmaster 

sc_outmaster F D_Out; 

D_Out; 

sc_inslave sc_inmaster 

sc_inmaster 

notEmpty, 

O notEmpty, 

notFull; 

sc_inslave 

Enable; 

Enable; notFull; 

sc_inslave sc_outmaster 

sc_outmaster 

Enable; 

sc_inslave Enable; Update; 

Update; 

... ... 

... ... 

// 

// 

local 

local 

member 

member Enable data 

data multiply! 

Symbol64C void 

void 

control(); 

control(); 

// 

// 

process 

Symbol64C 

coef_; 

coef_; process 

// 

// 

configuration 

configuration 

access 

access 

via 

via 

pointer 

pointer 

config_CMPY& SC_CTOR(CMPY_LCtrl) 


{ 

config_CMPY& 

configClass_; 

configClass_; { 


SC_THREAD(control); CLK 

... sensitive_pos 

sensitive_pos 

t 



Multiply (64 complex samples) when Enable is triggered 

• Using “Slow” Functional clock CLK 

• Process execution time ==> 1 x wait() for a functional CLK tick 

void 

void 

CMPY_LCtrl::control() 


{ 

{ 

} 

} 

while(true) 

while(true) 

{ 

{ 

if 

if 

(UpdateConfig.read()) 


{ 

{ 

Update.write(TRUE); 


ConfigUpdated.write(TRUE); 


} 

} 

if 

if 

(notEmpty.read() 


&& 

&& 

notFull.read()) 


{ 

{ 

Enable.write(TRUE); 


} 

} 

wait(); 

wait(); 

// 

// 

Functional 

Functional 

clock 

clock 

CLK 

CLK 

void 

void 

CMPY_DPath::updCoef() 


{ 

{ 

} 

} 

if 

if 

(Update.read()) 


{ 

{ 

coef_ 

coef_ 

= 

= 

configClass_.Coef(); 


} 

} 

0 

Result ready here! 

“Computed in ‘NoTime’ “ 

1 2 63 64 

0 1 CLK 



{ 

{ 

// 

// 

ports 

ports 

sc_inmaster 

sc_inmaster 

UpdateConfig; 

UpdateConfig; 

sc_outmaster 

sc_outmaster 



sc_outmaster 

sc_outmaster 

Update; 

Update; 

sc_inmaster 

sc_inmaster 

notEmpty, 

notEmpty, 

notFull; 

notFull; 

sc_outmaster 

sc_outmaster 

Enable; 

Enable; 

... 

... 

void 

void 

control(); 

control(); 

// 

// 

process 

process 



{ 

{ 



sensitive_pos 

sensitive_pos 

t 




• Using “Slow” Functional clock CLK 

// 

• Process execution time ==> 1 x wait() for a functional // 

ports 

ports CLK tick 



{ 

{ 

sc_inmaster 

sc_inmaster 

D_In; 

D_In; 

sc_outmaster 

SC_MODULE(CMPY_LCtrl) sc_outmaster 

D_Out; 


{ D_Out; 

sc_inslave { 

// 

void 

void 



{ 

// 

ports sc_inslave 

Enable; 

Enable; 

portssc_inslave 

{ 

sc_inmaster sc_inslave 

Update; 

sc_inmaster 

UpdateConfig; Update; 

... UpdateConfig; 

void sc_outmaster 

while(true) 

while(true) 

{ 

sc_outmaster 


void 

CMPY_Dpath::multiply() 

CMPY_Dpath::multiply() 

{ 

... 

{ 

// ConfigUpdated; 

Symbol64C { 

sc_outmaster 

sc_outmaster 

Update; 

Symbol64C 

in_ 

in_ 

, 

, 

tmp_ 

tmp_ 

; 

// 

local 

local 

member 

member 

data 

data 

; 

Symbol64C 

Symbol64C 

coef_; 

coef_; Update; 

if 

if 



{ 

// 

in_ { 

sc_inmaster 


sc_inmaster 

notEmpty, 

notEmpty, 

notFull; 

in_ 

= 

= 

D_In.read(); 

// 

configuration 

configuration 

access 

access 

via 

via 

ptr 

ptr 

D_In.read(); 

config_CMPY& notFull; 

for(i=0 Update.write(TRUE); 

sc_outmaster 

} 

sc_outmaster 

Enable; 

for(i=0 

; 

; 

i

t 




• Using “Fast” Functional clock CLK64 

• Process execution time ==> 1 x wait(64) with functional CLK64 ticks 



{ 

{ 

void 

void 



{ 

// 

{ 

// 

ports 

ports 

sc_inmaster 

sc_inmaster 

UpdateConfig; 

UpdateConfig; 

while(true) 

while(true) 

{ 

sc_outmaster 

{ 

sc_outmaster 



sc_outmaster 

sc_outmaster 

Update; 

Update; 

if 

if 



{ 

{ 


sc_inmaster 


sc_inmaster 

notEmpty, 

notEmpty, 

notFull; 

notFull; 

ConfigUpdated.write(TRUE); sc_outmaster 

ConfigUpdated.write(TRUE); sc_outmaster 

Enable; 

Enable; 

} 

... 

} 

... 

if 

if 



&& 

&& 



{ 

{ 


void 


void 

control(); 

control(); 

// 

// 

process 

process 

} 

} 

} 


} 


{ 

{ 



void 

void 



{ 

sensitive_pos 

{ 

sensitive_pos 

t 








{ 

{ 

void 

void 



{ 

{ 

SC_MODULE(CMPY_DPath) // 

// 

ports 

SC_MODULE(CMPY_DPath) ports { 

sc_inmaster 

sc_inmaster 

UpdateConfig; { 

void UpdateConfig; 

void 

CMPY_Dpath::multiply_1() 

while(true) CMPY_Dpath::multiply_1() 

{ 

// 

while(true) 

{ { 

sc_outmaster // 

ports 

ports 

{ 

sc_outmaster 


Symbol64C ConfigUpdated; 

Symbol64C 

in_ 

in_ 

, 

, 

tmp_ 

tmp_ 

; 

sc_inmaster 

; 

sc_outmaster sc_inmaster 

D_In; 

sc_outmaster 

Update; D_In; 

sc_outmaster 

sc_outmaster Update; D_Out; 

D_Out; 

in_ if 

if 



{ 

in_ 

= 

= 

D_In.read(); { 

sc_inslave 

D_In.read(); 


sc_inmaster 

sc_inslave 

Enable; 


sc_inmaster 

notEmpty, 

Enable; 

notEmpty, 

notFull; 

for(i=0 notFull; 

for(i=0 

; 

} 

; 

i

t 






void 

void 



{ 

{ SC_MODULE(CMPY_LCtrl) 

Symbol64C 

Symbol64C 

in_ 

in_ 

, 

, 

tmp_ 

tmp_ 

; 


{ 

{ 

; 

// 

// 

ports 

ports 

sc_inmaster 

in_ 

in_ 

= 

= 

D_In.read(); 

sc_inmaster 

UpdateConfig; 

UpdateConfig; 

D_In.read(); 

sc_outmaster 

for(i=0 

for(i=0 

; 

; 

i


CA#1 Model of ComplexMPY 

F 

I 

F 

O 


Master/Slave 



Link 

UpdateConfig 


Coeff 

Coeff 

Result 

DataPath 

LCtrl 

Processor 




{ 

{ 


// 

// 

... 


... { 

} { 

// } 

// 

ports 

SC_MODULE(CMPY_DPath) ports 

Master/Slave 


{ 

sc_inmaster { 

SC_MODULE(CMPY_DPath) sc_inmaster F 

UpdateConfig; 

// UpdateConfig; 

// 

ports 


{ 

sc_outmaster ports { 

Link 

sc_outmaster 

// I 


sc_inmaster // ... ConfigUpdated; 

sc_inmaster 

D_In; 

sc_outmaster ... 

} sc_outmaster 

Update; D_In; 

sc_outmaster Update; 

sc_outmaster 

D_Out; 

} F D_Out; 

sc_inslave 

sc_inslave 

Enable; 

sc_inmaster 

// sc_inmaster O notEmpty, Enable; 

// 

FIFO 

FIFO 

type 

type 

is 

is 

Sample notEmpty, 

notFull; 

sc_inslave 

Sample 

in 

in 

this notFull; 

sc_inslave 

Update; 

sc_outmaster this 

case. 

case. 


Enable; Update; 

... 

// 

And 

And 

one 

one 

complex 

complex 

multiplication Enable; 

... ... multiplication 

is 

is 

// // ... 

// 

local 

// local 

performed member 

performed member data 

data 

each 

each 

clock 

clock 

cycle. 

cycle. 

SampleC 

SampleC SC_MODULE(CMPY) coef_; 

void SC_MODULE(CMPY) 

{ 

void 

control(); coef_; { 

// 

// 

ports control(); 

// 

// 

process 

// process 

// 

configuration 

configuration 

access 

ports access 

via 

via 

pointer 

pointer 

config_CMPY& 

config_CMPY& SC_CTOR(CMPY_LCtrl) 

sc_inmaster configClass_; 

sc_inmaster configClass_; 

 

Full_In; 


{ Full_In; 

sc_inmaster 

sc_inmaster 

{ 

SC_THREAD(control); 

Empty_In; 


Empty_In; 

... 

... sensitive_pos 

sc_inmaster sensitive_pos 

t 

void 

void 

CMPY_Dpath::multiply_CA1() 


{ 

{ 

void 

void 



{ SampleC 

{ SampleC 

in_ 

in_ 

, 

, 

tmp_ 

tmp_ 

; 

; 

while(true) 

while(true) 

{ 

{ 

if 

if 

(UpdateConfig.read()) RealCoef_ 

(UpdateConfig.read()) RealCoef_ { = 

{ = 

coef_.sample[i].data.real(); 


Update.write(TRUE); ImaginCoef_ 


= 

= 

coef_.sample[i].data.imag(); 




} 

RealIn_ 

} 

RealIn_ 

= 

= 

in_.sample[i].data.real(); 


if 

if 



&& 

&& 

notFull.read()) ImaginIn_ 


= 

= 

in_.sample[i].data.imag(); 


{ 

{ 



} 

// 

} 

// 

multiplying 

multiplying 

data 

data 

samples 

samples 

by 

by 

coeff 

coeff 

samples 

samples 

wait(); 

wait(); 

// 

// 

Fast 

Fast 

clock 

clock 

CLK64 RealResult_ 


= 

= 

(RealIn_ 

(RealIn_ 

* 

* 

RealCoef_) 

RealCoef_) 

- 

- 

(ImaginIn_* 

(ImaginIn_* 

ImaginCoef_); 

ImaginCoef_); 

} 

ImaginResult_ 

} 

ImaginResult_ 

= 

= 

(RealIn_* 

(RealIn_* 

ImaginCoef_) 

ImaginCoef_) 

+(ImaginIn_* 

+(ImaginIn_* 

RealCoef_); 

RealCoef_); 

// 

// 

Putting 

Putting 

result 

result 

samples 

samples 

in 

in 

a 

a 

temporary 

temporary 

symbol 

symbol 

void 

void 



{ tmp_.sample[i] 


= 

= 

complex 

complex 

(RealResult_, 

(RealResult_, 

ImaginResult_); 


} 

} 



One complex multiplication per clock tick 

• FIFO on sample basis 

• Using “Fast” clock CLK-64 

in_ 

in_ 

= 

= 

D_In.read(); 

D_In.read(); 

if 

if 



{ // 

{ // 

Writing 

Writing 

the 

the 

result 

result 

to 

to 

the 

the 

output 

output 

port 

port 

coef_ 

coef_ 

= 

= 

configClass_.Coef(); D_Out.write( 

configClass_.Coef(); D_Out.write( 

tmp_ 

tmp_ 

); 

); 

} 

} 

} 

} .cc file 

.cc file 


t 



One complex multiplication per clock tick 

• FIFO on sample basis 

• Using “Fast” clock CLK-64 

void 

void 



{ 

{ 

void 

void 



{ SampleC 

{ SampleC 

in_ 

in_ 

, 

, 

tmp_ 

tmp_ 

; 

; 

while(true) 

while(true) 

{ 

{ 

if 

if 

(UpdateConfig.read()) RealCoef_ 

(UpdateConfig.read()) RealCoef_ { = 

{ = 





= 

= 





} 

RealIn_ 

} 

RealIn_ 

= 

= 



if 

if 



&& 

&& 



= 

= 



{ 

{ 



} 

// 

} 

// 

multiplying 

multiplying 

data 

data 

samples 

samples 

by 

by 

coeff 

coeff 

samples 

samples 

wait(); 

wait(); 

// 

// 

Fast 

Fast 

clock 

clock 



= 

= 

(RealIn_ 

(RealIn_ 

* 

* 

RealCoef_) 

RealCoef_) 

- 

- 

(ImaginIn_* 

(ImaginIn_* 

ImaginCoef_); 

ImaginCoef_); 

} 

ImaginResult_ 

} 

ImaginResult_ 

= 

= 

(RealIn_* 

(RealIn_* 

ImaginCoef_) 

ImaginCoef_) 

+(ImaginIn_* 

+(ImaginIn_* 

RealCoef_); 

RealCoef_); 

// 

// 

Putting 

Putting 

result 

result 

samples 

samples 

in 

in 

a 

a 

temporary 

temporary 

symbol 

symbol 

void 

void 





= 

= 

complex 

complex 

(RealResult_, 

(RealResult_, 



} 

} 

} 

} 

in_ 

in_ 

= 

= 

D_In.read(); 

D_In.read(); 

if 

if 



{ // 

{ // 

Writing 

Writing 

the 

the 

result 

result 

to 

to 

the 

the 

output 

output 

port 

port 

coef_ 

coef_ 

= 

= 


Result 


and Output D_Out.write( 

D_Out.write( 

ready 

tmp_ 

tmp_ 

); 

); 

at each sample... 

} 

} .cc file 

.cc file 

1 2 63 64 

CLK64 

time 


t 

a 

c 

CLK-64 

* 

b 

d 



Functional specification to HW-designers 

• one complex multiplication per fast CLK-64 cycle (THR=1, LAT=1) 

• (a+jb) * (c+jd) = (a*c – b*d) + j(c*b + a*d) 

* 

c 

b 

- 

* 

a 

d 

Result of 

Real part 

* + 

Latency! 

+ 

Throughput! 

+ 

Reference Clk 

= 

Input for HW 

designers 

Result of 

imaginary 

part 


t 

Possible implementation: 

a 

c 

CLK-HW 

* 

b 

d 



• 1 Multiplier, 1 Adder/Subtracter ; 

• use CLK-HW , 4 times faster than CLK64 

* 

c 

b 

- 

* 

a 

d 

Result of 

Real part 

* + 

Latency! 

+ 

Throughput! 

+ 

Reference Clk 

= 

Input for HW 

designers 

Result of 

imaginary 

part 


t 



One multiplication per clock tick 

• Using “Very Fast” clock CLK-HW 

• 4 CLK-HW cycles in order to perform a complex multiplication 



{ 

{ 

// 

// 

ports 

ports 

sc_inmaster 

sc_inmaster 

UpdateConfig; 

UpdateConfig; 

sc_outmaster 

sc_outmaster 



sc_outmaster 

sc_outmaster 

Update; 

Update; 

sc_inmaster 

sc_inmaster 

notEmpty, 

notEmpty, 

notFull; 

notFull; 

sc_outmaster 

sc_outmaster 

Enable; 

Enable; 

... 

... 

void 

void 

control(); 

control(); 

// 

// 

process 

process 



{ 

{ 



sensitive_pos 

sensitive_pos 

t 



One multiplication per clock tick 

• Using “Very Fast” void 

void clock CMPY_Dpath::multiply_CA2() 

CMPY_Dpath::multiply_CA2() CLK-HW 

{ 

{ 

SampleC 

SampleC 

in_ 

in_ 

, 

, 

tmp_ 

tmp_ 

; 

; 

• 4 CLK-HW cycles in order to perform a complex multiplication 

in_ 

in_ 

= 

= 

D_In.read(); 

D_In.read(); 

void 

void 



{ 

{ 

RealCoef_ 

RealCoef_ 

= 

= 



ImaginCoef_ 

ImaginCoef_ 

= 

= 



while(true) 

while(true) 

{ 

{ 

RealIn_ 

RealIn_ 

= 

= 



if 

if 



ImaginIn_ 

ImaginIn_ 

{ 

{ 

= 

= 







// 

// 

multiplying 

multiplying 

data 

data 

samples 

samples 

by 

by 

coeff 

coeff 

samples 

samples 

} 

} 

RealResult1_ 

RealResult1_ 

= 

= 

(RealIn_ 

(RealIn_ 

* 

* 

RealCoef_) 

RealCoef_) 

; 

; 

if 

if 



&& 

&& 

notFull.read()) wait(); 

notFull.read()) wait(); 

// 

// 

Hardware 

Hardware 

{ 

{ 

clock 

clock 

CLK-HW 

CLK-HW 



RealResult_ 

RealResult_ 

= 

= 

(RealResult1_ 

(RealResult1_ 

- 

- 

(ImaginIn_* 

(ImaginIn_* 

ImaginCoef_); 

ImaginCoef_); 

} 

} 

wait(); 

wait(); 

// 

// 

Hardware 

Hardware 

clock 

clock 

CLK-HW 

CLK-HW 

} 

ImaginResult1_ 

} 

ImaginResult1_ 

= 

= 

(RealIn_* 

(RealIn_* 

ImaginCoef_) 

ImaginCoef_) 

; 

; 

wait(); 

wait(); 

// 

// 

Hardware 

Hardware 

clock 

clock 

CLK-HW 

CLK-HW 

void 

void 



{ 

{ 

ImaginResult_ 

ImaginResult_ 

= 

= 

(ImaginResult1_ 

(ImaginResult1_ 

+(ImaginIn_* 

+(ImaginIn_* 

RealCoef_); 

RealCoef_); 

// 

// 

Putting 

Putting 

result 

result 

samples 

samples 

in 

in 

a 

a 

temporary 

temporary 

symbol 

symbol 

if 

if 



{ 

{ 

tmp_.sample[i] 

tmp_.sample[i] 

= 

= 

complex 

complex 

(RealResult_, 

(RealResult_, 



coef_ 

coef_ 

= 

= 



} 

// } } 

// 

Writing 

Writing 

the 

the 

result 

result 

to 

to 

the 

the 

output 

output 

port 

} 

.cc file 

port 

D_Out.write( 

D_Out.write( 

tmp_ 

tmp_ 

); 

); 

wait(); 

wait(); 

// 

// 

Hardware 

Hardware 

clock 

clock 

CLK-HW 

CLK-HW 

= 

= 

4 

4 

x 

x 

faster 

faster 

than 

than 

CLK64 

CLK64 

} 

} 

1 2 63 64 

CLK64 

time 

.cc file 



Latency / Throughput in Block Diagram 

Signal connection 

Processes in 

SC_CTOR like 

SC_CTHREAD, 

SC_THREAD, 

SC_METHOD. (Don't 

place process bubles 

for SC_SLAVE and 

other methods!) 

Instance Name 

Module Name 

master port name 

process_name() 

slave port name 

LAT 

THRxClk 

Latency of the 

process 

Throughput of the 

process 

Clock Name 

ConfigSR 

ShiftReg 

PortName_In 

PortName_Out 

Port Name 

Internal named signal 

Class_In 

Internal signal 

Classes with thick 

lines 

Write the external 

port name inside this. 

Hierarchical port 

connection. This port 

connects to upper 

level module. 



Latency / Throughput 

Latency 

+ 

Throughput 

+ 

Ref. Clk 

Calc1 

Calculate 

Data_In 

calc() 

Data_Out 

3 

1xClk20 

Calc1 

Calculate 

Data_In 

≡ calc() 

Data_Out 

1xClk20 

1xClk20 

1xClk20 

instate[LAT] 

instate[LAT] 

//0.....LAT-1 

//0.....LAT-1 

init() 

init() 

: 

: 

instate[i]=0; 

instate[i]=0; 

inptr 

inptr 

= 

= 

0; 

0; 

while(true) 

while(true) 

{ 

{ 

a= 

a= 

Data_In.read(); 


inptr 

inptr 

= 

= 

index 

index 

% 

% 

LAT; 

LAT; 

instate[inptr]= 

instate[inptr]= 

a; 

a; 

outptr=(inptr 

outptr=(inptr 

+ 

+ 

1)%LAT; 

1)%LAT; 

b=calc(instate[outptr]); 

b=calc(instate[outptr]); 

wait(THR-1); 

wait(THR-1); 

Data_Out.write(b); 


index++; 

index++; 

wait(); 

wait(); 

} 

} 

instate[LAT] 

instate[LAT] 

//0.....LAT-1 

//0.....LAT-1 

init() 

init() 

: 

: 

instate[i]=0; 

instate[i]=0; 

inptr 

inptr 

= 

= 

0; 

0; 

while(true) 

while(true) 

{ 

{ 

for 

for 

(int 

(int 

i 

i 

= 

= 

(LAT-1), 

(LAT-1), 

i>0, 

i>0, 

i- 

i- 

-) 

-) 

{ 

{ 

instate[i] 

instate[i] 

= 

= 

instate[i-1]; 

instate[i-1]; 

} 

} 

instate[0] 

instate[0] 

= 

= 



b 

b 

= 

= 

calc(instate[LAT-1]); 

calc(instate[LAT-1]); 

wait(THR-1); 

wait(THR-1); 



wait(); 

wait(); 

} 

} 


Outline 


t 

t 








t Horizontal - Vertical 

t 

t 


Summary 



Testbench Strategy (horizontal re-use) 

TimeD 

F 

I 

F 

O 

CMPY 

F 

I 

F 

O 

FFT 

F 

I 

F 

O 

FreqD1 

F 

I 

F 

O 

FreqD2 

F 

I 

F 

O 

HW 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

DPRam 

DPRam 

DPRam 

DPRam 

DPRam 

TB1 TB2 TB3 TB4 TB5 

Processor 

Operational Firmware 

FW 

Load Evaluate Get/Analyze 



Testbench Strategy (horizontal re-use) 


F 

I 

F 

O 

Master/Slave 

Link 

Coeff 

Result 

Master/Slave 

Link 

F 

I 

F 

O 




Coeff 

UpdateConfig 

DataPath 

LCtrl 

ConfigUpdated 


Processor 




Testbench Strategy (vertical re-use) 

Matlab as the 

algorithmic 

reference 


Testbench 

Algorithmic Modelling 

Matlab 

SystemC Modelling 

HW 

FW 


VHDL C-code 

Reused in all stages 

of the design! 

Prototype Tests 



Testbench Strategy (vertical re-use) 


Matlab 

Algorithmic 

Reference 

F 

I 

F 

O 

Master/Slave 

Link 

Coeff 

Result 

Master/Slave 

Link 

F 

I 

F 

O 

.mat 




UpdateConfig 

Coeff 

DataPath 

LCtrl 

Processor 

ConfigUpdated 



.mat 

Equal? 


Result 



Execution of the Model 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

| Rx_Section5 module test starts! | 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

|-------------------------------------------------------------------| 

| Test_reference list: | 

| 1 -TopLevel_Push_Tag_Only | 

| 2 -TopLevel_BPSK_1_2 | 

| 3 -TopLevel_QPSK_3_4 | 

| 4 -TopLevel_16QAM_9_16 | 

| 5 -TopLevel_64QAM_2_3 | 

| 6 -TopLevel_BPSK_1_2_4OFDM | 

|-------------------------------------------------------------------| 

>> Select one of the test_reference numbers:2 

>> Do you want debug-info?(0=No,1=Yes)0 

(SOFTCODING) : soft reseted at 0 0 clk cycle 

(DEINTERLEAVER) : soft reseted at 0 0 clk cycle 

(DEPUNCTURER) : soft reseted at 0 0 clk cycle 

(VITERBI) : soft reseted at 0 0 clk cycle 

(DESCRAMBLER) : soft reseted at 0 0 clk cycle 

(SCHEDULER) : soft reseted 0 0 clk cycle 

. 

(TESTBENCH) : Matlab input file = 

./input_mat_files/TopLevel_BPSK_1_2_in.mat 

(TESTBENCH) : Matlaboutput file 

:./output_mat_files/TopLevel_BPSK_1_2_out.mat 

(SCHEDULER) : process_scheduler() started at 0 0 clk cycle 

(TESTBENCH) : Modulation = BPSK 1/2 

(TESTBENCH) : Ncbps = 48 

(TESTBENCH) : Nbpsc = 1 

(TESTBENCH) : P1 puncturing disabled 

(TESTBENCH) : Dummy Softbit = 100 

(TESTBENCH) : Viterbi Traceback Depth = 96 

(TESTBENCH) : Descrambler Mode = Reset with external seed 

(TESTBENCH) : Seed = 1110100 

(TESTBENCH) : Tag pushed 

(TESTBENCH) : Number of OFDM symbols = 10 

User 

interface 

Resetting 

blocks 

Opening 

input/ 

creating 

output files 

Configuration 

data sent by 

testbench 

(SCHEDULER) : config signals updated at 50 1 clk cycle 

(SOFTCODING) : config updated at 50 1 clk cycle 

(DEINTERLEAVER) : config updated at 50 1 clk cycle 

(DEPUNCTURER) : config updated at 50 1 clk cycle 

(VITERBI) : config updated at 50 10 clk cycle 

(DESCRAMBLER) : config updated at 50 1 clk cycle 

(SOFTCODING) : DATA IN :0 DATA :000001 FLAG :0 

(SCHEDULER) : current_config_.DeScramblerMode()--->2 at 5350 107 clk cycle 

. 

(DEINTERLEAVER) : enabled for OFDM symbol 1 at 100 2 clk cycle 

. 

(DEPUNCTURER) : enabled for OFDM symbol 1 at 1100 22 clk cycle 

. 

(VITERBI) : enabled for OFDM symbol 1 at 1300 26 clk cycle 

. 

(DESCRAMBLER) : enabled for OFDM symbol 1 at 5350 107 clk cycle 

. 

(TESTBENCH) : Section is done! 

(TESTBENCH) : Files are closed ! 

***************************************************************************** 

* START COMPARING OUTPUT WITH GOLDEN REFERENCE 

* 

* First file : ./output_mat_files/TopLevel_BPSK_1_2_out.mat 

* Second file : ./golden_output_mat_files/TopLevel_BPSK_1_2_golden_out.mat 

* Arrays in two files : 

* RxS5TopLevelOut_systemc 2 160x1 real numbers 

* TOPLEVELOutput 2 160x1 real numbers 

* 

***************************************************************************** 

* REPORT : 

* 

* Number of bits compared : 160 

* There is no difference between arrays in two files 

* 

* Files are closed successfully. 

End of the test 

Configuration 

received by 

blocks 

Processing 

data 

Result of 

comparison 

***************************************************************************** 

Comparison results are written to "results.log" file. 

Comparing 

output 

with 

golden 

output 



Results File 

***************************************************************************** 

* START COMPARING OUTPUT WITH GOLDEN REFERENCE * 

* First file : ./output_mat_files/TopLevel_BPSK_1_2_out.mat 

* Second file : ./golden_output_mat_files/TopLevel_BPSK_1_2_golden_out.mat 

* Arrays in two files : 

* RxS5TopLevelOut_systemc 2 160x1 real 

numbers 

* TOPLEVELOutput 2 160x1 real 

numbers 

* 

* 

* Comparing 1. column(OFDM symbol except descrambler) 

* 0 ...............................................… 

* 50 ...............................................… 

* 100 ...............................................… 

* 150 .......… 

* 

* Comparing 1. Column 

* SYSTEMC MATLAB 

* 0. 1 1 

* 1. 1 1 

* 2. 1 1 

* 3. 1 1 

* 4. 0 0 

* 5. 0 0 

* 6. 0 0 

* 7. 0 0 

. 

. 

Output (SystemC) and 

Reference(Matlab) Data 

***************************************************************************** 

* REPORT : 

* Number of bits compared : 160 

* There is no difference between arrays in two files 

* 

* Files are closed successfully. 

***************************************************************************** 

Output and 

Reference File 

Info 

“.” means that output is same with 

reference 

“x” means errors 

Result Summary 


Outline 


t 

t 



t 


• AME needs and CoWare N2C as a solution 

• Complex Multiplier for SystemC/VHDL 

cosim 

• Complex Multiplier for SystemC/ISS 

cosim 

• Complex Multiplier for SystemC/ISS/VHDL 

cosim 

t 

Summary 


Co-simulation 

AME needs and N2C as a solution 

Coware’s N2C flow 

Sign-off 

system functionality 

Sign-off between 

system developer, 

hardware developer 

and software developer 

Sign-off for 

processing 

1 System Specification 

System specification 

& 

environment model 

2 Partitioning & interface design 

Partitioning 

& 

interface design 

Hardware 

implementation 

C simulation 

Simulation 

-C 

-Assembly 

Software 

optimization 


Link to CoSim 

environment. 

Manual or 

by tool. 

3 Hardware implementation and software optimization 

CoSim and 

design 


Abstr. 

RTOS 

RTO 

S 

AME Flow 

Matlab 

UTF 

TF 

BCA 

RTL 

Algorithmic 

Design and 

Validation 

System 

Design and 

Validation 

BCA 

CoSim Environment 

Software Hardware Firmware 

CoSim Environment 

Target 

Software Hardware Firmware 

Design and Design and Design and 

Validation Validation Validation 

C 

Function 

Simulation 

-Multi-level mixed mode 


Co-simulation 

SoC SystemC / VHDL CoSim 

t 

SystemC model as reference for “HW (VHDL) design” 

TimeD 

DPath 

LCtrl 

TimeDomain 

F 

I 

F 

O 

CMPY 

DPath 

LCtrl 

Complex MPY 

F 

I 

F 

O 

DPath 

LCtrl 

FFT 

FFT 

F 

I 

F 

O 

FreqD1 

F 

I 

F 

O 

FreqD2 

DPath 

LCtrl 

Freq Dom 2 

Section 

HW 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

LCtrl 

DPRam 

DPRam 

DPRam 

DPRam 

DPRam 

Processor 

FW 


t 

SystemC and VHDL Co-simulation 


Co-simulation 

SystemC / VHDL 


BlackBox 

F 

I 

F 

O 

F 

I 

F 

O 

Master/Slave 

Link 

sc_uint 

std_logic_vector 

Coeff 

std_logic 

Result 

sc_uint 

Master/Slave 

Link 

F 

I 

F 

O 

F 

I 

F 

O 





UpdateConfig 

UpdateConfig 

Coeff 

Coeff. Register 

std_logic 

DataPath 

DataPath 

LCtrl 

LCtrl 

Wrapper Around Vhdl 

sc_uint 

SystemC I/F 

ConfigUpdated 

ConfigUpdated 



Processor 


Co-Simulation 

SystemC / VHDL 

t 

Wrapper around VHDL: to convert generic C / SystemC types to VHDL 

data types 

SC_MODULE(CoSimWrapper_BCA_version) 

SC_MODULE(CoSimWrapper_BCA_version) 

{ 

{ 

cwr_clock_inslave 

cwr_clock_inslave 

Clk_20M; 

Clk_20M; 

sc_inslave 

sc_inslave 

Mult_In; 

sc_outmaster 

sc_outmaster 

 

ReadFIFOEn_Out; 

ReadFIFOEn_Out; 

sc_uint 

} 

} 

SC_CTOR 

SC_CTOR 

(CoSimWrapper_BCA_version) 

(CoSimWrapper_BCA_version) 

{ 

{ 

// 

// 

location 

location 

of 

of 

the 

the 

source 

source 

file 

file 

cwr_add_attribute 

cwr_add_attribute 

(this, 

(this, 

"import", 

"import", 

"source 

"source 

= 

= 

(\"./CoSimWrapper.Entity.vhd\");"); 

(\"./CoSimWrapper.Entity.vhd\");"); 

// 

// 

replace 

replace 

"." 

"." 

to 

to 

"_" 

"_" 

when 

when 

referring 

referring 

to 

to 

signals 

signals 

in 

in 

ports 

ports 

in 

in 

this 

this 

context 

context 

// 

// 

for 

for 

exampl 

exampl 

clk.clk 

clk.clk 

to 

to 

clk_clk 

clk_clk 

cwr_add_context 

cwr_add_context 

(this, 

(this, 

"component 

"component 

CoSimWrapper\n" VHDL 

CoSimWrapper\n" 

component in SystemC 

" 

" 

port 

port 

(\n" 

(\n" 

" 

" 

Clk_20M 

Clk_20M 

: 

: 

in 

in 

std_logic;\n" 

std_logic;\n" 

" 

" 

Mult_In 

Mult_In 

: 

: 

in 

in 

std_logic_vector(23 

std_logic_vector(23 

downto 

downto 

0);\n" 

0);\n" 

" 

" 

ReadFIFOEn_Out 

ReadFIFOEn_Out 

: 

: 

out 

out 

std_logic;\n" 

std_logic;\n" 

// 

// 

Connect 

Connect 



ports 

ports 

to 

to 

VHDL 

VHDL 

ports 

ports 

" 

" 

CoSimWrapper_1 

CoSimWrapper_1 

: 

: 



" 

" 

port 

port 

map 

map 

(\n" 

(\n" 

" 

" 

Clk_20M 

Clk_20M 

=> 

=> 

Clk_20M_clk,\n 

Clk_20M_clk,\n 

" 

" 

" 

" 

Mult_In 

Mult_In 

=> 

=> 

Mult_In_d,\n 

Mult_In_d,\n 

" 

" 

" 

" 

ReadFIFOEn 

ReadFIFOEn 

_Out 

_Out 

=> 

=> 

ReadFIFOEn_Out_d,\n 

ReadFIFOEn_Out_d,\n 

" 

" 


t 

Co-simulation 

SystemC/VHDL 

SystemC I/F Wrapper: to convert C++ data types to generic C or 

SystemC data types 

SC_MODULE(SystemCInterface){ 

SC_MODULE(SystemCInterface){ 

// 

// 



Interface 

Interface 

port 

port 

declarations 

declarations 

sc_in_clk 

sc_in_clk 

Clk20; 

Clk20; 

sc_outmaster 

sc_outmaster 

Mult_Out; 

Mult_Out; 

sc_inmaster 

sc_inmaster 

Mult_In; 

Mult_In; 

sc_inslave 

ReadFIFOEn_In; 

ReadFIFOEn_In; 

sc_outmaster 

MultSerialData_Out; 

MultSerialData_Out; 

sc_inslave 

MultSerialData_In; 

MultSerialData_In; 

... 

... 

void 

void 

read_fifo_out(); 

read_fifo_out(); 

Conversion of Mult_In to MultSerial_Out 

SC_CTOR(SystemCInterface) 

SC_CTOR(SystemCInterface) 

{ 

{ 

SC_THREAD(read_fifo_out); 

SC_THREAD(read_fifo_out); 

sensitive_pos 

sensitive_pos 

1 CA or 

TF 

Co-simulation 

ComplexMPY Abstract Levels 

F 

I 

F 

O 

Master/Slave 

Link 


Coeff 

Result 

Master/Slave 

Link 

F 

I 

F 

O 

2 TF 


Matlab 

UTF 

TF 

Algorithmic 

Design and 

Validation 

System 

Design and 

Validation 

Function 




Coeff 

UpdateConfig 

DataPath 

LCtrl 

ConfigUpdated 


1 CA or 

TF 

Abstr. 

RTOS 

RTO 

S 

Software 

Software 

Design and 

Validation 

BCA 

RTL 

Hardware 

Hardware 

Design and 

Validation 

BCA 

C 

Firmware 

Firmware 

Design and 

Validation 

Target 

2 TF 

Processor 


Co-simulation 

SystemC/VHDL 

1RTL 


F 

I 

F 

O 

sc_uint 


std_logic 

DataPath 

sc_uint 

F 

I 

F 

O 

2TF 


Matlab 

UTF 

TF 

Algorithmic 

Design and 

Validation 

System 

Design and 

Validation 

Function 


UpdateConfig 


std_logic 

LCtrl 


sc_uint 


Processor 

ConfigUpdated 

2TF 


Abstr. 

RTOS 

RTO 

S 

Software 

Software 

Design and 

Validation 

1RTL 

BCA 

RTL 

Hardware 

Hardware 

Design and 

Validation 

BCA 

C 

Firmware 

Firmware 

Design and 

Validation 

Target 


Co-simulation 

SoC SystemC/ISS CoSim 

t 

SystemC model as reference for “FW (C-code) design” 

TimeD 

F 

I 

F 

O 

CMPY 

F 

I 

F 

O 

FFT 

F 

I 

F 

O 

FreqD1 

F 

I 

F 

O 

FreqD2 

HW 

LCtrl 

DPRam 

LCtrl 

DPRam 

LCtrl 

DPRam 

LCtrl 

DPRam 

LCtrl 

DPRam 

D 

SRAM 

CPU Core 

ARM Processor 

MAC 

I 

SRAM 

Processor 

ISS : 

Instruction 

Set 

Simulator 


FW 

t 

SystemC and ISS Co-simulation 


Co-Simulation 

SystemC / ISS 

Black Box 

fifo_config class 

new_fifo_config 

struct 

F 

I 

F 

O 


Complex 

Multiplier 

LCtrl 

C++ classes (may be hierarchical) 

N2c compliant System-C Wrapper around not N2c compliant System-C 


F 

I 

F 

O 

sc_indexed port 

Basic C types 

Non-hierarchical C structs 

Indexed ports 

SC_MODULE 

mapped to a 

processor 

SystemC I/F (N2C) 

PROCESSOR 

C- code 

System 

Bus 

Clock and Reset 

generators for 

processor 


t 

Wrapper for ISS 

Co-Simulation 

SystemC / ISS 

// 

// 

fifo_config 

fifo_config 

class 

class 

template 

template 

 

class 

class 

fifo_config 

fifo_config 

{ 

{ 

public: 

public: 

void 

void 

fc_cmd(int 

fc_cmd(int 

command); 

command); 

int 

int 

fc_cmd(); 

fc_cmd(); 

void 

void 

fc_index(int 

fc_index(int 

idx); 

idx); 

int 

int 

fc_index(); 

fc_index(); 

void 

void 

fc_value(itemT 

fc_value(itemT 

val); 

val); 

itemT 

itemT 

fc_value(); 

fc_value(); 

void 

void 

fc_status(fifo_status_s 

fc_status(fifo_status_s 

sts); 

sts); 

fifo_status_s 

fifo_status_s 

fc_status(); 

fc_status(); 

// 

// 

Define 

Define 

the 

the 

= 

= 

operator 

operator 

inline 

inline 

void 

void 

operator 

operator 

= 

= 

(const 

(const 

fifo_config& 

fifo_config& 

rhs){ 

rhs){ 

fc_cmd_ 

fc_cmd_ 

= 

= 

rhs.fc_cmd_; 

rhs.fc_cmd_; 

fc_index_ 

fc_index_ 

= 

= 

rhs.fc_index_; 

rhs.fc_index_; 

fc_value_ 

fc_value_ 

= 

= 

rhs.fc_value_; 

rhs.fc_value_; 

fc_status_= 

fc_status_= 

rhs.fc_status_; 

rhs.fc_status_; 

} 

} 

private: 

private: 

int 

int 

fc_cmd_; 

fc_cmd_; 

int 

int 

fc_index_; 

fc_index_; 

itemT 

itemT 

fc_value_; 

fc_value_; 

fifo_status_s 

fifo_status_s 

fc_status_;}; 

fc_status_;}; 

// 

// 



struct 

struct 

struct 

struct 

fifo_config 

fifo_config 

{ 

{ 

int 

int 

fc_cmd_; 

fc_cmd_; 

int 

int 

fc_index_; 

fc_index_; 

// 

// 

do 

do 

not 

not 

use 

use 

hierarchical 

hierarchical 

structs 

structs 

// 

// 

divide 

divide 

fifo_status_s 

fifo_status_s 

into 

into 

members 

members 

int 

int 

fs_buffer_size; 

fs_buffer_size; 

int 

int 

fs_wrptr; 

fs_wrptr; 

int 

int 

fs_rdptr; 

fs_rdptr; 

int 

int 

fs_nbrerrwr; 

fs_nbrerrwr; 

int 

int 

fs_full; 

fs_full; 

int 

int 

fs_empty; 

fs_empty; 

}; 

}; 

sc_indexed 

sc_indexed 

port 

port 

for 

for 

itemT 

itemT 

fc_value_ 

fc_value_ 

sc_inoutmaster 

FIFOData; 

FIFOData; 

// 

// 

128 

128 

comes 

comes 

from: 

from: 

// 

// 

64 

64 

real 

real 

part 

part 

of 

of 

an 

an 

OFDM 

OFDM 

symbol 

symbol 

// 

// 

64 

64 

imaginary 

imaginary 

part 

part 

of 

of 

an 

an 

OFDM 

OFDM 

symbol 

symbol 


Co-simulation 

SoC SystemC / ISS / VHDL CoSim 

t 

SystemC and VHDL and ISS Co-simulation 

TimeD 

DPath 

LCtrl 

TimeDomain 

LCtrl 

DPRam 

F 

I 

F 

O 

CMPY 

DPath 

LCtrl 

CMPY 

LCtrl 

DPRam 

F 

I 

F 

O 

FFT 

LCtrl 

DPRam 

F 

I 

F 

O 

FreqD1 

LCtrl 

DPRam 

F 

I 

F 

O 

FreqD2 

LCtrl 

DPRam 

HW 

D 

SRAM 

I 

SRAM 

CPU Core 

ARM Processor 

MAC 

Processor 

ISS : 

Instruction 

Set 

Simulator 


FW 


Co-Simulation 

SystemC / ISS / VHDL 


C++ classes 

F 

I 

F 

O 


sc_uint 


std_logic 

DataPath 

sc_uint 


F 

I 

F 

O 


std_logic 

LCtrl 


with SystemC 


SC_MODULE mapped to a 

processor 

PROCESSOR 

C-code 

System 

Bus 


Co-Simulation 

ISS / VHDL 


F 

I 

F 

O 


F 

I 

F 

O 

DataPath 


LCtrl 

std_logic 

Wrapper Around Vhdl with SystemC I/F 


SC_MODULE mapped to a 

processor 

PROCESSOR 

C-code 

System 

Bus 


Summary 

t 

t 

t 

t 

SystemC is the GOLDEN reference throughout 

the design phases (iterative and model-based) 

• Matlab as an algorithmic reference for SystemC. 

Integration methodology based on 

• Master/slave ports : M/S communication has advantages. 

• Classes and pointers 

Testbench strategy: 

• Horizontal 

• Vertical 

Co-simulation: 

• SystemC / VHDL 

• SystemC / ISS 

• SystemC / ISS / VHDL 


Part V 

AME’s Experience with 

SystemC Based 

Design Methodology 


Part V - slide 1

Outline 

Part V. AME’s Experience 

t 


t 

Introducing SystemC in AME 

t 

Design Engineers’ Involvement 

t 

SystemC Approach 

t 

Conclusion 


Part V - slide 2

Outline 


t 

t 

t 

t 

t 


• Overview 

• Project Phases 

• Project Team Setup 


Design Engineers’ involvement 


Conclusion 


Part V - slide 3


( Overview ) 

t 


RF 

front 

end 

Analog 

SystemC execution output: 


Global 

Controller 

CL 

Control 

SAP 

Core 

Network 

>(Testbench) : Starting Test1. 

>(Testbench) Digital: Transmission started at time 500 ns. 

>(PHY) : System reseted at time 300 ns 

>(PHY) : Sytem running for 3 frames...... 

>(PHY) : Transmitting frame 1... 

>(PHY) Transmit : Transmitting Data-Path frame 2... 

>(PHY) : & 

Local Transmitting Controller 

frame 3... 

>(PHY) : Transmission Completed!!. 

>(Testbench) : Comparison started 

CL 


User 

>........ 

& 

SAP 

>........ 


>(Testbench) : Comparison completed 

>(Testbench) : see Test1.LOG file 

Core 

Network 





[ MAC - DLC ] 


[ PHY ] 

HiperLAN-2 

Core 

Network 

Program 

SDRAM 

(Fw/Sw) 

(E)PROM 

(Fw/Sw) 


Part V - slide 4

OWL Project Phases 


t 

OWL Case : R&D Trajectory is ITERATIVE & MODEL based 

• Re-use of SW methodology coming from RUP in project context 

• Main target : reduce Risks in order to get ASAP Working Product 

• Early feedback from Executable SystemC model in First iteration 

• Models are not “throw-away” but re-used throughout iterations 

• SystemC is baseline for next iterations : testbench re-usage 

• keep models well-documented, high-quality and consistent ! 

S 

It.0 

It.1 

It.2 

It.3 

matlab 

systemC 

VHDL\ISS 

FPGA 

Silicon 


Part V - slide 5

OWL Project Phases 


S 

It.0 

It.1 

It.2 

It.3 

Matlab 

systemC 

VHDL\ISS 

FPGA 

Silicon 

> Matlab 

Modelling 

> SystemC 

Modelling 

> HW design 

> FW design 

> Cosimulation 

Step Risk Covered Model/Platform Used Test Target 

S : Feasibility Feasibility - Algorithms Matlab Function 

It0 : Definition Specification - System&Architecture SystemC Simulated Timing & Bit level 

It1 : Development 

Discrepancy Physics/Model 

SystemC as golden reference for 

Check implementation 

Integration & Coexistence of 

SystemC+ISS+VHDL cosimulation 

versus SystemC golden reference 

HW/FW 

environment 

It2 : Development 

RTL Implementation 

SystemC as golden reference 

for FPGA + Integration boards 

Simulated Timing & Bit level 

It3 : Validation 

Backend & production 

SystemC as golden reference 

for real Silicon on Integration boards 

and System Qualification tests 

Full system 


Part V - slide 6

OWL Project Team Setup 

( Context of SystemC teams ) 

t 

Teams and Interactions (in/out AME) 

Tools 

Emb. Proc. 

Design 

Method. 

FPGA 


IP Blocks 

VHDL 

CAD 

Method. 

SW 


Part V - slide 7

OWL Project Team Setup 

( SystemC teams ) 

Tools 

Emb. Proc. 

Design 

Method. 

FPGA 

Task 2 


Teams 

Task 3 Task 3 

Task 1 Task 1 

Task 4 Task 4 

Task 5 Task 5 

IP Blocks 

VHDL 

CAD 

Method. 

SW 


Part V - slide 8

Outline 


t 

t 

t 

t 

t 





Conclusion 


Part V - slide 9


Experience/Activities 

ManPower ManPower 

SystemC Modelling 

SystemC Methodology 

VHDL 


& 

Firmware 



language 

AME 


Methodology 

Start 

week1 

week5 

Time 


Part V - slide 10

Outline 


t 

t 

t 

t 

t 




• Phase 1 : SystemC Modelling 

• Phase 2 : Implementation, Verification and Testing 


Conclusion 


Part V - slide 11


( Phase 1 : SystemC modelling ) 

Phase 1 : 


Modelling 

HW 

designers 


Part V - slide 12

HW designers in Phase 1 

t 

t 

t 

t 



HW designers are familiar with SystemC concepts like 

• ports 

• signals 

• wait() concept 

HDL background is an advantage while learning/using 

SystemC to model a HW block. 

HW design experience makes it easier for a designer to 

make timing assumptions for TF models in SystemC. 

C++ and Object-Oriented Oriented background helps 

HW-designers to get used to SystemC syntax. 


Part V - slide 13



Phase 1 : 


Modelling 

HW 

designers 

SW 

designers 


Part V - slide 14

SW designers in Phase 1 

t 

t 

t 

t 

SW designers are familiar with the syntax of SystemC, 

since it is a C++ based language 

UTF models of SystemC are very similar to SW coding. 

SW designers are less familiar with HW-concepts like 

• ports 

• signal timings and wait() 

Knowledge of abstract timing concepts such as 

• throughput 

• latency 



makes it possible for SW designers to develop CA 

Models. 


Part V - slide 15



Phase 1 : 


Modelling 

HW 

designers 

SW 

designers 

System 

designers 


Part V - slide 16

System designers in Phase 1 

t 

t 

t 

t 


( Phase 1 : SystemC Modelling ) 

Facilitate making executable spec. out of Matlab 

algorithms. 

Matlab usage (Algorithms + GUI) facilitates 

communication between HW/SW and system engineers. 

They decide on model abstraction level (BCA/CA vs. 

UTF/TF) to guide HW/SW engineers. 

SystemC language is easy to use by System engineers. 


Part V - slide 17


( Phase 2 : Impl. , verification and testing ) 

Phase 1 : 


modelling 

HW 

designers 

SW 

designers 

System 

designers 

Phase 2 : 


Verification 

and Testing 

HW/SystemC 

Co-Simulation 

ISS/SystemC 

CoSimulation 

SystemC reuse in 

system tests 

-FPGA 

-IC/ lab 


Part V - slide 18


t 

SystemC creates a suitable platform for 

• SW, 

• HW and 

• system designers 

to contribute to 

Executable specification of the design 

t 

Mutual interaction between different teams/disciplines 

• improves quality of the designed product 

• enhances the development time. 

• increases technical competence and related skills 

This makes up an ideal TEAM! 


Part V - slide 19


( Modelling and Implementation ) 

Classical approach 

System designers 

SystemC approach 


HW spec 

- funct. 

- perf. 

SW spec 

HW spec 

- funct. 

- perf. 

SW spec 

System level understanding 

HW designers 

SW designers 

HW designers 

SW designers 


Part V - slide 20

Outline 


t 

t 

t 

t 

t 





Conclusion 


Part V - slide 21


( Testbench re-usage ) 

Classical approach 


SystemC approach 


Testbench 1 

HW spec 

- funct. 

- perf. 

SW spec 

Testbench 

HW spec 

- funct. 

- perf. 

SW spec 

System level understanding 

HW designers 

SW designers 

Testbench 2 

HW designers 

Testbench 3 

SW designers 

Testbench 

Testbench 

Testbench 4 

Testbench 


Part V - slide 22


( Examples from OWL-experience ) 

Matlab 

model 

Matlab 

output 

Matlab 

stimuli 


output 

HW spec 

- funct. 

HW spec 

- funct. 

- perf. 

- perf. 

HW designers 


SW spec 

SW spec 

SW designers 

t 

Matlab integration 

• Matlab files are read by 

SystemC Models. 

• SystemC dumps results to 

Matlab files 

• SystemC testbench 

compares the SystemC 

spec outputs to Matlab 

reference outputs and 

generates reports 

Reports 

Analyze 

in 

Matlab environment 


Part V - slide 23


( Examples from OWL-experience ) 

HW spec 

- funct. 

- perf. 

HW designers 


Reports 

SW spec 

SW designers 

t 

t 

SW bug 

The Model is executable 

Early bug detection!! 

• alarm conditions of the system 

are detected at SystemC top level 

integration phase 

• HW/SW interface is designed 

and bugs are fixed at SystemC 

design phase 



(Testbench) : Starting Test1. 

(Testbench) : Transmission started at time 500 ns. 

(PHY) : Sytem running....... 

(PHY) : 5 symbols of frame 1 transmitted.. 

(PHY) : FIFO1 full! System error!!! 

(Testbench) : Starting Test1. 

(Testbench) : Transmission started at time 500 ns. 

(PHY) : Sytem running....... 

(PHY) : Parameter P1 =0 , P2 = BPSK, P3 = 1/2 

.... 

(PHY) :Output not as expected!! See LOG file 


Part V - slide 24


( Design complexity and time ) 

t 

t 

Mastering design complexity 

Reducing design time ( and first-time 

time-right ! ) 

Examples of some sub-blocks blocks : 

CA 

TF 

CA 

System 

C code 

size 

VHDL code 

size (#lines) 

Hardware size 

(#Gates) 

VHDL 

development 

time (mandays) 


development 

time (mandays) 

HWObservations 400 2083 37295 80 65 

Processor 1789 2221 10272 150 50 

Rotor 686 770 60999 25 15 

Correlator 102 210 24900 35 10 

Counter 220 137 1183 10 2 

Deinterleaver 200 20 2 

Viterbi 1100 40 5 


Part V - slide 25

Outline 


t 

t 

t 

t 

t 





Conclusion 


Part V - slide 26

Conclusion 

t 

Errors detected in early stage 

t System specification is generated : 

t 

t 

t 

t 

• without thinking about HW/SW first. 

• As specification evolves, parts to be implemented in SW and HW become b 

clearer. 

The methodology development done for this project 

• smoothened integration phase (SW/HW SystemC model integration) 

• may be reused in other projects 

Testbenches come with the Spec. 

These testbenches can be reused in implementation and 

testing phases. 

Matlab is integrated to SystemC testbenches. 


Part V - slide 27

Part VI. 

Summary and Conclusions 


Part VI - slide 1

Summary 

t Need for System-on 

on-Chip (SoC) Design Methodology 

t OSCI SystemC provides solution : 

Language & reference simulator 

• Suitable for system ( hardware , firmware , software ) level design 

• Supports different levels of abstraction 

with gradual and partial refinement 

• Executable specification 

• Open Source SystemC Initiative 

• Big momentum , world-wide 

wide 

• Roadmap : new versions evolve while being backwards compatible 

• Seed for SystemC-based tools and methodologies 

t Besides the language, one needs also a Methodology ... 

• AME used the SystemC language to develop 

an own SystemC-based SoC-Design Methodology 


Part VI - slide 2

Summary 

t 

t 

Introducing SystemC in Alcatel Microelectronics 

• Early adoption of SystemC language and reference simulator 

• Fast learning curve 

• In context of real-life life project : OWL Wireless LAN Project 

• Resulted in : OWL Executable System model 

( Hardware , Firmware , Software ) 

• Resulted in : 


The AME SoC Design Methodology 

• Iterative based design : reducing risks , model based 

• Iteration-0 0 : SystemC model development 

t executable specification as golden reference 

t tool for early (designers/customers) feedback and design decisions 

• Next iterations ( design implementation, test and qualification ): 

t SystemC model as reference & test-bench re-usage 

t SystemC based co-simulation during hardware and software design 


Part VI - slide 3

t 

Summary 

Experience from the OWL Project 

• SystemC is easy to learn and use 

• SystemC is extendable : C++ , Matlab integration , fixed point types 

• Fast model development for complex and large system 

t Abstraction level : mainly TF , some CA 

t Master/Slave communication, separated from behaviour 

• Model integration methodology is required 

• Methodology needs to be well documented 

• Allows early involvement of several multi-disciplinary teams (system, 

hardware, software engineers) : 

t cross-fertilization of ideas 

t the ideal team ! 

• Executable model results in 

t fast feedback from designers / customers / marketing 

t early bug-detection 

t faster and higher-quality design cycles 


Part VI - slide 4

Conclusion 

t 

The OWL Project team at Alcatel Microelectronics 

gained large experience and expertise 

in System-on 

on-Chip development 

and SoC Design Methodologies 

by using SystemC 

and making an executable specification 

of a real-life life Wireless LAN product 

!! Hip hip hurray for SystemC !! 


Part VI - slide 5

Appendix 

References 

t 

t 

t 

t 

http://www.systemC 

systemC.org 

SystemC source code 

UserGuide.pdf 

systemc-forum@ 

forum@systemc.org 

http://www-ti 

ti.informatik.uni-tuebingen.de/~ 

.de/~systemc 

ESCUG 

http://www 

www.ittf.no/ 

.no/aktiviteter/2001/dakforum/program 

DAK2001 Forum 2001 

http://www.alcatel 

alcatel.com/microelectronics 

marc.pauwels 

pauwels@mie.alcatel.be 

yves.vanderperren 

vanderperren@mie.alcatel.be 

ates.berna 

berna@alcatel.com. 

.com.tr 

fatma.ozdemir@alcatel.com. 

.com.tr 

.be fatma 


Part VI - slide 6

SystemC Tutorial - Microelectronic Systems Laboratory

Create successful ePaper yourself

Delete template?

Save as template?