Architectural Modeling in VCC EE 249 - Donald...

Seminar on Virtual Component Co-Design (Cadence CiertoTM VCC)

Page 1

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


Page 2

ImplementationTimed,Clocked,RTL Level

RefinementDesign Export

SpecificationUntimed,Unclocked ,C/C++ Level

Embedded System on Chip (SoC) Design

Testbench

Satellite

Macro-Cell Micro-Cell

Zone 2: UrbanZone 1: In-Building

Pico-Cell

Zone 4: Global

Zone 3: Suburban

SystemEnvironment

Implem

entation

CharacterizationFirmware

CORE

Software

SOC

µP/CAnalog

EmbeddedSoftware

Memory

Embedded Systems Design

Requirements Specification

SystemHouses

Manufacturing

BMWInfineon Technologies AG

Magneti Marelli S.p.A. Motorola

National SemiconductorNokia

Telefonaktiebolaget LM EricssonThomson CSF

SOC Creator and System Integrator Enabling the Electronic Design Chain

SemiconductorHouses

Hitachi Micro SystemsInfineon Technologies AG

Motorola SPSNational Semiconductor

NEC ElectronicsPhilips Semiconductors

ST MicroelectronicsTexas Instruments

Virtual Component(IP) Providers

Virtual Component(IP) ProvidersARM

debis Systemhaus (now Infineon)Symbionics Ltd (now Cadence)

ARMSymbionics Ltd (now Cadence)

Felix Partnership Members


Page 3

The Platform-Based Design ConceptTaking Design Block Reuse to the Next Level

Rapid Prototype forEnd-Customer EvaluationSoC Derivative DesignMethodologies

System-level performanceevaluation environment

ApplicationSpace

Methodology / Flows:

Foundation Block

MEM

FPGACPU Processor(s), RTOS(es)

and SW architecture

*IP can be hardware (digitalor analogue) or software.IP can be hard, soft or‘firm’ (HW), source orobject (SW)

*IP can be hardware (digitalor analogue) or software.IP can be hard, soft or‘firm’ (HW), source orobject (SW)

Scaleablebus, test, power, IO,clock, timing architectures

+ Reference Design

Programmable

SW IP

Hardware IP

Pre-Qualified/VerifiedFoundation-IP*

Foundry -SpecificPre-Qualification

Foundry Targetting Flow

The Platform-Based Design ConceptPlatform Type Examples

Examples:–Palmchip–Sonics

Examples:– ARM Micropack– ST100 Platform– Improv Jazz

Examples:–TI OMAP–Philips nExperia, –Infineon MGold

“Communication Centric”

“ProcessorCentric”

“Full ApplicationHW/SW Platform”

ImprovJAZZ Platform

SiliconBackplane™

