Ee382V-Ics: System-On-A-Chip (Soc) Design

EE382V-ICS: System-on-Chip (SoC) Lecture 8
Design
EE382V-ICS:
System-on-a-Chip (SoC) Design
Lecture 8 - System Design Methodology
with sources from:

Christian Haubelt, Univ. of Erlangen-Nuremberg
Andreas Gerstlauer
Electrical and Computer Engineering
University of Texas at Austin
gerstl@ece.utexas.edu
SoC Design Flow

Start Analyze results
MRD
Functionality No
Met?
No
PRD
Modify Yes
Product Model? Yes
Map, Model &
Validation Simulate in
Loop
SPW or Matlab or C System No
or C++ BOM Costs
Met?
Yes
Mapping to
No Platform or
Components Power No
Complete? Req. Met?
Design Yes
Convergence and
Yes
Analyze results
Verification Schedule
Loop
No
Req. Met?
No Metrics
Met?
Yes
Yes
Platform No
Freeze
Req. Met?
Architecture
Yes
No MRD
Met?
Return
Yes
EE382V-ICS: SoC Design, Lecture 8 Done © 2010 A. Gerstlauer 2
© 2010 A. Gerstlauer 1
Design
Design Convergence
Front
Front End
End Design
Design Implementation
Implementation
Reduced convergence time due to minimal data
Convergence time increases due to more design data
# Optimization Solutions
Reduced convergence time due to reduced solution space
Convergence time increases due to transition phase
Reduced convergence time due to reduced solution space
Design Converges
Rapid Exploration Rapid Traversal
EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 3
Design Challenges
• Complexity
• High degree of parallelism at Applications
various levels
• Heterogeneity Programming
• Of components Model?
• Of tools
• Low-level communication
mechanisms
• Programming model
Source: C. Haubelt, Univ. of Erlangen-Nuremberg
Design
Complexity Forces
Functionality
Cost Compatibility
Capacity Security
Availability Reliability
Performance Throughput
Technology churn Robustness
“The challenge over the next 20 years will not be speed or cost or
performance; it will be a question of complexity.”
Bill Raduchel, Chief Strategy Officer, Sun Microsystems
Multi-Processor System-on-Chip (MPSoC)
System Memory Micro-

ASIP Local RAM
Memory Controller Controller
Controller Bus
Hardware
DSP DSP RAM
Accelerator
Bridge DSP Bus
Shared Hardware Video

RAM Accelerator Front End
Local Bus
Source: C. Haubelt, Univ. of Erlangen-Nuremberg
Design
MPSoC Terminology
• Multi-processor
• Heterogeneous, asymmetric multi-processing (AMP)
• Distributed memory and operating system
• Multi-core
• Homogeneous, symmetric multi-processing (SMP)
• Shared memory and operating system
 Multi-core processors in a multi-processor system
• Many-core
• > 10 cores per processor…
Processor Implementation Options
Source: T. Noll, RWTH Aachen, via R. Leupers, “From ASIP to MPSoC”, Computer Engineering Colloquium, TU Delft, 2006
Design
Lecture 8: Outline
 Introduction
• System design methodology

• Electronic system-level design (ESL/SLD)
• ESL design
• Modeling
• Synthesis
• Verification
• ESL landscape
• Summary and conclusions
System Design
System-level design
Hardware Software
development development
Integration &
Verification
Design
Classical System Design Flow

System requirement specification
system design
System architecture design
Modeling
Hardware design
hardware software
Software development
Integration & Verification
integration &
System
verification
manual (semi)automatic
Hardware-Centric Design Cycle
Task
Specification Fixes in specification
HW design Fixes in hardware
HW verification
SW design Fixes in software
SW verification
Integration & verification
Time
Design
Hardware-Centric Design Cycle

but you want to know here
… and here
Task … and here
Specification Fixes in specification

✘
✘
HW verification

✘
SW verification

