Soc Design Methodology Soc Design Methodology

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
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
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
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
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
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)
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
Future SoC Interconnect Challenges

• Physical
− Clock distribution
Mem/
ASIC
− Latency management
IO − Transaction integrity
• Functional
− Traffic management
DSP CPU − Allocation of resources
− Signalization
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
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)
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

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“)

⇒
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
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
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
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
Transaction level modeling
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
Range of abstraction levels covered by TLM
High Level
protocol
Message
Transaction/Packet
TLM
COMMUNICATION Abstractions
Layers
Transaction
Transfer
Signal RTL
HW Layer
11
IP structure at TLM
Communication versus Behavior
Boundary :
This is where synchronization
Behavior : between behavior and Communication:
communication is done TLM is targeted for
For a complex IP, this is
where the real value is. At communication modelling.
TLM, IP reuse should be This is where the TLM API
based on behavior reuse. calls are located.
IP
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
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
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
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

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
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
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
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
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();
}
}
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();
myVar
myVar= =P1.WriteDataTrf->getWriteData();
P1.WriteDataTrf->getWriteData();
}
void sendEotTrf() {
P1.sendEotTrf(); myVar = P1.getWriteDataTrf()->getWriteData();
}
Target : Write transaction, 0 wait, Ok response (3)

Provides access to
the address transfer
void receiveWriteData() {
and its attributes
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
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 tools
18
ConergenSC product family: Platform Creator
System Workspace
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
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
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
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.)
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

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
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
22
Debugger Coverage
Coverage
Source
SourceProfiling
Profiling C/C++
C/C++Variables
Variables
Backtrace
Backtrace
GDB
GDBCommand
CommandLine
Line
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
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
RTL generation GUI
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
25

Soc Design Methodology Soc Design Methodology

Uploaded by

Copyright:

Available Formats

Soc Design Methodology Soc Design Methodology

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Soc Design Methodology Soc Design Methodology

Uploaded by

Copyright:

Available Formats

SoC design methodology

© CoWare, Inc. 1997-2003 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

Software effort Architecture effort

Source: IBS, November 2002 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

- connect up to hundred Resources - platform scalability

Future SoC Interconnect Challenges

© CoWare, Inc. 1997-2003 CoWare Confidential

11 © CoWare, Inc. 1997-2003 CoWare Confidential

Why ASIPs – technological and economical

© CoWare, Inc. 1997-2003 CoWare Confidential

Intrinsic: refers to useful arithmetic operations / data routing

© CoWare, Inc. 1997-2003 CoWare Confidential

Energy Efficiency – Optimization Example (II)

reduce overhead energy

Start with minimum „basic instruction set architecture“

→ apply application-specific optimization („constructive“)

Optimization steps towards “best fit”

• exploit regularity/parallelism in operation

• optimized control of computations

© CoWare, Inc. 1997-2003 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

It's time to move up, yet again!

© CoWare, Inc. 1997-2003 CoWare Confidential

TIC APB FRC

© CoWare, Inc. 1997-2003 CoWare Confidential

Transaction level modeling

© CoWare, Inc. 1997-2003 CoWare Confidential

MEM RISC • RTL: The bus is merely wires

© CoWare, Inc. 1997-2003 CoWare Confidential

Range of abstraction levels covered by TLM

© CoWare, Inc. 1997-2003 CoWare Confidential

Communication versus Behavior

Transaction Level Modeling

different parts of the

Untimed Inst. Acc. Cycle Acc. RTL

TLM allows complex SoC platforms to be simulated accurately

Transactions & Transfers

© CoWare, Inc. 1997-2003 CoWare Confidential

All the API are non-blocking

Transactions Transfers Transfer Name Attribute

port = TLM port

© CoWare, Inc. 1997-2003 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

Concepts: Sending a transaction

© CoWare, Inc. 1997-2003 CoWare Confidential

// Initiator can send transfer

© CoWare, Inc. 1997-2003 CoWare Confidential

© CoWare, Inc. 1997-2003 CoWare Confidential

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

© CoWare, Inc. 1997-2003 CoWare Confidential

shelf solution AHB_D

• Fully models the AMBA

technology optimizes AHB_m1 Inputstage4