SoC design methodology

Using SystemC

Bart Vanthournout

© CoWare, Inc. 1997-2003 CoWare Confidential

Agenda
• ESL trends
− Network on Chip, Application Specific processors (ASIP)
− SoC design requirements, Abstraction levels
• SystemC Transaction level modeling
• CoWare tools

© CoWare, Inc. 1997-2003 CoWare Confidential

1
 Key Challenges With Chip Design
Relative Effort by Designer Role

250%

200%
Software
150% Validation
Physical
100% Verification
Architecture
50%

0%
350nm 250nm 180nm 130nm 90nm

Software effort Architecture effort

overtakes hardware effort overtakes physical design
at 130 nm at 90 nm

Source: IBS, November 2002 CoWare Confidential

© CoWare, Inc. 1997-2003

What is changing
• Magarshack & Paulin (DAC’03)
− Cause:
− Shrinking of design technology
− Increase in NRE cost for manufacturing (>1M$) and design (10-
(10-100M$)
of SoC
− For non multi-
multi-million chip volume cost needs to be amortized over multiple
products
− Observation:
− IP reuse is not sufficient
− IP is not fixed with shrinking technologies leading to verification
verification and design-
design-
for test issues
− Methodology Requirement:
− Need for revolutionary design methods enabling:
− Faster ‘Time To Market’ through IP reuse, standard communication interfaces
and scalable interconnect topology (NoC)
− Increased flexibility through SW programmability and configurable
configurable HW
− Enable to map an application to a platform to increase the productivity
productivity of a
platform user

© CoWare, Inc. 1997-2003 CoWare Confidential

2
What is changing
• Magarshack & Paulin (DAC’03)
− Solution:
− Emergence of flexible, domain-
domain-specific, SW programmable platforms
(processor, IP, interconnect)
− Methodology based on 4 distinct abstraction levels
1. System application design
− embedded SW and platform configuration specification
2. Multiprocessor SoC platform design
− specification, assembly and configuration of IP blocks
3. Highlevel IP block design
− ASIP, interconnect, HW IP for standards, standard I/O devices, etc
etc
4. Semiconductor technology and basic IP
− Process dependencies
− Tool requirement:
− Correctly map of highlevel abstraction to the lower layers
− Topdown methodology

© CoWare, Inc. 1997-2003 CoWare Confidential

What is changing
• Sangiovanni-
Sangiovanni-Vincentelli & Grant Martin (CASES’01)
Embedded SW design Vision
− Situation:
− Embedded SW is an implementation choice for a function that can be
implemented as HW as well
− Increasingly more ESW due to platform based design, where re-
re-use and
programmability are used to share development cost
− Methodology Requirement:
− Capture system requirements at higher levels of abstraction
− Close interaction between HW/platform definition and the ESW that
that will
run on it
− Platform definition based on understanding of applications that will run on it
− SW design with good caracterisation of the HW
− Solution:
− Need to define a topdown methodology taking a global view on all
interacting aspects of the system

© CoWare, Inc. 1997-2003 CoWare Confidential

3
SoC designs of the future
Application
• Design questions
Application − Algorithm mapping

RTOS
− SW development
Algorithm Algorithm Application
− Custom HW design
ASIP ASIP DSP RISC • IP questions
− Reuse
− Selection
Interconnect network − Configuration
• Architecture
questions
EXT MEM Custom Periph − Optimization
− Exploration

© CoWare, Inc. 1997-2003 CoWare Confidential

Why NoC?
• Shrinking technology Leads to new interconnect strategies
− Benini & de Michele (DATE 2002):
“Delays on wires will dominate:
global wires spanning a significant fraction of the chip size will carry signals whose
propagation delay will exceed the clock period.”
− K. Goossens & Van Meerbergen (DATE 2002):
− “A NOC hardware architecture based on a packet-switched router network … breaks the
fatal global timing closure loop by separating inter-IP from intra-IP communication, and can
so reduce global design iterations.”
• What is NoC?
− Less but ‘programmable’ wires by introducing switches (routers).
− Shared bus: communication bottleneck
− Point to point connection: many under-utilized long wires
− Structured approach to interconnect; wires are either
− short to get on the network,
− router to router.
− Separation of computation (IPs) and communication (NOC)

© CoWare, Inc. 1997-2003 CoWare Confidential

4
Interconnect Trends - today
ARM
ARM
CPU
ASIC
ASIC IP-Core
IP-Core
ASIC IP Core
ASIC
IPCore
ASIC
IP Core Memory
Memory
System on Chip
IPCore
Core Memory
IPIPCore

Traffic Traffic
Contract Contract

?
Bus II
Interconnect
Bridge
Memory
Memory
Memory
ASIP
ASIP
ASIP Structure

Bus I
ASIP
IP Core
IPCore
IP Core
IP Core
Requirements

- connect up to hundred Resources - platform scalability

- I/O requirements GBit/s range - power efficiency
- traffic management / QoS - latency
© CoWare, Inc. 1997-2003 CoWare Confidential

Future SoC Interconnect Challenges

• Physical
− Clock distribution
Mem/
ASIC
− Latency management
IO − Transaction integrity

• Functional
− Traffic management
DSP CPU − Allocation of resources
− Signalization

© CoWare, Inc. 1997-2003 CoWare Confidential

5
 Why ASIPs? The Energy-Flexibility Gap

General ICORE
Purpose Digital 20-35 MOPS/mW
Processors Signal Application

Log P O W E R D I S S I P A T I O N
Processors Specific Signal
Processors
Log F L E X I B I L I T Y

StrongARM110 Field
TMS320C54x
0.4 MIPS/mW Programmable

105 . . . 106
3MIPS/mW
Devices
Application
Specific
ICs
Physically
Optimized
ICs

Log PERFORMANCE

103 . . . 104
Source: T.Noll, RWTH Aachen

11 © CoWare, Inc. 1997-2003 CoWare Confidential

Why ASIPs – technological and economical

Technological
− Power/Energy
Power/Energy Efficient heterogenous Processing Platforms in Mobile
Communication
− Application Specific High Performance Requirements
(Network Processors)
Processors)