(patented) {DSP MPEGCPUDMA

C MEM I O

SONICs Architecture


Page 4

System House Requirements… exploring and developing on top of SoC Platforms

Platform Based Design Objectives

• Define the application instance to be implemented to satisfy product requirements defined by consumer

• Specify the system platform together with suppliers accordingly

• Evaluate top down different instances of SOC platforms

Architectural Space

System Platform

Application Space

PlatformSpecification

PlatformDesign SpaceExploration

"The increasing complexity of telecom applications requires thatwe spend more time upfront exploring system architecturesand 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 next-generation system design solutions.”

Jan-Olof Kismalm, Director, Microelectronics,Corporate Function Technology,

Telefonaktiebolaget LM Ericsson,January 10th 2000

System Houses and SOC Providers ……enabling a close communication!


Page 5

SOC Provider Requirements… designing SoC Platforms and Sub-systems

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 Architectural Space

System Platform

Application Space

PlatformSpecification

PlatformDesign SpaceExploration

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 ChateauDirector of Design, Consumer and Micro Groups

ST Microelectronics

September 25th, 2000


Page 6

A Commercial Solution -The VCC Design Flow

VCC Front End

• 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

Functional IP

C/C++SDLSPW

Simulink Performance Analysis and Platform Configuration

System Integration

Platform Function Platform Architecture

Embedded System Requirements

Platform Configuration

… at theun-clocked, timing-aware

system level

Architecture IP

CPU/DSPRTOS

Bus, MemoryHWSW


Page 7

VCC Front EndFunctional Integration and Analysis

Functional IP

C/C++SDLSPW


System Integration





system level

Architecture IP

CPU/DSPRTOS

Bus, MemoryHWSW

VCC Front EndDefine Architectural Options and Configuration

Functional IP

C/C++SDLSPW


System Integration





system level

Architecture IP

CPU/DSPRTOS

Bus, MemoryHWSW


Page 8

VCC Front EndDefine Function Architecture Mapping

Functional IP

C/C++SDLSPW


System Integration





system level

Architecture IP

CPU/DSPRTOS

Bus, MemoryHWSW

VCC Front EndRun Performance Analysis for Platform Configuration

Functional IP

C/C++SDLSPW


System Integration





system level

Architecture IP

CPU/DSPRTOS

Bus, MemoryHWSW

Cache Results Processor Load Process Gant Chart Analysis


Page 9

VCC Backend

• Linking System Level Design to Implementation

– Fast track to prototyping

– Fast track to software development

– Design consistency through the design flow

Design Export… after initial platform configuration through design refinement and

communication synthesis!

Synthesis / Place & Route etc.

Implementation Level Verification

SoftwareAssembly

HardwareAssembly

CommunicationRefinement, Integration & Synthesis

VCC BackendCommunication Refinement and Synthesis





SoftwareAssembly

HardwareAssembly


AbstractToken

AbstractToken

CommunicationRefinement

CPU

VCC ModelVCC Model to RTOS Protocol Component

CPU to Bus Protocol Component

Bus

Bus Slave to VCC Model Component

Bus ModelBus

VCC Model

Bus to Bus Slave Component

Bus Slave

RTOSRTOS to CPU

Protocol Component

CommunicationSynthesis


Page 10

VCC BackendExport to Implementation (Design and Test Bench)





SoftwareAssembly

HardwareAssembly


Flow To Implementation

HardwareTop-level

SystemTest Bench

Softwareon RTOS

VCCSystem Exploration

Communication Refinement

VCC Flow Summary



Functional IP

C/C++SDLSPW

Simulink



SoftwareAssembly

HardwareAssembly


Performance Analysis and Platform Configuration

System Integration





system level

Architecture IP

CPU/DSPRTOS

Bus, MemoryHWSW


Page 11

Abstraction – A Brief History

How did we use abstraction in the past?Step 1 – Layout to Transistor

Digital Abstraction

• Switching delay of the transistor

• Interconnect delay between transistors

1970’s

• The design complexity exceeds what designers can comprehend and think through at the layout level

• Transistor level simulation allows to verify the logic of digital and analog designs based on transistor switching characteristics

abst

ract

Transistor ModelCapacity Load

1970’s

cluster


Page 12

How did we use abstraction in the past?Step 2 – Transistors to Gates

abst

ract


1970’s

cluster

abst

ract

Gate Level ModelCapacity Load

1980’s

1980’s§ The design complexity exceeds what

designers can comprehend and simulate at the transistor level

§ Gate level simulation allows to verify the logic of digital designs based on gate switching characteristics.

cluster

Digital Abstraction

§ Gate delay

§ Interconnect delay between gates

How did we use abstraction in the past?Step 3 – Gates to RTL-HDL

RTL

cluster

abst

ract

1990’s

Digital Abstraction

§ Not really a abstraction of performance (e.g. SDF only used for gate to layout to gate)

§ Textual statements result in “many gates” after synthesis

abst

ract

Gate Level ModelCapacity Load

1980’s

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


Page 13

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?

abst

ract


cluster

abst

ract

SDFGate Level Model

Capacity Load

RTL

cluster

abst

ract

1970’s 1980’s 1990’s Year 2000 +

MPEG

Vide

o Dec

oder

I/F

DMACPorts

Timers

MPEGAudio Decoder

GraphicsEngine

DRAM

Ctrl

Bus/C

ache

Contr

ol

Register File

uC

On- Chip Ram

D -Cach

e

I- Cache

RTLClusterscluster

abst

ract

IP Block Performance

Modeling of Performance for IP Blocks

§ … by attaching performance data to timing free functional models


Page 14


abst

ract


cluster

abst

ract

SDFGate Level Model

Capacity Load

RTL

cluster

abst

ract

1970’s 1980’s 1990’s Year 2000 +

RTLClusterscluster

abst

ract

Inter IP Communication Performance

Modeling of Performance for Communication between IP Blocks


abst

ract


cluster

abst

ract

SDFGate Level Model

Capacity Load

RTL

cluster

abst

ract

1970’s 1980’s 1990’s Year 2000 +

MPEG

Vide

o Dec

oder

I/F

DMACPorts

Timers

MPEGAudio Decoder

GraphicsEngine

DRAM

Ctrl

Bus/C

ache

Contr

ol

Register File

uC

On- Chip Ram

D -Cach

e

I- Cache

RTLClusterscluster

abst

ract

IP Block PerformanceInter IP Communication Performance

SWModels

Driver

RTOS

Tasks

Discontinuity:Embedded Software

Apply this to Hardware and Software


Page 15

Performance Modeling… using Abstraction

Functional SimulationGate Level

Functional Simulation

• 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

A B OUT0 0 10 1 01 0 01 1 0

Function


Page 16

C++ C

Simulink

SDL

SPWStateCharts

Functional SimulationUsing VCC at the System-Level


• Function of system blocks executed

– General Descriptions

– C, C++, State Charts, OMI

– Application specific

– SPW, Telelogic SDL, Matlab Simulink, ETAS Ascet

• 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

A B O U T0 0 10 1 01 0 01 1 0

Funct ion

Abstraction

Performance SimulationGate Level


• Gate switching functionality

Performance Simulation

• functionality annotated with intrinsic gate delay

• interconnect delay modeled from capacity

Refinement

• SDF data is refined after layout is carried out

Inter -ConnectCapacity

Performance

A B OUT0 0 10 1 01 0 01 1 0

Function

∆t

Performance

SDF andGate Level

Library


Page 17

VCC Performance SimulationSystem-Level Block Performance Modeling

Performance Simulation

• functionality annotated with intrinsic delay models

• Delay Script and Inline Models, refined after implementation

A B O U T0 0 10 1 01 0 01 1 0

Funct ion

∆ t

Performance

Abstraction

AnnotatedIP 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);}