✘
Time
known if project is successful
Electronic System-Level (ESL) Design Flow

System requirement specification
system design
High-level model
System-level design
Hardware design Software development
hardware software
Integration & Verification
integration &
System implementation
verification
manual (semi)automatic
Design
New ESL Design Cycle
Task
Specification
(high-level & arch. models) Fixes in specification
HW verification
SW verification
Time
Find good design options here
Double Roof Model

Software Hardware
system
Specification
task component
instruction logic
architecture
ISA RTL
Arch Implementation gate
Source: A. Gerstlauer, C. Haubelt, A. Pimentel, et al., “Electronic System-Level Synthesis Methodologies,“ TCAD, 2009.
Design
Design Methodologies
 Set of models and design steps (transformations)
• Top down design • Platform based design
• Starts with functional system • Starts with architecting a
specification processing platform for a given
– Application behavior vertical application space
– Models of Computation (MoC) – Semiconductor, ASSP vendors
• Successive refinement • Enables rapid creation and
• Connect the hardware and verification of sophisticated SoC
software design teams earlier in designs variants
the design cycle. • PBD uses predictable and pre-
• Allows hardware and software to verified firm and hard blocks
be developed concurrently • PBD reduces overall time-to-
• Goes through architectural market
mapping – Shorten verification time
• The hardware and software parts • Provides higher productivity
are either manually coded or through design reuse
obtained by refinement from • PBD allows derivative designs
higher model with added functionality
• Ends with HW-SW co-verification • Allows the user to focus on the
and System Integration part that differentiate his design
Source: Coware, Inc., 2005
Top-Down ESL Design Environment
Primarily Primarily
Virtual
PROTOTYPING ENVIRONMENT Physical
HW HW
DESIGN FAB
System Function INTEG.
SL
Def. Design & TEST
Design
SW SW
HW & SW
DESIGN CODING
CODESIGN
Cost Models
Copyright © 1995-1999 SCRA Used with Permission
Design
Platform-Based Design (PBD)

Performance models:
Models of Emb. SW, Comm.
Computation and Comp. resources
System System
Behavior Platform
Model Checking
HW/SW Partitioning,
Behavior Scheduling & Estimation
Mapping
Verification
Performance Architecture
Analysis
and Simulation
Refinement
Synthesis
Flow To Implementation
& Coding
Source: UC Berkeley, EECS249
System Design Languages
• Netlists
• Structure only: components and connectivity
 Gate-level [EDIF], system-level [SPIRIT/XML]
• Hardware description languages (HDLs)
• Event-driven behavior: signals/wires, clocks
• Register-transfer level (RTL): boolean logic
 Discrete event [VHDL, Verilog]
• System-level design languages (SLDLs)
• Software behavior: sequential functionality/programs
 C-based [SpecC, SystemC, SystemVerilog]
Design
Lecture 8: Outline
 Introduction
 System design flow
• ESL design
• Modeling
• Synthesis
• Verification
• ESL landscape
System Modeling
• Design models as abstraction of a design instance

• Representation for validation and analysis
• Specification for further implementation
 Documentation & specification
 Systematic modeling flow and methodology

• Set of models
• Set of design steps
 From specification to implementation
 Well-defined, rigorous system-level semantics

• Unambiguous, explicit abstractions, models
– Objects and composition rules
 Synthesis and verification
Design
Modeling Guidelines
• A model should capture exactly the aspects required by

the system, and no more.
• There is not one model/algorithm/tool that fits all.
• Being formal is a prerequisite for algorithmic analysis.

• Formality means having a mathematical definition
(semantics) for the properties of interest.
• Being compositional is a prerequisite for scalability.

• Compositionality is the ability of breaking a task about A||B
into two subtasks about A and B, respectively.
Separation of Concerns
Managing
Complexity
Orthogonalizing
concerns
Behavior across Computation
Vs. multiple levels Vs.
Architecture of Communication
abstraction
Design
System Design Flow

