EE249VCC - The Donald O. Pederson Center for Electronic
Download
Report
Transcript EE249VCC - The Donald O. Pederson Center for Electronic
Architectural Modeling in VCC
EE 249
Agenda
• System-level SoC Design – Message and Use Models
• A commercial solution - The VCC Design Flow
• Abstraction – A Brief History
• Performance Modeling
• System-level Design Exploration
• How to Get The Performance Numbers
• Architectural Services Example
• Summary
Embedded System on Chip (SoC) Design
System
Environment
Zone 4: Global
Satellite
Zone 3: Suburban Zone 2: Urban
Zone 1: In-Building
Pico-Cell
Macro-Cell Micro-Cell
Requirements
Specification
Specification
Untimed,
Unclocked,
C/C++ Level
Memory
Implementation
Timed,
Clocked,
RTL Level
Software
Analog
SOC
Firmware
CORE
Implementation
P/C
µ
Embedded
Software
Characterization
Testbench
Refinement
Design Export
Embedded
Systems Design
SOC Creator and System Integrator
Enabling the Electronic Design Chain
BMW
Infineon Technologies AG
Magneti Marelli S.p.A.
Motorola
National Semiconductor
Nokia
Telefonaktiebolaget LM Ericsson
Thomson CSF
Felix Partnership Members
Hitachi Micro Systems
Infineon Technologies AG
Motorola SPS
National Semiconductor
NEC Electronics
Philips Semiconductors
ST Microelectronics
Texas Instruments
System
Houses
Virtual Component
(IP) Providers
ARM
debis Systemhaus (now Infineon)
Symbionics Ltd (now Cadence)
Semiconductor
Houses
Manufacturing
Virtual Component
(IP) Providers
ARM
Symbionics Ltd (now Cadence)
The Platform-Based Design Concept
Taking Design Block Reuse to the Next Level
Pre-Qualified/Verified
Foundation-IP*
Foundation Block + Reference Design
MEM
Hardware IP
SW IP
Application
Space CPU
FPGA
Scaleable
bus, test, power, IO,
clock, timing architectures
Processor(s), RTOS(es)
and SW architecture
Methodology / Flows:
Programmable
System-level performance
evaluation environment
*IP can be hardware (digital
or analogue) or software.
IP can be hard, soft or
‘firm’ (HW), source or
object (SW)
Foundry-Specific
Pre-Qualification
Rapid Prototype for
End-Customer Evaluation
SoC Derivative Design
Methodologies
Foundry Targetting Flow
The Platform-Based Design Concept
Platform Type Examples
“Full Application
HW/SW Platform”
Examples:
–TI OMAP
–Philips nExperia,
–Infineon MGold
“Processor
Centric”
Examples:
– ARM Micropack
– ST100 Platform
– Improv Jazz
Improv JAZZ Platform
“Communication
Centric”
Examples:
–Palmchip
–Sonics
SONICs Architecture
DMA
SiliconBackplane™
(patented)
{
C
CPU
MEM
DSP
I
MPEG
O
System House Requirements
… exploring and developing on top of SoC Platforms
Application Space
Platform Based Design Objectives
• Define the application instance to be
implemented to satisfy product
requirements defined by consumer
Platform
Specification
• Specify the system platform together
with suppliers accordingly
• Evaluate top down different instances
of SOC platforms
System Platform
Platform
Design Space
Exploration
Architectural Space
System Houses and SOC Providers …
…enabling a close communication!
"The increasing complexity of telecom applications requires that
we spend more time upfront exploring system architectures
and IP alternatives. The Cierto VCC environment assisted us in
providing a platform to clearly articulate these needs to our
IP providers and we believe it will help architect the nextgeneration system design solutions.”
Jan-Olof Kismalm, Director, Microelectronics,
Corporate Function Technology,
Telefonaktiebolaget LM Ericsson,
January 10th 2000
SOC Provider Requirements
… designing SoC Platforms and Sub-systems
Application Space
Platform Based Design Objectives
• Define the SOC platform instance so
that multiple instances of applications
can be mapped to the same system
platform
• Present this to system customers as
SOC Design-Kit and optimally
leverage economy of scale for SOC
platform instance
• Provide bottom up instances of SOC
platform for evaluation without
disclosing the details of the IP
Platform
Design Space
Exploration
System Platform
Platform
Specification
Architectural Space
Customer Testimonials!
"As an original development partner during the development of VCC our
focus has been the modeling of the IP in our SOC platforms. The
memory and cache modeling features in VCC 2.0 will allow us and
our customers to explore the impact of different memory
hierarchies on overall system performance before we commit to
implementation of our SOC platforms. VCC 2.0 will significantly
optimize the interaction with our SOC customers to negotiate
the system specification.“
Jean-Marc Chateau
Director of Design, Consumer and Micro Groups
ST Microelectronics
September 25th, 2000
A Commercial Solution The VCC Design Flow
VCC Front End
Embedded System Requirements
Functional IP
C/C++
SDL
SPW
Simulink
Platform Function
Platform
Architecture
System Integration
Performance Analysis and
Platform Configuration
Architecture IP
CPU/DSP
RTOS
Bus, Memory
HW
SW
Platform
Configuration
… at the
un-clocked, timing-aware
system level
• Enabling communication within the SOC Design Chain
• Design Space Exploration with abstracted Performance Models
• Untimed Functional and Performance Verification
• Integration Platform Design, Optimization and Configuration
VCC Front End
Functional Integration and Analysis
Embedded System Requirements
Functional IP
C/C++
SDL
SPW
Simulink
Platform Function
Platform
Architecture
System Integration
Performance Analysis and
Platform Configuration
Architecture IP
CPU/DSP
RTOS
Bus, Memory
HW
SW
Platform
Configuration
… at the
un-clocked, timing-aware
system level
VCC Front End
Define Architectural Options and Configuration
Embedded System Requirements
Functional IP
C/C++
SDL
SPW
Simulink
Platform Function
Platform
Architecture
System Integration
Performance Analysis and
Platform Configuration
Architecture IP
CPU/DSP
RTOS
Bus, Memory
HW
SW
Platform
Configuration
… at the
un-clocked, timing-aware
system level
VCC Front End
Define Function Architecture Mapping
Embedded System Requirements
Functional IP
C/C++
SDL
SPW
Simulink
Platform Function
Platform
Architecture
System Integration
Performance Analysis and
Platform Configuration
Architecture IP
CPU/DSP
RTOS
Bus, Memory
HW
SW
Platform
Configuration
… at the
un-clocked, timing-aware
system level
VCC Front End
Run Performance Analysis for Platform Configuration
Embedded System Requirements
Functional IP
Platform Function
C/C++
SDL
SPW
Simulink
Cache Results
Platform
Architecture
System Integration
Performance Analysis and
Platform Configuration
Processor Load
Architecture IP
CPU/DSP
RTOS
Bus, Memory
HW
SW
Platform
Configuration
… at the
un-clocked, timing-aware
system level
Process Gant Chart Analysis
VCC Backend
• Linking System Level Design to Implementation
– Fast track to prototyping
– Fast track to software development
– Design consistency through the design flow
Communication
Refinement, Integration & Synthesis
Hardware
Assembly
Software
Assembly
Implementation Level Verification
Synthesis / Place & Route etc.
Design Export
… after initial platform
configuration through
design refinement and
communication synthesis!
VCC Backend
Communication Refinement and Synthesis
Communication
Refinement
Communication
Synthesis
VCC Model
VCC Model to RTOS
Protocol Component
Abstract
Token
Abstract
Token
Communication
Refinement, Integration & Synthesis
Hardware
Assembly
Software
Assembly
Implementation Level Verification
Synthesis / Place & Route etc.
RTOS
VCC Model
RTOS to CPU
Protocol Component
Bus Slave to VCC
Model Component
CPU
Bus Slave
CPU to Bus Protocol
Component
Bus to Bus Slave
Component
Bus
Bus
Bus Model
Design Export
… after initial platform
configuration through
design refinement and
communication synthesis!
VCC Backend
Export to Implementation (Design and Test Bench)
VCC
System Exploration
Communication Refinement
Flow To Implementation
Hardware
Top-level
System
Test Bench
Software
on RTOS
Communication
Refinement, Integration & Synthesis
Hardware
Assembly
Software
Assembly
Implementation Level Verification
Synthesis / Place & Route etc.
Design Export
… after initial platform
configuration through
design refinement and
communication synthesis!
VCC Flow Summary
Embedded System Requirements
Functional IP
C/C++
SDL
SPW
Simulink
Platform Function
Platform
Architecture
System Integration
Performance Analysis and
Platform Configuration
Communication
Refinement, Integration & Synthesis
Hardware
Assembly
Software
Assembly
Implementation Level Verification
Synthesis / Place & Route etc.
Architecture IP
CPU/DSP
RTOS
Bus, Memory
HW
SW
Platform
Configuration
… at the
un-clocked, timing-aware
system level
Design Export
… after initial platform
configuration through
design refinement and
communication synthesis!
Abstraction – A Brief History
How did we use abstraction in the past?
Step 1 – Layout to Transistor
Digital Abstraction
1970’s
• Switching delay of the transistor
• The design complexity exceeds what
designers can comprehend and think
through at the layout level
• Interconnect delay between transistors
• Transistor level simulation allows to verify
the logic of digital and analog designs
based on transistor switching
characteristics
abstract
Transistor Model
Capacity Load
1970’s
cluster
How did we use abstraction in the past?
Step 2 – Transistors to Gates
Digital Abstraction
Gate delay
Interconnect delay between gates
1980’s
The design complexity exceeds what
designers can comprehend and
simulate at the transistor level
abstract
Transistor Model
Capacity Load
1970’s
abstract
Gate Level Model
Capacity Load
cluster
1980’s
cluster
Gate level simulation allows to verify
the logic of digital designs based on
gate switching characteristics.
How did we use abstraction in the past?
Step 3 – Gates to RTL-HDL
Digital Abstraction
Not really a abstraction of performance
(e.g. SDF only used for gate to layout
to gate)
abstract
Gate Level Model
Capacity Load
1980’s
abstract
Textual statements result in “many
gates” after synthesis
RTL
cluster
1990’s
The design complexity exceeds what
designers can comprehend and
simulate at the gate level alone
HDL is first used for fast verification,
synthesis allows translation of text into
gates
Synthesis algorithms map text to actual
registers and logic in between based on
characterized gate and wire-load
libraries
Gate and wire-load delays are refined
after layout. SDF emerges as format
1990’s
So what did we do all the time?
• The industry abstracted the system function
– Layout to transistor switching
– Transistor to gate schematics
– Gate schematics to RTL
• From level to level the industry abstracted performance data
– Spice models to transistor models (switch+interconnect)
– Transistor models to gate level models (gate switch+interconnect)
– No real “new” performance models when going to RTL
• Resulting standard formats
– SDF for delay characterization
– Gate delays and wire-load (.db) enabling synthesis
And what is the next step?
IP Block Performance
Ports
DMAC
Modeling of Performance for IP Blocks
abstract
Transistor Model
Capacity Load
1970’s
abstract
SDF
Gate Level Model
Capacity Load
MPEG
Audio Decoder
uC
I/F
abstract
abstract
… by attaching performance data to
timing free functional models
Register File
Timers
RTL
cluster
Graphics
Engine
On-Chip Ram
RTL
Clusters
cluster
cluster
1980’s
1990’s
Year 2000 +
And what is the next step?
Inter IP Communication Performance
abstract
Transistor Model
Capacity Load
1970’s
abstract
SDF
Gate Level Model
Capacity Load
abstract
abstract
Modeling of Performance for
Communication between IP Blocks
RTL
cluster
RTL
Clusters
cluster
cluster
1980’s
1990’s
Year 2000 +
And what is the next step?
IP Block Performance
Inter IP Communication Performance
Ports
DMAC
Apply this to Hardware and Software
1970’s
RTOS
MPEG
Audio Decoder
uC
I/F
abstract
abstract
abstract
Transistor Model
Capacity Load
abstract
SDF
Gate Level Model
Capacity Load
cluster
RTL
cluster
Driver
Graphics
Engine
On-Chip Ram
RTL
Clusters
1990’s
SW
Models
Discontinuity:
Embedded Software
cluster
1980’s
Tasks
Register File
Timers
Year 2000 +
Performance Modeling
… using Abstraction
Functional Simulation
Gate Level
Functional Simulation
Function
A
0
0
1
1
B OUT
0
1
1
0
0
0
1
0
• Gate switching defines functionality
• Combination of gate functionality
defines “functionality” of the design
• Simulation slow in complex systems
as huge amounts of events are to be
processed
Functional Simulation
Using VCC at the System-Level
Functional Simulation
SPW
• Function of system blocks executed
StateCharts
– General Descriptions
– C, C++, State Charts, OMI
– Application specific
SDL
– SPW, Telelogic SDL, Matlab
Simulink, ETAS Ascet
Simulink
A
0
0
1
1
Functio
n
B OUT
0
1
1
0
0
0
1
0
C++
C
• Functional execution defined as “fire
and return” with a OMI 4.0 compliant
discrete event simulation
infrastructure
• Simulation is as fast as the abstract,
un-timed models simulate
Performance Simulation
Gate Level
Functional Simulation
Function
A
0
0
1
1
B OUT
0
1
1
0
0
0
1
0
• Gate switching functionality
Performance
Dt
SDF and
Gate Level
Library
Performance
InterConnect
Capacity
Performance Simulation
• functionality annotated with intrinsic
gate delay
• interconnect delay modeled from
capacity
Refinement
• SDF data is refined after layout is
carried out
VCC Performance Simulation
System-Level Block Performance Modeling
Performance Simulation
Performance
• functionality annotated with intrinsic
delay models
• Delay Script and Inline Models,
refined after implementation
Interleaver
Dt
IP Functional Model
A
0
0
1
1
Functio
n
B OUT
0
1
1
0
0
0
1
0
Performance
Scripted
Delay
Model
Forward Error Correction
FEC() {
f = x.read();
// FEC function here
y.write(r);
}
Inline
Delay
Model
Dt
IP Functional Model
Forward Error Correction
FEC on CPU
FEC in slow HW
FEC() {
// FEC_ip_implem
f = x.read();
FEC in fast HW
delay()
{
// FEC_ip_implem
// FEC function here
input(x);
delay() Delay
{
Script
y.write(r);
run();input(x);
// FEC_ip_implem
}
delay(200*cps);
run();delay() {
output(y);
delay(128*cps);
input(x);
}
output(y);
run();
}
delay(64*cps);
output(y);
}
Annotated
IP Functional Model
FEC() {
f = x.read();
// FEC function part A here
__DelayCycles(60*cps);
// FEC function part B here
__DelayCycles(78*cps);
// FEC function part C here
__DelayCycles(23*cps);
y.write(r);
}
VCC Performance Simulation
System Level Block Interconnect Performance Modeling
Post() from Behavior 1
Sender
Value()/Enable() from Behavior 2
Shared Memory
Communication Pattern
Receiver
RTOS
Standard C
Library
CPU
A
0
0
1
1
Functio
n
B OUT
0
1
1
0
0
0
1
0
Pattern Services
Memory
Access
InterConnect
Capacity
Memory
CPU
Port
Architecture Services
Performanc
e
RAM
Bus Adapter
RAM
Port
Slave
Adapter
ASIC
Port
Bus Adapter
Bus
Bus Arbiter
VCC Performance Simulation
Enabled through Architecture Services in VCC
A
B
Post(5)
Value()
Semaphore
Protected
SemProt_Send
SemProt_Recv
SemProt_Send
mutex_lock;
memcpy;
setEnabled
wait;
memcpy;
signal
signal
User Visible
RTOS
SwMutexes
write
MemoryAccess
BusMaster
Pattern Services
read
Architecture Services
CPU
Mem
SlaveAdapter
busRequest
BusArbiter
arbiterRequest/Release
busIndication
busIndication
VCC Performance Modeling …
… the System Level extension of SDF !
Classical Gate Level Technology
Function
A
0
0
1
1
B OUT
0
1
1
0
0
0
1
0
VCC System Level Technology
IP Block
Performance
Performance
Dt
SDF and
Gate Level
Library
Function
C, C++,
SPW, SDL,
Simulink,
Statecharts
Performance
System
Level Library
Interleaver
Dt
SPW
Interconnect
Performance
InterConnect
Capacity
StateCharts
IP Block
Interconnect
Performance
SDL
Simulink
C++
C
Design Space Exploration
… using Abstraction
Design Space Exploration
From RTL through Gate Level options
Technology provider
SDF
Wire Load
– characterizes silicon technology for
gates and interconnects
Synthesis
Library
– map constructs from RTL into
registers and logic in between
registers, does logic optimization
RTL
Models
– explore the design space
(“performance” – “area”) using
gradient methods in a optimization
process
Performance
synthesize
Abstracted from Layout
Synthesis Tools
Area
Design Space Exploration
… through Function and Architecture
Perf.
Model
Library
IP Block Performance
Interconnect Performance
Ports
DMAC
Tasks
Register File
Timers
RTOS
MPEG
Audio Decoder
uC
I/F
Driver
Performance
synthesize
RTL
Models
Abstracted from Layout
On-Chip Ram
RTL
Clusters
Synthesis
Library
SDF
Wire Load
Area
integrate
abstract
Graphics
Engine
SW
Models
Design Space Exploration using VCC
… through Function and Architecture
SOC Silicon provider
Perf.
Model
Library
IP Block Performance
Interconnect Performance
Ports
DMAC
Tasks
Register File
Timers
RTOS
MPEG
Audio Decoder
uC
I/F
– characterizes IP portfolio (typically in
Integration Platforms) for intrinsic IP
Block Performance and Inter IP
Block Interconnect Performance
Driver
System Integrator and SOC Provider
SW
Models
– map function to architecture setting
up design experiments
– determine using performance
simulation feedback suitability of
function-architecture combination
– explore design space through
“function” and ”architecture”
Performance
synthesize
RTL
Models
Abstracted from Layout
On-Chip Ram
RTL
Clusters
Synthesis
Library
SDF
Wire Load
integrate
abstract
Graphics
Engine
Area
How to get the Performance
Numbers
How to get the performance numbers…
IP Block Performance Modeling
Top Down Flow
• In a pure top down design flow the
performance models are “Design
Requirements” for functional models
• They are refined using bottom up
techniques in due course throughout
the project
Bottom Up Flow
• SOC Provider characterizes IP
portfolio, e.g. of a Integration
platform
– using HDL model simulation
– using software simulation on ISS
– using benchmarking on SOC
IP Functional Model
Scripted
Delay
Model
Forward Error Correction
FEC() {
f = x.read();
// FEC function here
y.write(r);
}
IP Functional Model
Forward Error Correction
FEC on CPU
FEC in slow HW
FEC() {
// FEC_ip_implem
f = x.read();
FEC in fast HW
// {FEC_ip_implem
// FECdelay()
function
here
input(x);
delay() {Delay Script
y.write(r);
run(); input(x);
}
// FEC_ip_implem
delay(200*cps);
run(); delay() {
output(y);
delay(128*cps);
input(x);
}
output(y);
run();
}
delay(64*cps);
output(y);
}
Inline
Delay
Model
Annotated
IP Functional Model
FEC() {
f = x.read();
// FEC function part A here
__DelayCycles(60*cps);
// FEC function part B here
__DelayCycles(78*cps);
// FEC function part C here
__DelayCycles(23*cps);
y.write(r);
}
How to get the performance numbers…
IP Block Interconnect Performance Modeling
Top Down Flow
• Datasheets for architectural IP
information are entered in
parameters for architectural services
• Can be done fast by System
Integrator without SOC Provider!
• Refinement with SOC Provider
models
Bottom Up Flows
• Architectural IP is profiled using
HDL simulation, ISS or silicon and
data is entered in VCC architectural
services
Value()/Enable() from Behavior 2
Post() from Behavior 1
Shared Memory
Communication Pattern
Sender
Receiver
RTOS
Standard C
Library
CPU
Memory
Access
RAM
Memory
CPU
Port
Bus Adapter
RAM
Port
Slave
Adapter
ASIC
Port
Bus Adapter
Bus
Bus Arbiter
Pattern Services
Architecture Services
How to get the performance numbers…
Software Estimation for ANSI C code (“Whitebox C”)
• Estimation of software performance prior to implementation
• CPU characterized as Virtual Processor Model
– Using a Virtual Machine Instruction Set
– Used for dynamic control SW estimation during performance simulation taking into
account bus loading, memory fetching, and register allocation
• Value
– True co-design: SW estimation using annotation into C Code (as opposed to to
simulation in instruction simulators used in co-verification)
– Good for early system scheduling, processor load estimation
– Two orders of magnitude faster than ISS
– Greater than 80 percent accuracy
– Enables pre-implementation decision but is not a verification model
How to get the performance numbers…
Virtual Processor Model Characterization Methods
Data Book Approach
– CPU data book information to count cycles and estimate VIM
Calibration Suite using “Best Fit”
– Run Calibration Suite on VIM and ISS
– Solve a set of linear equations to minimize difference
Application Specific Calibration Suite
– using the “Best Fit” method but use application specific routines for automotive,
wireless telecom, multimedia etc.
Exact Count on ISS
– cycle counts exactly derived from ISS run
– Filter specific commands out (e.g. OPi etc.)
How to get the performance numbers…
Software Estimation for ANSI C code (“Whitebox C”)
Virtual Machine
Instruction Set Model
LD,3.0
LI,1.0
ST,3.0
OP.c,3.0
OP.s,3.0
OP.i,4.0
OP.l,4.0
OP.f,4.0
OP.d,6.0
MUL.c,9.0
MUL.s,10.0
MUL.i,18.0
MUL.l,22.0
MUL.f,45.0
MUL.d,55.0
DIV.c,19.0
DIV.s,110.0
DIV.i,118.0
DIV.l,122.0
DIV.f,145.0
DIV.d,155.0
IF,5.0
GOTO,2.0
SUB,19.0
RET,21.0
Load from Data Memory
Load from Instr. Mem.
Store to Data Memory
Simple ALU Operation
Complex ALU Operation
Test and Branch
Unconditional Branch
Branch to Subroutine
Return from Subroutine
How to get the performance numbers…
Software Estimation for ANSI C code (“Whitebox C”)
ANSI C
Input
char *event;
int proc;
if (*(event+proc) & 0x1: 0x0)
...
Assembler
ld
ld
add
ld
ldi
and
cmp
br
ba
Whitebox C
declare ports
tmp=b+c
c=f(d)
MT update D1
Compile
generated C and
run natively
Performance
Estimation
#event,R1
#proc,R2
R1,R2,R3
(R3),R4
#0x1, R5
R4, R5, R6
R0, R6, R7
R7, LTRUE
LFALSE
tmp
r=(s<<*a)
a=r+m*x
y=a*c+b
MT update D2+D3
write B y
Analyse
ld
ld
op
ld
li
op
ts
-br
basic blocks
compute delays
D1
Generate new C
!tmp
with delay counts
D2
D3
Virtual
Processor
Model
Architecture
Characterization
f6(y)
MT update D4
return
D4
Architectural Services Example
Architecture Service
• The service is the element that defines the functionality of
architecture
• A service is coded in C++ and performs a specific role to model
architecture, for example:
– bus arbitration
– memory access
– interrupt propagation
– etc.
Example of Services
ASIC
Behavior
Post
Pattern
Sender
Bus
BusMaster
BusArbiter
Mem
BusSlave
Memory
Example of Services
• Behavior calls Post, i.e., send a communication
• Pattern hears Post and directs ASIC block’s BusMaster to send
a communication
• BusMaster asks the Bus Block’s BusArbiter for use of the bus
• BusArbiter grants the bus, so communication can go to Memory
Block
• Memory Block’s BusSlave receives communication and forwards
to memory
• Memory stores communication.
Categories of Services
• Pattern Service
– services that coordinate the communication of architecture services
• Architecture Service
– services that define the functionality of architecture
• Internal Service
– generic, default service used during functional simulation
Pattern Service
• A pattern coordinates architectural services that collectively model a
communication path from sender to receiver
• Patterns are composed of a sender service and a receiver service
– Sender service defines Post
– Receiver service defines Enabled/Value
Post
Pattern
Sender
Enabled/ Pattern
Value Receiver
• Both the sender and receiver service direct the actions of architecture
services to send/receive communication
Basic Example
• Let’s assume two behaviors.
• b1 and b2 talk to each other:
– b1 says Post; b2 says Value
– and visa versa
Basic Example (cont)
• What does it mean for b1 to talk to b2?
• What does it mean for b1 to say Post?
• What does it mean for b2 to say Value?
• We should consider an architecture to give meaning to b1 and
b2.
• We should consider how the behavior blocks map to the
architecture.
Basic Example (cont)
• Let’s assume the following architecture:
Basic Example (cont)
• Here we map the behavior to the architecture:
Basic Example (cont)
• What do we see in the mapping diagram?
– b1 is mapped to software.
– b2 is mapped to hardware.
– b1 to b2 communication is set to Shared Memory.
– b2 to b1 communication is set to to Interrupt Register Mapped.
• For simplicity’s sake, we’re focusing on b1-to-b2 communication.
– b2 to b1 will be ignored for now.
• If b1 talks to b2, how does that look when mapped to an architecture?
– What happens when b1 says Post?
– What happens when b2 says Value?
– Note b1 to b2 is shared memory communication.
Basic Example (cont)
• Using Shared Memory, we have the
following sequence of communication:
1. b1 writes to memory:
b1 RTOS CPU Bus Mem
2. b2 reads from memory:
b2 ASIC Bus Mem
Basic Example (cont)
• So b1 talks to b2 through the various architecture components:
– b1 says Post and that becomes a write to memory.
– b2 says Value and that becomes a read from memory.
• What is the underlying mechanism that propagates Post/Value
through the architecture?
– It’s something called the “service”.
Architectural Services
• More basic than the architecture block is the service.
• The service is the atomic (unsplittable) piece that composes the
architecture block.
• The next diagrams overlay the services on top of architectural
blocks.
Service Example
Architecture
SimpleMemory
Memory
TDMI_DataBus
ASIC
FCFSBusAdapter
FCFSSlaveAdapter
BusArbiter
eCos
StandardCLibrary
SimpleCPU
CPUMemoryAccess
FCFSBusAdapter
Service Example (cont)
Architecture
Pattern
b1
Sender
Receiver
b2
Sender Perspective
Message Sequence Charts
Receiver Perspective
Message Sequence Charts
Commercial Example
ST Microelectronics
IP models support codesign efforts
By
Benoit Clement
System-Level Design Engineer
Doha Benjelloun
System-Level Design Engineer
Co-Design Methodology for Systems &Architecture (CMSA)
STMicroelectronics, Grenoble, France
http://www.eetimes.com/story/OEG20010913S0069