Economical
− Simple, but cost-
cost-sensitive Applications
− Cost (No
(No Royalty and licence Fee)
Fee)
− IP Protection and Reuse (IP is about applications )
− Verification
− Time-
Time-to-
to-market,
market, development time reduction
− Flexibility through programmability

© CoWare, Inc. 1997-2003 CoWare Confidential

6
Energy Efficiency – Optimization Example (I)

P(t)

Punopt.
Intrinsic Energy
Overhead Energy
Tunopt.
Runtime

Intrinsic: refers to useful arithmetic operations / data routing

Intrinsic energy nearly scheduling-independent
(serial/parallel processing does not matter)

© CoWare, Inc. 1997-2003 CoWare Confidential

Energy Efficiency – Optimization Example (II)

P(t)
Popt.
Punopt. Intrinsic Energy

Overhead Energy
Topt. Tunopt.
Runtime
Measurement results:
• overhead power nearly constant
• intrinsic energy nearly constant (only scheduling changed)

reduce overhead energy

© CoWare, Inc. 1997-2003 CoWare Confidential

7
Constructive ASIP Design Approach

Start with minimum „basic instruction set architecture“

architecture“ e.g.
e.g. a register-
register-
register RISC architecture:
architecture:

Load/Store
Load/Store read/
read/write memory and I/O
Arithmetic +, -, *, arith.
arith. shift,
shift, abs
Logic and, or,
or, xor,
xor, logical shift
Control compare-
compare-set-
set-status,
status, uncond.
uncond. and
cond branches,
branches, branch to
subroutine,
subroutine, return from
subroutine,
subroutine, stop run

→ apply application-specific optimization („constructive“)

⇒
© CoWare, Inc. 1997-2003 CoWare Confidential

Optimization steps towards “best fit”

• exploit regularity/parallelism in data flow/data storage
- optimize data organization and interfaces
- use appropriate memory and I/O bandwidth

• exploit regularity/parallelism in operation

- chain, parallelize and pipeline operations
- optimize frequently executed blocks like loop bodies
- provide the right degree of parallelism (functional units)
- use only resources that are really needed