• Abstraction based on level of detail & granularity
• Computation and communication
 System design flow
 Path from model A to model F
Cycle-
timed D F
Communication
A. System specification model

B. Timed functional model
Approximate- C. Transaction-level model (TLM)
timed C E D. Bus cycle-accurate model (BCAM)
E. Computation cycle-accurate model (CCAM)
F. Cycle-accurate model (CAM)
Un-
timed
A B
Un- Approximate- Cycle- Computation
timed timed timed
Source: L. Cai, D. Gajski. “Transaction level modeling: An overview”, ISSS 2003
Computation vs. Communication

• Separation of concerns
• Flexibility in modeling
• IP reuse
Bus Model Device Model

Communication Computation
Must be synchronized
get a;
get b; c = a * b;
send c;
Communication can be described in a Behavior can be described

wide range of fashions, from high-level algorithmically, without the burden of
messages, to detailed signal level the handshaking and control logic
handshakes without impacting the associated with bus communication.
behavior description. Source: Coware, Inc., 2005
Design
Computation Models
Process B1()
{
• Application model
…
waitfor(15000); • Model of Computation (MoC)
… – Process-/state-based [KPN, SDF, FSM, …]
waitfor(25000);
};
…
• Back-annotated execution timing
– Timing granularity (basic block level)
• Processor model
CPU
• Operating system
B1 B2 – Real-time multi-tasking (RTOS), drivers
OS • Hardware abstraction layer (HAL)

HAL Drv ISR – Media accesses
• Processor hardware
– Bus I/O & interrupts
Bus • Instruction-set model

• Instruction-set or micro-architecture
Interrupts
– Down to cycle-accurate behavior
Communication Models
• Pin-Accurate Model (PAM)
MEM CPU • Redundant RTL complexity
results in slow simulation
• Each device interface must
BUS
Pin/Cycle implement the bus protocol
Accurate
• Each device on the bus has a
pin-accurate interface
Clk
Periph Req
Sel
Grnt
Addr
• Transaction-Level Model (TLM)
Data
• Less code, no wires, fewer
events yield faster simulation
• Protocol is modeled as a
single bus model instead of in
each device
MEM CPU • Each device communicates
via transaction-level API
TLM API TLM API Transactions  100x-10,000x faster than
BUS (Function Calls) PAM
TLM API
HREQ
Transaction
ReqTrf
Grant
HGRANT Trf
Periph HADDR
AddrTrf
HWDATA WriteDataTrf
HREADY EotTrf
HRESP Source: Coware, Inc., 2005
Design
Transaction Level Modeling
Initiator Communication Target

channel
TLM read(addr) read(addr) TLM

write(addr, data) write(addr, data)
API API
The transaction level is a higher level of abstraction for

communication
For SoC, communication is often the bottleneck
TLM Details
• Abstracted communication
• Detailed signal handshaking is reduced to series of
generic events called “transactions”.
• Blocks are interconnected via a bus model, and
communicate through an API.
• The bus model handles all the timing, and events on the
bus can be used to trigger action in the peripherals.
Event timing can
Bus
trigger actions.
Initiator addressEvent() Model dataEvent() Target
Address Data
sendAddress() sendData()
Bus Model keeps Initiator and target use

track of timing. an API to communicate
via transfers.
Design
SystemC/TLM 2.0
• Pointer to transaction object is passed from module to
module using forward and backward paths
• Transactions are of generic payload type
Forward path Interconnect Forward path

Initiator Initiator/ Target
Target
Backward path Backward path
Command
Address
Data
Byte enables
Response status
Extensions
Source: OSCI TLM-2.0
SystemC/TLM 2.0 Coding Styles

• Loosely-timed BEGIN
• Sufficient timing detail to boot OS and
simulate multi-core systems END
• Each transaction has 2 timing points:
begin (call) and end (return) Initiator Target
• Approximately-timed BEGIN_REQ
• Cycle-approximate or cycle-count- END_REQ
accurate
• Sufficient for architectural exploration BEGIN_RESP
• Each transaction has at least END_RESP
4 timing points
Initiator Target
Design
Blocking and Non-Blocking Transports
• Blocking transport interface