IP Functional ModelForward Error Correction

FEC() {f = x.read();// FEC function herey.write(r);}

FEC on CPU

// FEC_ip_implemdelay() {input(x);run();delay(200*cps);output(y);}

FEC in slow HW


FEC in fast HWDelay Script




ScriptedDelayModel

InlineDelayModel

∆ t

Performance

Interleaver

VCC Performance SimulationSystem Level Block Interconnect Performance Modeling

Inter-ConnectCapacity

Performance

A B O U T0 0 10 1 01 0 01 1 0

Funct ion

Abstraction

Shared MemoryCommunication PatternSender Receiver

Post() from Behavior 1Value()/Enable() from Behavior 2

Pattern Services

Standard CLibrary

RTOS

Architecture Services

MemoryAccess

CPU

RAMPort

Bus Adapter

Bus Arbiter

SlaveAdapter

CPUPort

Bus Adapter

ASICPort

Bus

Memory

RAM


Page 18

VCC Performance SimulationEnabled through Architecture Services in VCC

SemProt_Send

A B

CPU Mem

RTOS

mutex_lock;memcpy;signal

Post(5)

write

busRequest

arbiterRequest/Release

busIndication

setEnabled

Value()

wait;memcpy;signal

read

SemaphoreProtected

busRequest

arbiterRequest/Release

busIndication

User Visible

SwMutexes

BusMasterSlaveAdapter

BusArbiter

MemoryAccessArchitecture Services

SemProt_Send SemProt_Recv

Pattern Services

VCC Performance Modeling …… the System Level extension of SDF !

IP BlockInterconnectPerformance

C++ C

Simulink

SDL

SPWStateCharts

IP BlockPerformance

PerformanceSystem

Level Library

VCC System Level Technology

∆ tInterleaver

FunctionC, C++,

SPW, SDL,Simulink,

Statecharts

Inter -ConnectCapacity

InterconnectPerformance

A B OUT0 0 10 1 01 0 01 1 0

Function

∆t

Performance

Classical Gate Level Technology

SDF andGate Level

Library


Page 19

Design Space Exploration… using Abstraction

Design Space Exploration From RTL through Gate Level options

Technology provider

– characterizes silicon technology for gates and interconnects

Synthesis Tools

– map constructs from RTL into registers and logic in between registers, does logic optimization

– explore the design space (“performance” – “area”) using gradient methods in a optimization process

Abs

trac

ted

from

Lay

out

SDFWire Load

synt

hesi

ze

SynthesisLibrary

RTLModels

Perfo

rman

ce

Area


Page 20

Design Space Exploration… through Function and Architecture

Abs

trac

ted

from

Lay

out

S D FWire Load

synt

hesi

ze

SynthesisLibrary

R T LModels

Per

form

ance

Area

Abstraction

MPEG

Vide

o Dec

oder

I/F

DMACPorts

Timers

MPEGAudio Decoder

GraphicsEngine

DRAM

Ctrl

Bus/C

ache

Contr

ol

Register File

uC

On- Chip Ram

D -Cach

e

I- Cache

Driver

RTOS

Tasks

IP Block PerformanceInterconnect Performance

RTLClusters

SWModels

abst

ract

inte

grat

e

Perf. ModelLibrary

Architecture

Functio

n

Opt

imal

Map

ping

Design Space Exploration using VCC… through Function and Architecture

SOC Silicon provider

– characterizes IP portfolio (typically in Integration Platforms) for intrinsic IP Block Performance and Inter IP Block Interconnect Performance

System Integrator and SOC Provider

– 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”

Abs

trac

ted

from

Lay

out

S D FWire Load

synt

hesi

ze

SynthesisLibrary

R T LModels

Per

form

ance

Area

Abstraction

MPEG

Vide

o Dec

oder

I/F

DMACPorts

Timers

MPEGAudio Decoder

GraphicsEngine

DRAM

Ctrl

Bus/C

ache

Contr

ol

Register File

uC

On- Chip Ram

D -Cach

e

I- Cache

Driver

RTOS

Tasks

IP Block PerformanceInterconnect Performance

RTLClusters

SWModels

abst

ract

inte

grat

e

Perf. ModelLibrary


Page 21

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

AnnotatedIP 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);}