• optimized control of computations

- add instructions/control mechanisms to exploit parallel funct. units
- use high instruction coding density
- use low-power guarding techniques and clock gating
- smart low-power encoding techniques to decrease toggle count

© CoWare, Inc. 1997-2003 CoWare Confidential

8
CoWare’s system design vision

C
Create System specification
− Functional description
−
m
Identify IP reuse and platform requirements

e
HW/SW architecture specification, Platform design

t
− Highlevel HW/SW Architecture exploration

s
− ‘Programmers view’ model, to enable SW design and HW/SW

y
trade-offs

S
HW implementation
− Platform and HW refinement, interconnect micro architecture
definition
Technology mapping
− RTL

© CoWare, Inc. 1997-2003 CoWare Confidential

It's time to move up, yet again!

70 70 82 82 88 88 99 99 03

TopDown
System level
Design
n
sig
De
Platform Based Application
Design Platform

RTL RTL
Netlist
Schematic Netlist
at ion
ent
Netlist

lem
Netlist Netlist

Mask Mask I mp
Hardware centric history

© CoWare, Inc. 1997-2003 CoWare Confidential

9
TopDown Design
Peripheral
AHB to Bridge
Addr MuxP2B
Decode APB
Executable specification (UT description) PRDATA
Internal
MuxM2S Memory PWDATA

ARM
Retry Remap
SW
Core
Slave Pause
(+wrapper)

Default Interrupt
Slave Control
MuxS2M

TIC APB FRC

IF Timers
FRC
Arbiter

Reset
Ctrl HW

•Take algorithm and map it to an application •Reuse application platform over many
platform designs
•Ensure HW/SW communication is •Simulation speed suffcient to do
implemented correctly on the platform development of large pieces of SW

© CoWare, Inc. 1997-2003 CoWare Confidential

Transaction level modeling

© CoWare, Inc. 1997-2003 CoWare Confidential

10
Transaction Level Modeling: What Is It?
A Higher Level Of Abstraction For Communication

MEM RISC • RTL: The bus is merely wires

− Each device on the bus has
a pin-
pin-accurate interface
BUS
− Each device interface must
implement the bus protocol
Clk

Periph Req
Sel
Grnt • TLM: The bus model is key
−
Addr
Data
Bus model enforces the bus
protocol
MEM RISC − Each device communicates
via transaction level API
TLM API TLM API − Less code, fewer pins, fewer
BUS events => much faster
TLM API
HREQ ReqTrf
Transaction Grant
HGRANT Trf

Periph HADDR
AddrTrf

HWDATA WriteDataTrf

HREADY EotTrf
HRESP

© CoWare, Inc. 1997-2003 CoWare Confidential

Range of abstraction levels covered by TLM

High Level
protocol

Message

Transaction/Packet
TLM
COMMUNICATION Abstractions
Layers
Transaction

Transfer

Signal RTL
HW Layer

© CoWare, Inc. 1997-2003 CoWare Confidential

11
 IP structure at TLM

Communication versus Behavior

Behavior :
For a complex IP, this is
where the real value is. At
TLM, IP reuse should be
based on behavior reuse.
Boundary :
This is where synchronization
between behavior and Communication:
communication is done TLM is targeted for
communication modelling.
This is where the TLM API
calls are located.

IP
© CoWare, Inc. 1997-2003 CoWare Confidential

Transaction Level Modeling

Performance
Cycles/S
• SW developers and HW
designers/verifiers work
SW

different parts of the

Zo

curve
ne

100K
TLM • Transaction level moves
HW-
HW-SW co-co-design to a
new curve

10K
HW Z
one

Untimed Inst. Acc. Cycle Acc. RTL

Accuracy

TLM allows complex SoC platforms to be simulated accurately

enough for architectural exploration, firmware development
and verification use models
© CoWare, Inc. 1997-2003 CoWare Confidential

12
 Transactions & Transfers
Transaction

Arbitration

HREQ ReqTrf
Grant
HGRANT Trf
Transfer:
HADDR Atomic operation
AddrTrf
HBURST / HWRITE /
HSIZE / HPROT