• Typically used with loosely-timed coding style
• tlm_blocking_transport_if
void b_transport(TRANS&, sc_time&);
• Non-blocking transport interface

• Typically used with approximately-timed coding style
• Includes transaction phases
• tlm_fw_nonblocking_transport_if
tlm_sync_enum nb_transport_fw(TRANS&, PHASE&, sc_time&);
• tlm_bw_nonblocking_transport_if
tlm_sync_enum nb_transport_bw(TRANS&, PHASE&, sc_time&);
Blocking Transport
Initiator Target
Simulation time
0ns
call b_transport(t, 0ns);
b_transport(t, 0ns); return

Simulation time
0ns
call b_transport(t, 0ns);
Simulation time
wait(30ns);
30ns
b_transport(t, 0ns); return
Design
Non-Blocking Transport
Initiator Target
nb_transport(-, BEGIN_REQ, 0ns);
nb_transport(TLM_ACCEPTED, -, -);
nb_transport(-, END_REQ, 0ns);
nb_transport(-, BEGIN_RESP, 0ns);
nb_transport(-, END_RESP, 0ns);
Virtual Platform Prototyping
Computation refinement
Untimed TLM (LT/AT) PCAM
Virtual Prototype
Communication refinement
Design
Abstraction Levels
Functional Validation Processor Interconnect Peripheral
Increasing Scope for Relative Optimization

Emb.
Emb.System
SystemModeling
Modeling Host-
Host-compiled Not Modeled
-Executable
-Executablespec.
spec.capture
capture -Point to point
-Functional
-Functionaltesting
testing -Memory-
Memory-mapped
Increasing Simulation Performance

Instruction Loosely Timed
Architectural Validation Accurate TLM Untimed
System
SystemPartitioning
Partitioningand
and
Assembly
Assembly
-Exploration
-Explorationand
andanalysis
analysis
Approximately Timed
Hardware Refinement Timed TLM Bus-
Bus-Functional
Cycle
RTL
RTLDesign
Design&&Verification
Verification Accurate Cycle-
-Block
-Blockdesign
designandandunit
unittest
test Cycle-Accurate
-Validation
-Validationininthe
thesystem
RTL TF
system TLM
(Transfer Level)
(DUT) (rest)
RTL Verification
System-
System -level Verification
System-level Verification
-Complete RTL RTL
-Completedesign
designatatRTL
RTL
-System-
System -level testbench
-System-level testbench RTL
Speed vs. Accuracy
UT
ESL
Host-based
Architectural
IA ISS Design LT
10MIPS TLM Bus 3 Mcps
SystemC
Executable TLM
Re-use for
1MIPS Early
Software
Cycle
Development CA
Accurate
Log S P E E D
100Kcps -TLM 150 kps
10Kcps Re-use for Pin-accurate PAM+RTL

System-level w/RTL 15 kps
Hardware
1Kcps Verification
RTL
100cps
Log A C C U R A C Y
Design
Lecture 8: Outline
 Introduction
 System design methodology
• ESL design
 Modeling
• Synthesis
• Verification
• ESL landscape
Design Automation
• Synthesis = Decision making + model refinement
GUI Specification
GUI Specificationmodel
model
Model n
Model n
Optim.
Optim.algorithm
algorithm
Refinement DB
Design decisions Refinement DB
Model
Modeln+1
n+1
Implementation model
Implementation model
 Successive, stepwise model refinement

 Layers of implementation detail