FEC on CPU


FEC in slow HW


FEC in fast HWDelay Script




ScriptedDelayModel

InlineDelayModel


Page 22

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

MemoryAccess

CPU

Memory

RAM

RAMPort

Bus Adapter

Bus Arbiter

SlaveAdapter

CPUPort

Bus Adapter

ASICPort

Bus

Shared MemoryCommunication PatternSender Receiver

Post() from Behavior 1Value()/Enable() from Behavior 2

Standard CLibrary

RTOS

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


Page 23

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


Virtual MachineInstruction Set Model

LD,3.0 Load from Data MemoryLI,1.0 Load from Instr. Mem .ST,3.0 Store to Data MemoryOP.c,3.0 Simple ALU OperationOP.s,3.0OP.i,4.0OP.l,4.0OP.f,4.0OP.d,6.0MUL.c,9.0 Complex ALU OperationMUL.s,10.0MUL.i,18.0MUL.l,22.0MUL.f,45.0MUL.d,55.0DIV.c,19.0DIV.s,110.0DIV.i,118.0DIV.l,122.0DIV.f,145.0DIV.d,155.0IF,5.0 Test and BranchGOTO,2.0 Unconditional BranchSUB,19.0 Branch to SubroutineRET,21.0 Return from Subroutine


Page 24


char *event;int proc;if (*(event+proc) & 0x1: 0x0)... ld

ldopldliopts--br

tmp=b+cc=f(d)M

T update ∆

1

∆1

y=a*c+bM T update ∆2+∆3write B y

∆3

f6(y)M T update ∆4return

∆4

r=(s<<*a)a=r+m*x ∆2

tmp !tmp

�Whitebox Cdeclare ports

ANSI CInput

ld #event,R1ld #proc,R2add R1,R2,R3ld (R3),R4ldi #0x1, R5and R4, R5, R6cmp R0, R6, R7br R7, LTRUEba LFALSE

Assembler

VirtualProcessor

Model�Analyse

basic blockscompute delays

PerformanceEstimation

ArchitectureCharacterization

�Generate new C

with delay counts

�Compile

generated C andrun natively

Architectural Services Example


Page 25

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

Behavior PatternSender

BusMaster BusArbiter

BusSlave

ASIC Bus

Mem

Memory

Post


Page 26

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


Page 27

• 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

• Both the sender and receiver service direct the actions of architecture services to send/receive communication

Pattern Service

PatternSender

Post

PatternReceiver

Enabled/Value

Basic Example

• Let’s assume two behaviors.

• b1 and b2 talk to each other:

– b1 says Post; b2 says Value

– and visa versa


Page 28

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.


• Let’s assume the following architecture:


Page 29


• Here we map the behavior to the architecture:


• 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.


Page 30


• 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


• 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”.


Page 31

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.

Memory

BusArbiter

FCFSSlaveAdapter

SimpleMemory

TDMI_DataBus

FCFSBusAdapter

ASIC eCos

StandardCLibrary

SimpleCPU

CPUMemoryAccess

FCFSBusAdapter

Architecture

Service Example


Page 32

Architecture

Pattern

Sender Receiverb1 b2

Service Example (cont)

Sender PerspectiveMessage Sequence Charts


Page 33

Receiver PerspectiveMessage Sequence Charts

Commercial ExampleST Microelectronics

IP models support codesign effortsBy Benoit Clement

System-Level Design Engineer

Doha BenjellounSystem-Level Design Engineer

Co-Design Methodology for Systems &Architecture (CMSA)

STMicroelectronics, Grenoble, France

http://www.eetimes.com/story/OEG20010913S0069

Date post:	21-Jun-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Architectural Modeling in VCC EE 249 - Donald...

Documents