HWDATA WriteDataTrf

HREADY
EotTrf
HRESP
I2B I2T I2T
B2I T2I
© CoWare, Inc. 1997-2003 CoWare Confidential

Transactions & Transfers

• Transfer
− Groups all attributes (“(“Pins”
Pins”) that have the same
timing
− Represents the relevant events of a transaction
−A transfer can be send when its attributes are allowed to
be driven on the bus, but not later.
−A transfer can be send only once
− Performs uni-
uni-directional data exchange
−Between bus master, bus slave and the bus
− The attributes have the same direction as the
transfer

© CoWare, Inc. 1997-2003 CoWare Confidential

13
 TLM API

All the API are non-blocking

Transactions Transfers Transfer Name Attribute

port.getTransaction() port.getTrfName() ReqTrf ReqMode
GrantTrf
port.canSendTransaction() port.canSendTrfName()
Address
port.canReceiveTrfName() Type
AddrTrf AccessSize
port.sendTransaction() port.sendTrfName() Kind
Group
port.sendDelayedTrfName(delay) BurstWrap
(etc...)

WriteDataTr WriteDat
In bus clock f a
cycles ReadDataTr ReadData
fEotTrf Status

port = TLM port

© CoWare, Inc. 1997-2003 CoWare Confidential

TLM API
• Transfer sensitivity
− allows to query the timing of the bus to find out
when attributes can be send/received
− Prevents the user from violating the bus timing
− Does not force the user to code the timing of the bus in
an FSM in every peripheral
− Provides a generic coding style that allows to re-
re-use
peripherals within a certain class of buses
• All the attributes of the transaction can be
accessed from a transfer
− Prevents unnecessary bookkeeping in every
peripherals in case of pipelined protocols

© CoWare, Inc. 1997-2003 CoWare Confidential

14
 TLM : Bus simulator
Sending and Receiving transfers

GrantTrf ReadDataTrf
Initiator is allowed to Transfers
send a Write Data WriteDataTrf
transfer during this ReqTrf
AddrTrf
time slot

WriteDataTrf

Bus
Initiator Attributes
Target
The bus synchronizes the transfers with the
target according to the timing of the protocol

© CoWare, Inc. 1997-2003 CoWare Confidential

Concepts: Sending a transaction

if (P.getTransaction()) {
P.Transaction->setAddress(0x1000);
P.Transaction->setType(tlmWrite);
Bus model handles
P.Transaction->setWriteData(0x2000);
transaction as if all
P.sendTransaction();
transfers were sent
}
with the correct
timing.

Bus
Initiator
Model

© CoWare, Inc. 1997-2003 CoWare Confidential

15
 Concepts: Sending/Receiving transfers

HADDR
AddrTrf
HBURST / HTRANS
HSIZE / HPROT /HWRITE

// Initiator can send transfer

// Target can receive transfer
if (P.getAddrTrf()) {
if (P.getAddrTrf()) {
P.AddrTrf->setAddress(1234); addr = P.AddrTrf->getAdress();
P.AddrTrf->setType(tlmWrite); ftype = P.AddrTrf->getType();
}
P.sendAddrTrf();
}

Initiator Target

© CoWare, Inc. 1997-2003 CoWare Confidential

TLM process
A systemC process can be sensitive to a transfer event.
The bus simulator will trigger this process whenever an action
from the initiator or the target is allowed.
¾ Send or receive transfer

SC_MODULE (MyModule)
Static sensitivity
TLMTargetPort port;
void send_address(){
…
}
SC_CTOR(MyModule) {
SC_METHOD(send_address);
Sensitive << port.getSendAddressTrfEventFinder();
}
}
© CoWare, Inc. 1997-2003 CoWare Confidential

16
Target : Write transaction, 0 wait, Ok response (2)
Coding style: static sensitivity to transfer
(Equivalent to previous example)
SC_METHOD(receiveWriteData);
sensitive << p_bus.getReceiveWriteDataTrfEventFinder();
dont_initialize();