Design
X-Chart
Application Platform
Behavior Constraints
Synthesis
Decision
Refinement
making
Quality
Structure
numbers Latency, Area,
Transaction
Level Model Throuput, etc
Platform-Based System Synthesis
Application Platform
Optimal Mapping ?
Design
Resource Allocation
• Resource allocation, i.e., select resources from a
platform for implementing the application
Process Binding
• Process mapping, i.e., bind processes onto allocated
computational resources
Design
Channel Routing
• Channel mapping, i.e., assign channels to paths over
busses and address spaces
Design Space Exploration

• Design Space Exploration is an iterative process:
• How can a single design point be evaluated?
• How can the design space be covered during the
exploration process?
Evaluating Covering the

design points design space
Design
Optimization Approaches
• Exact methods
• Enumeration, (Integer) Linear Programs
• Heuristics
• Constructive
– Random mapping, hierarchical clustering
• Iterative
– Random search, simulated annealing, min-cut (Kernighan-Lin)
• Set-based (“intelligent” randomized search)
– Evolutionary Algorithms (EA),
Particle Swarm Optimization (PSO),
Ant Colony Optimization (ACO)
 Exact, constructive & iterative methods are prohibitive

 Large design space, multiple objectives, dynamic behavior
 Set-based approaches
 Randomized, problem independent (black box), Pareto set
Evaluation Approaches
• Dynamic simulation
• Profiling, ISS/RTL co-simulation
 Long simulation times, corner cases
• Static analysis
• Component-level estimation
[Worst-Case Execution Time (WCET)]
• System-level cost functions, real-time calculus
[Modular Performance Analysis (MPA)]
 Inaccurate bounds, manual interference (false paths)
 Combinations
• Host-compiled simulation
• Trace-driven simulation
 Tradeoff between accuracy and speed
Design
Lecture 8: Outline
 Introduction
• ESL design
 Modeling
 Synthesis
• Verification
• ESL landscape
Design Verification Methods
• Simulation based methods

• Specify input test vector, output test vector pair
• Run simulation and compare output against expected
output
• Formal Methods
• Check equivalence of design models or parts of models
• Check specified properties on models
• Semi-formal Methods
• Specify inputs and outputs as symbolic expressions
• Check simulation output against expected expression
Design
Simulation
• Create test vectors and simulate model
• Simulation, debugging and visualization tools
[Synopsys VCS, Mentor ModelSim, Cadence NC-Sim]
Specification
Stimulus
Monitors
DUT
• Inputs
• Specification
– Used to create interesting stimuli and monitors
• Model of DUT
– Typically written in HDL or C or both
• Output
• Failed test vectors
– Pointed out in different design representations by debugging tools
Equivalence Checking
• LEC uses boolean algebra to check for logic equivalence
outputs
inputs
1
2
1 = 1’ ? Equivalence
2 = 2’ ? result
outputs
inputs
1’
2’
• SEC uses FSMs to check for sequential equivalence

x r xy
x p xx pr ps pt xy
a
a × y s = aa
y q b b b yx qr
bb
qt yy
qs
y t yy bb
Design
Model Checking
• Model M satisfies property P? [Clarke, Emerson ’81]
• Inputs
• State transition system representation of M
• Temporal property P as formula of state properties
• Output
• True (property holds)
• False + counter-example (property does not hold)
P1 P2 P = P2 always leads to P4
s1 s2
s4 s3 Model True /
P4 P3 Checker False + counter-example
M
Lecture 8: Outline
 Introduction
 ESL design
• ESL landscape
• Commercial tools
• Academic tools
Design
Electronic System-Level (ESL) Landscape

CPU Mem
B1 B2 v1
Computation &
MARTE (UML) Communication
SPIRIT/IP-XACT Matlab/Simulink,
C2
Arbiter
Bridge
C1
(XML) LabView, …
B3 B4
HW IP
System
SystemSynthesis
Synthesis
Platform library Front-End
Front-End Application specification
Academic Tools
System-Level Design Languages (SLDLs)
VaST, OVP Simulator (ISS) Transaction-Level Models SystemC,

