ee382v: system-on-a-chip (soc)...
TRANSCRIPT
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 1
EE382V:System-on-a-Chip (SoC) Design
Andreas GerstlauerElectrical and Computer Engineering
University of Texas at [email protected]
Lecture 6 – Electronic System-Level (ESL) Design
with sources from:Christian Haubelt, Univ. of Erlangen-Nuremberg
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 2
SoC Design Challenges
Applications
ProgrammingModel?
• Complexity
• High degree of parallelism atvarious levels
• Heterogeneity
• Of components
• Of tools
• Low-level communicationmechanisms
• Programming model
Source: C. Haubelt, Univ. of Erlangen-Nuremberg
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 2
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 3
Multi-Processor System-on-Chip (MPSoC)
Controller Bus
SystemMemory
Local Bus
Local RAM
Bridge
SharedRAM
DSP Bus
DSP RAM
MemoryController ASIP
DSP
HardwareAccelerator
Micro-Controller
HardwareAccelerator
VideoFront End
Source: C. Haubelt, Univ. of Erlangen-Nuremberg
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 4
Lecture 6: Outline
Introduction
• System design methodology
• Electronic system-level design (ESL/SLD)
• System-level design
• Synthesis
• Modeling
• Summary and conclusions
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 3
Algorithmic DesignAlgorithmic Design
System/MarketingRequirements
System/MarketingRequirements
Architectural DesignArchitectural Design
System Bring-upPrototyping
System Bring-upPrototyping
Final AssemblyFinal Assembly
HW Design
CaptureCapture
VerificationVerification
ImplementationImplementation
SW Design
CaptureCapture
VerificationVerification
• RTL language centric• Dysfunctional levels of abstraction• SW Design Cycle often serial to
HW Design Cycle• Lack of unified hardware-software
representation• Missing executable platform
models early in cycle• SW/HW integration is tough• Simulation speed is critical• Partitions are defined a priori
• Hard to find incompatibilities across HW-SW boundary
• Lack of well-defined design flow• Time-to-market problems• Specification revision becomes
difficult
Courtesy: Coware, Inc. 2005
Issues in HW Centric Design Flows
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 5
The ESL Solution: One Reference Model
One ReferenceModel
Algorithm &Architecture Exploration
HW Development& Verification
SW Development& Verification
Courtesy: Coware, Inc. 2005
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 6
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 4
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 7
Electronic System-Level (ESL) Design
System-level design
Hardwaredevelopment
Softwaredevelopment
Integration & Verification
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 8
system design
hardwaredevelopment
softwaredevelopment
integration & verification
Classical System Design Flow
(semi)automaticmanual
System requirement specification
System architecture design
Modeling
Hardware design
Software development
System
Integration & Verification
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 5
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 9
Hardware-Centric Design Cycle
Time
Task
Specification Fixes in specification
HW design Fixes in hardware
HW verification
SW design Fixes in software
SW verification
Integration & verification
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 10
Hardware-Centric Design Cycle
Time
Task
Specification Fixes in specification
HW design Fixes in hardware
HW verification
SW design Fixes in software
SW verification
Integration & verification✘
known if project is successful
✘
but you want to know here
✘
… and here
✘
… and here
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 6
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 11
system design
hardwaredevelopment
softwaredevelopment
integration & verification
Electronic System-Level (ESL) Design Flow
(semi)automaticmanual
System requirement specification
High-level model
Hardware design Software development
System implementation
Integration & Verification
System-level design
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 12
New ESL Design Cycle
Time
Task
Specification(high-level & arch. models) Fixes in specification
HW design Fixes in hardware
HW verification
SW design Fixes in software
SW verification
Integration & verification
Find good design options here
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 7
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 13
Design Methodologies
• Top down design• Starts with functional system
specification– Application behavior– Models of Computation (MoC)
• Successive refinement• Connect the hardware and
software design teams earlier in the design cycle.
• Allows hardware and software to be developed concurrently
• Goes through architectural mapping
• The hardware and software parts are either manually coded or obtained by refinement from higher model
• Ends with HW-SW co-verification and System Integration
• Platform based design • Starts with architecting a
processing platform for a given vertical application space
– Semiconductor, ASSP vendors
• Enables rapid creation and verification of sophisticated SoCdesigns variants
• PBD uses predictable and pre-verified firm and hard blocks
• PBD reduces overall time-to-market
– Shorten verification time
• Provides higher productivity through design reuse
• PBD allows derivative designs with added functionality
• Allows the user to focus on the part that differentiate his design
Source: Coware, Inc., 2005
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 14
Top-Down ESL Design Environment
SLDesign
FunctionDesign
SystemDef.
HWDESIGN
SWDESIGN
HWFAB
SWCODING
INTEG.& TEST
PROTOTYPING ENVIRONMENTPrimarilyVirtual
PrimarilyPhysical
HW & SW CODESIGN
Cost Models
Copyright © 1995-1999 SCRA Used with Permission
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 8
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 15
Flow To Implementation
Platform-Based Design (PBD)
SystemBehavior
SystemPlatform
Mapping
Refinement
BehaviorVerification
Architecture
Models of Computation
Performance models: Emb. SW, Comm. and
Comp. resources
HW/SW Partitioning,Scheduling & Estimation
Synthesis& Coding
Performance Analysis
and Simulation
Source: UC Berkeley, EECS249
Model Checking
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 16
Lecture 6: Outline
Introduction
System design methodology
• System-level design
• Synthesis
• Modeling
• Summary and conclusions
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 9
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 17
Platform-Based System Synthesis
Application
Optimal Mapping ?
Platform
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 18
Resource Allocation
• Resource allocation, i.e., select resources from a platform for implementing the application
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 10
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 19
Process Binding
• Process mapping, i.e., bind processes onto allocated computational resources
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 20
Channel Routing
• Channel mapping, i.e., assign channels to paths over busses and address spaces
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 11
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 21
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?
Covering the design space
Evaluating design points
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 22
Lecture 6: Outline
Introduction
System design methodology
• System-level design
Synthesis
• Modeling
• Summary and conclusions
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 12
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 23
System Modeling
• Design models as abstraction of a design instance• Representation for validation and analysis• Specification for further implementation Documentation & specification
Systematic methodology• Set of models and transformations (design steps)• Modeling flow defines the design process From specification to implementation
Well-defined, rigorous semantics• Unambiguous, explicit abstractions• Formal models Synthesis and verification
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 24
Separation of Concerns
Managing Complexity
Orthogonalizing concerns
acrossmultiple levels
of abstraction
Behavior Vs.
Architecture
Computation Vs.
Communication
Source: UC Berkeley, EECS249
Platform-based design (PBD) Transaction-level modeling (TLM)
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 13
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 25
Computation vs. Communication
ComputationCommunication
Bus Model Device Model
Behavior can be described algorithmically, without the burden of the handshaking and control logic associated with bus communication.
Communication can be described in a wide range of fashions, from high-level messages, to detailed signal level handshakes without impacting the behavior description.
c = a * b;get a;get b;send c;
Must be synchronized
• Separation of concerns
• Flexibility in modeling, IP reuse
• Design computation & communication separately
Source: Coware, Inc., 2005
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 26
Communication Models
• Pin-Accurate Model (PAM)• Redundant RTL complexity
results in slow simulation• Each device interface must
implement the bus protocol• Each device on the bus has a
pin-accurate interface
• Transaction-Level Model (TLM)• Less code, no wires, fewer
events yield faster simulation• Protocol is modeled as a
single bus model instead of in each device
• Each device communicates via transaction-level API
100x-10,000x faster than PAMBUS
MEM CPU
Periph
TLM API TLM API
TLM APIHREQ
HADDR
HGRANT
HWDATA
HRESP
HREADY
ReqTrfGrant
Trf
AddrTrf
WriteDataTrf
EotTrf
Transaction
BUS
MEM CPU
Periph Req
GrntSel
DataAddr
Clk
Source: Coware, Inc., 2005
Pin/Cycle Accurate
Transactions (Function
Calls)
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 14
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 27
Transaction Level Modeling
The transaction level is a higher level of abstraction for communication
For SoC, communication is often the bottleneck
Communication channel
TargetInitiator
TLM
API
TLM
API
read(addr)write(addr, data)
read(addr)write(addr, data)
Source: Coware, Inc., 2005
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 28
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.
sendAddress()
InitiatorBus
Model
Bus Model keeps track of timing.
Address Data
Initiator and target use an API to communicate via transfers.
Target
sendData()
Event timing can trigger actions.
addressEvent() dataEvent()
Source: Coware, Inc., 2005
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 15
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 29
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
InterconnectInitiator/Target
TargetInitiatorForward path
Backward path
Forward path
Backward path
Command
Address
Data
Byte enables
Response status
Extensions
Source: OSCI TLM-2.0
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 30
SystemC/TLM 2.0 Coding Styles
• Loosely-timed
• Sufficient timing detail to boot OS and simulate multi-core systems
• Each transaction has 2 timing points: begin (call) and end (return)
• Approximately-timed
• Cycle-approximate or cycle-count-accurate
• Sufficient for architectural exploration
• Each transaction has at least4 timing points
– 4 forward/backward function calls– Must immediately return (no wait())
END_REQ
BEGIN_RESP
END_RESP
BEGIN_REQ
Initiator Target
BEGIN
END
Initiator Target
Source: OSCI TLM-2.0
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 16
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 31
Blocking and Non-Blocking Transports
• Blocking transport interface
• Typically used with loosely-timed coding style
• tlm_blocking_transport_ifvoid b_transport(TRANS&, sc_time&);
• Non-blocking transport interface
• Typically used with approximately-timed coding style
• Includes transaction phases
• tlm_fw_nonblocking_transport_iftlm_sync_enum nb_transport_fw(TRANS&, PHASE&, sc_time&);
• tlm_bw_nonblocking_transport_iftlm_sync_enum nb_transport_bw(TRANS&, PHASE&, sc_time&);
Source: OSCI TLM-2.0
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 32
Loosely Timed (LT) Model
TargetInitiator
wait(30ns);
Simulation time 0ns
b_transport(t, 0ns);
b_transport(t, 0ns);call
return
Simulation time 30ns
b_transport(t, 0ns);
b_transport(t, 0ns);call
return
Simulation time 0ns
Source: OSCI TLM-2.0
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 17
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 33
Approximately Timed (AT) Model
TargetInitiator
nb_transport(TLM_ACCEPTED, -, -);
nb_transport(-, END_REQ, 0ns);
nb_transport(TLM_ACCEPTED, -, -);
nb_transport(-, BEGIN_REQ, 0ns);
nb_transport(TLM_ACCEPTED, -, -);
nb_transport(-, END_RESP, 0ns);
nb_transport(TLM_ACCEPTED, -, -);
nb_transport(-, BEGIN_RESP, 0ns);
Source: OSCI TLM-2.0
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 34
NB Return Values (tlm_sync_enum)
• TLM_ACCEPTED• Transaction, phase and timing arguments unmodified
(ignored) on return• Target may respond later (depending on protocol)
• TLM_UPDATED• Transaction, phase and timing arguments updated (used)
on return• Target has advanced the protocol state machine to the
next state
• TLM_COMPLETED• Transaction, phase and timing arguments updated (used)
on return• Target has advanced the protocol state machine straight to
the final phaseSource: OSCI TLM-2.0
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 18
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 35
Using the Return Path
• Callee annotates delay to next transaction
• Caller waits
35
Initiator TargetPhase
BEGIN_REQ
-, BEGIN_REQ, 0nsCall
Simulation time = 100ns
TLM_UPDATED, END_RESP, 5ns Return
-, BEGIN_RESP, 0ns
BEGIN_RESP
Call
Simulation time = 150ns
TLM_UPDATED, END_REQ, 10nsReturn
END_REQ Simulation time = 110ns
END_RESP Simulation time = 155ns
Source: OSCI TLM-2.0
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 36
Early Completion
• Callee annotates delay to next transaction
• Caller waits
36
Initiator TargetPhase
BEGIN_REQ
-, BEGIN_REQ, 0nsCall
TLM_COMPLETED, -, 10ns Return
END_RESP Simulation time = 110ns
Simulation time = 100ns
Source: OSCI TLM-2.0
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 19
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 37
Temporal Decoupling
Initiator Target
b_transport(t, 0ns)Call
Simulation time = 100ns
Simulation time = 130ns
wait(30ns)
Local time offset
Returnb_transport(t, 5ns)+5ns
b_transport(t, 20ns)Call+20ns
Returnb_transport(t, 30ns)+30ns
b_transport(t, 0ns)Call+0ns
Quantum = 25ns
Source: OSCI TLM-2.0
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 38
Direct Memory Interface (DMI)
• Implementation approach• Direct member function
call of target object– In master context
• Pure virtual interface classes defined interface
• Function call encapsulates and hides all interconnect details
• Port/export provides connection semantics (incl. restrictions)
Direct memory interface Faster (no context switch)
Debug interface
CPU
write(addr,data)m(addr)=data
read(addr)return m(addr)
write (addr,data)
read (addr)
Source: W. Ecker, Infineon
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 20
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 39
Lecture 6: Outline
Introduction
System design methodology
System-level design
Synthesis
Modeling
• Summary and conclusions
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 40
Virtual Platform Prototyping
Computation refinement
Communication refinement
Untimed TLM (LT/AT) PCAM
Virtual Prototype
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 21
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 41
Not Modeled-Point to point
-Memory-mapped
Abstraction Levels
Functional Validation
System Partitioning and Assembly
-Exploration and analysis
System Partitioning and Assembly
-Exploration and analysis
Emb. System Modeling-Executable spec. capture
-Functional testing
Emb. System Modeling-Executable spec. capture
-Functional testing
RTL Design & Verification-Block design and unit test-Validation in the system
RTL Design & Verification-Block design and unit test-Validation in the system
System-level Verification-Complete design at RTL-System-level testbench
System-level Verification-Complete design at RTL-System-level testbench
Architectural Validation
Hardware Refinement
RTL Verification
RTL RTL
TimedBus-Functional
Untimed
ApproximatelyTimed TLM
Cycle-AccurateTLM
(Transfer Level)
RTL
InstructionAccurate
CycleAccurate
Processor Interconnect Peripheral
Host-compiled
Loosely TimedTLM
RTL(DUT)
TF(rest)
Incr
easi
ng S
cope
for
Rel
ativ
e O
ptim
izat
ion
Incr
easi
ng S
imul
atio
n Pe
rfor
man
ce
Source: Coware, Inc., 2005
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 42
UT
IA ISSTLM Bus
Log A C C U R A C Y
Log
S P
E E
D
SystemCExecutable TLM
100Kcps
1MIPS
10MIPS
10Kcps
100cps
1Kcps
CycleAccurate
-TLM
Pin-accuratew/RTL
RTL
Host-based
Re-use for Early
SoftwareDevelopment
Re-use for System-level
HardwareVerification
ESLArchitectural
Design LT3 Mcps
CA150 kps
PAM+RTL15 kps
Speed vs. Accuracy
EE382V: System-on-Chip (SoC) Design Lecture 6
© 2014 A. Gerstlauer 22
EE382V: SoC Design, Lecture 6 © 2014 A. Gerstlauer 43
System Design Flow Summary
Design Export… after initial platform configuration through design refinement and
communication synthesis
Functional IP
C/C++SDLSPW
Simulink
Synthesis / Place & Route etc.
Implementation Level Verification
SoftwareAssembly
HardwareAssembly
CommunicationRefinement, Integration &
Synthesis
Performance Analysis and Platform Configuration
System Integration
Platform Function
Platform Architecture
Embedded System Requirements
Platform Configuration
… at theun-clocked, timing-
awaresystem level
Architecture IP
CPU/DSPRTOS
Bus, MemoryHWSW