SC_METHOD(sendEoT);
sensitive << p_bus.getSendEotTrfEventFinder(); Either one can be used in
dont_initialize(); case of sensitivity to the
specific transfer
void receiveWriteData() {
P1.getWriteDataTrf();
P1.getWriteDataTrf();
myVar
myVar= =P1.WriteDataTrf->getWriteData();
P1.WriteDataTrf->getWriteData();
}

void sendEotTrf() {
P1.sendEotTrf(); myVar = P1.getWriteDataTrf()->getWriteData();
}

© CoWare, Inc. 1997-2003 CoWare Confidential

Target : Write transaction, 0 wait, Ok response (3)

Provides access to
the address transfer
void receiveWriteData() {
and its attributes
P1.getWriteDataTrf();
myArray[P1.WriteDataTrf->getAddrTrf()->getAddress()] =
P1.WriteDataTrf->getWriteData();
}

void sendEot () {
P1.sendEotTrf();
}

….Address
Address Address The bus simulator provides a link
between a transfer and its transaction.
Write Write ….Transaction
Data Data

© CoWare, Inc. 1997-2003 CoWare Confidential

17
Transactional Bus Simulator
AHB_I Inputstage
Outputstage
AHB

ARM926EJS
AHB2 Internal

• A complete off-
off-the-
the- Inputstage1
ROM

shelf solution AHB_D

• Fully models the AMBA

IRQ SMI_external
memory
Internal
FIQ
2.0 bus specification at
RAM

the transaction-
transaction-level AHB

• Innovative CoWare
Inputstage2 Outputstage2
APB Display
AHB_sl Ctrl

technology optimizes AHB_m1 Inputstage4

APB_cfg

performance while DMA

Ctrl AHB_m2 INT_displ

retaining cycle Inputstage3

Outputstage1
APB
Input

accuracy
DMA_Int
device
INT_inp
Interrupt
Ctrl

• Fully SystemC 2.0 Clk and rst

compliant
Transactional Bus Simulators

© CoWare, Inc. 1997-2003 CoWare Confidential

CoWare tools

© CoWare, Inc. 1997-2003 CoWare Confidential

18
 ConergenSC product family: Platform Creator

System Workspace

© CoWare, Inc. 1997-2003 CoWare Confidential

Platform Creator Usage – Platform-

Platform-based Design
Platform-based
3. Connect
elements with
Connection Tool

System Workspace
4. Select blocks and
nodes to set
2. Drag and drop memory map and
blocks and bus other parameters
nodes from the IP
libraries into the
Design Editor
window. The block
appears in your
Workspace
5. Export system
design
(Tools menu)
1. Open IP libraries

© CoWare, Inc. 1997-2003 CoWare Confidential

19
 Platform Creator Usage – Top -down Design
Top-down

5. Partition
the HW and
1. New Workspace SW blocks

2. Open 6. Resolve the

Scenario abstract
Library channels

3. Open 7. Set the

TLM memory map
Platform and parameters

4. Open UT
specification Double-click 8. Export the
(application) here to view the system
SW blocks

© CoWare, Inc. 1997-2003 CoWare Confidential

System-Level Analysis
System-Level
ConvergenSC System Designer
• Superior Hardware, Software,
Memory, and Bus Analysis for
Cache Hits/Misses SystemC
SW Task Gantt
− Which masters and slaves should be on
which bus layer?
− Is the cache the right size?
− How much memory is needed?
• Comprehensive APIs
Memory Reads/Writes
− Fully customizable data collection and
display
− Fully accessible to designer

Transaction Counts Enables

Enables the
the Right
Right System
System
Architecture,
Architecture, Performance,
Performance, and
and
Embedded
Embedded SW SW Trade-offs
Trade-offs Sooner
Sooner
Bus Contention

© CoWare, Inc. 1997-2003 CoWare Confidential

20
Mixed Language SystemC-HDL Simulation
SystemC-HDL
• Use Verilog and VHDL models
− To verify implementation
− For legacy IP re-
re-use
• ConvergenSC supports the
following simulators:
simulators:
− Cadence NC-
NC-Sim
− Synopsys VCS
− MTI modelsim
• Capabilities:
− Automated SystemC-
SystemC-HDL
executable generation
− Fast, single process
simulation
− Multiple HDL blocks
− Mixed HDL language (if
supported by HDL sim.)
sim.)