Instruction-Set
C-based RTL
Virtutech,… CoWare, …
TLM
TLM
TLM
TLMn
C/C++ code
Software
Software//Hardware
Hardware
Green Hills, Mentor Catapult,
Synthesis
Synthesis
gcc, VxWorks, … Forte, …
Back-End
Back-End
Tensilica
Software Synopsys Design

Hardware
Object Code Compiler, …
VHDL/Verilog
ESL Tools
• Electronic System-Level (ESL) terminology
• Often single hardware unit only
– C-to-RTL high-level synthesis (HLS) [Mentor Catapult, Forte Cynthesizer]
• System-level across hardware and software boundaries

• System-level frontend
• Hardware and software synthesis backend
 Commercial tools for modeling and simulation

• Algorithmic modeling (MoC) [UML, Matlab/Simulink, Labview]
• Virtual system prototyping (TLM) [Coware, VaST, Virtutech]
 Only horizontal integration across models / components
 Academic tools for synthesis and verification
• MPSoC synthesis [SCE, Metropolis, SCD, PeaCE, Deadalus]
 Vertical integration for path to implementation
Design
Academic MPSoC Design Tools
Approach DSE Comp. Comm. Comp. Comm.

decision decision refine refine
Daedalus ∙ ∙ ∘ ∙ ∘
Koski ∙ ∙ ∘ ∙ ∘
Metropolis ∘ ∘
PeaCE/HoPES ∘ ∘ ∙ ∘
SCE ∙ ∙
SystemCoDesigner ∙ ∙ ∙ ∘
System Design Flow Summary

Embedded System Requirements
Platform Platform
Functional
Function Architecture Architecture
Platform
IP IP Configuration
C/C++ CPU/DSP
… at the
SDL System Integration RTOS un-clocked, timing-
SPW Bus, Memory aware
Simulink HW system level
SW
Performance Analysis and
Platform Configuration
Communication Design Export

Refinement, Integration & … after initial platform
Synthesis configuration through
design refinement and
communication synthesis
Hardware Software
Assembly Assembly
Implementation Level Verification
Synthesis / Place & Route etc.

Ee382V-Ics: System-On-A-Chip (Soc) Design

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

Ee382V-Ics: System-On-A-Chip (Soc) Design

Uploaded by

Copyright:

Available Formats

EE382V-ICS: System-on-Chip (SoC) Lecture 8

Lecture 8 - System Design Methodology

with sources from:

SoC Design Flow

Reduced convergence time due to reduced solution space

Convergence time increases due to transition phase

Reduced convergence time due to reduced solution space

Rapid Exploration Rapid Traversal

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 3

Source: C. Haubelt, Univ. of Erlangen-Nuremberg

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 4

Technology churn Robustness

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 5

Multi-Processor System-on-Chip (MPSoC)

System Memory Micro-

Bridge DSP Bus

Shared Hardware Video

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 6

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 7

Processor Implementation Options

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 8

• System design methodology

• Summary and conclusions

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 9

Classical System Design Flow

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 11

Hardware-Centric Design Cycle

Specification Fixes in specification

HW design Fixes in hardware

SW design Fixes in software

Integration & verification

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 12

Hardware-Centric Design Cycle

Specification Fixes in specification

SW design Fixes in software

Integration & verification

known if project is successful

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 13

Electronic System-Level (ESL) Design Flow

Hardware design Software development

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 14

New ESL Design Cycle

HW design Fixes in hardware

SW design Fixes in software

Integration & verification

Find good design options here

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 15

Double Roof Model

Arch Implementation gate

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 16

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 17

Top-Down ESL Design Environment

Copyright © 1995-1999 SCRA Used with Permission

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 18

Platform-Based Design (PBD)

Source: UC Berkeley, EECS249

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 19

System Design Languages

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 20

 System design flow

• Summary and conclusions

EE382V-ICS: SoC Design, Lecture 8 © 2010 A. Gerstlauer 21

• Design models as abstraction of a design instance