© CoWare, Inc. 1997-2003 CoWare Confidential

LISATEK product family

• Flexible platforms…include more processors
• Embedded FPGA to allow customers to extend processor
instruction set
• LISATek offers a complete Application

design flow for ASIPs

prog
pipeline control
seq

LISATek CCCompiler
Compiler

− Allows existing designers to

regs

IF/ID ID/EX EX/WB

Assembler
Assembler&&
prog data
Assembler
Assembler
Linker
mem mem

Linker
Processor
LISA 2.0 Description Designer Linker
Simulator
Linker
automate processor development
Simulator

− Creates ISS, C Compiler and S/W

Simulator
Simulator

No
development tools Design goals

− Synthesises RTL from processor

met ?
Yes

description RTL
RTLGeneration
Generation Architecture & Application Profiling

• ConvergenSC offers the best Software

Tools
RTL
Implementation

solution for designing platform

© CoWare, Inc. 1997-2003 CoWare Confidential

21
LISA 2.0 – Instruction Set Modelling
• Design complex instruction sets
• Integrated design environment (GUI)
Instruction
InstructionSet
Set
• Hierarchical description style VLIW
• Instruction (binary) encoding Multi - Word
− Arbitrary bitwidth and format Parallel Instructions

• Instruction (assembly) syntax

CC//C++
C++Behavior
Behavior
• Hardware Behavior
− Pure C or C++ code
− Integration of existing libraries
− Additional data-
data-types ease modeling

© CoWare, Inc. 1997-2003 CoWare Confidential

Integrated Simulator-Debugger-Profiler
Simulator-Debugger-Profiler
•Immediately explore the architecture prototype

Source-code
Source-code&&
Disassembly
Disassembly
Model
Model
Debugging
Debugging

Loop
Loop&&
Instruction
Instruction
Profiler Unit
Unit&&
Command- Profiler
Command- Resource
Resource
line
linecontrol
control Utilization
Utilization

Tracing
Tracing
Memories
Memories&&
Registers
Registers

© CoWare, Inc. 1997-2003 CoWare Confidential

22
Debugger Coverage
Coverage

Source
SourceProfiling
Profiling C/C++
C/C++Variables
Variables

Backtrace
Backtrace

GDB
GDBCommand
CommandLine
Line

© CoWare, Inc. 1997-2003 CoWare Confidential

CoSy compiler system (ACE)

• Universal retargetable
C/C++ compiler
• Extensible intermediate
representation (IR)
• Modular compiler
organization
• Generator (BEG) for code
selector, register allocator,
allocator,
scheduler © ACE - Associated
• Permits building working Compiler Experts

compilers quickly

© CoWare, Inc. 1997-2003 CoWare Confidential

23
 C -Compiler GUI approach
C-Compiler
• Analysis tools extract as
much compiler information as
possible from LISA model
(e.g. instruction latencies,
latencies,
registers,
registers, ASM syntax)
syntax)
• GUI guided extension and
refinement by user (e.g. code
selection,
selection, stack layout, type
bitwidths)
bitwidths)
• Emission of compiler
description file

© CoWare, Inc. 1997-2003 CoWare Confidential

RTL generation GUI

© CoWare, Inc. 1997-2003 CoWare Confidential

24
 CoWare ESL Solution Flow
Algorithm System IP
Vertical
System Algorithms Apps. ConvergenSC Periphs & Bus Processor
Mem IP Specs Specs
Functional Libraries System Designer
Validation System Verifier Vendor
PSPs Bus
Bus Compiler
Architectural
Validation
SPW ConvergenSC
Models LISATek
Platform Creator Processor
LISATek
PSPs Designer

Refinement C Compiler
& Verification Verification
HDS HW Impl.
(Incisive etc.) Option ESP ISS & S/W tools

Implementation RTL2GDSII SW

© CoWare, Inc. 1997-2003 CoWare Confidential

25