socintro_a5

8/13/2019 SoCintro_A5

1/55

System-on-Chip Design Introduction

Marcel JacometBern University of Applied Sciences

Bfh-TiHuCE-microLab, Biel/Bienne

[email protected]

February 20, 2012

Contents

1 SoC Introduction 1

1.1 Design Gap . . . . . . . . . . . . . . . . . . . . . 31.2 Y-Chart . . . . . . . . . . . . . . . . . . . . . . . 51.3 Processor Level . . . . . . . . . . . . . . . . . . . 71.4 System Level . . . . . . . . . . . . . . . . . . . . 141.5 Design Flow . . . . . . . . . . . . . . . . . . . . . 171.6 System Models . . . . . . . . . . . . . . . . . . . 361.7 System Platform . . . . . . . . . . . . . . . . . . 431.8 Tools. . . . . . . . . . . . . . . . . . . . . . . . . 451.9 Conclusion . . . . . . . . . . . . . . . . . . . . . 49

References 53

References 53


2/55

Introduction

c Marcel Jacomet, 2010-2012

All rights reserved. This work may not be translated or copied in

whole or in part without the written permission by the author, except

for brief excerpts in connection with reviews or scholarly analysis.

Use in connection with any form of information storage and retrieval,

electronic adaptation, computer software is forbidden. The slides of

this chapter are a copy of Gajskis transparencies with some minor

changes and some additional animations for didactical purposes. The

slides accompany his book Embedded System Design[GAGS09](which

is mandatory for this course) and contain some summary text notes.

Marcel Jacomet ii 2012


3/55

Introduction

1 Chapter: SoC Introduction

Marcel Jacomet 1 2012


4/55

Introduction

Chapter Introduction



5/55

Introduction

1.1 Design Gap

The basic needs for new system design methodologies are theincrease in complexity in parallel with the shorter product lifetime cycles. According to Moores Law, the circuit complexity,or the transistor count, is doubling every 2 years. This pre-diction has been made by Gordon Moore around 1965 and itis still valid. The increase in complexity and the shortening of

the product lifetime fosters the so called design gap. In order tofind an answer to these challenges, systematic design approachesbased on higher abstraction levels have to be introduced - notonly in the past and present, but also in the future. Such newdesign methodologies also have to be supported by Cadtools.

Design Gap

system design complexity is increasing

product lifetime is decreasing

design efficiency is essential

systematic design approaches are needed

higher abstraction levels are needed

leading to new design methodologies

newCadtools are needed:

tools have to implement design methodologies

tools have to handle large amount of data/simulation



6/55

Introduction

Moores Law



7/55

Introduction

The rising complexity ofAsics has forced the designer to goto higher abstraction levels. The Y-chart introduced by Gajskiin the early eighties allows us to clearly discuss differences be-tween design tools. The Y-chart model distinguishes between3 abstraction domains or views and four abstraction levels. Inthe following text design tools and methodologies are discussedwith reference to the Y-chart.

1.2 Y-Chart

Y-Chart



8/55

Introduction

3 design views

behavioral (function-ality)

structural (netlist)

physical (layout)

4 abstraction layers

system

processor

logic

circuit

4 to 5 component libraries

system (MoC, NoC)

processor (std, cus-tom)

ALUs (RFs, mem)

logic (standard, cells)

transistor

Behavioral Structural

Physical

systemprocessor

logic

circuit

processorcomponents

RTL

components

logiccomponents

transistorcomponents



9/55

Introduction

1.3 Processor Abstraction Level

On the processor level the processing elements (Pe) are defined.Pes can be described as algorithms, data flow graphs or finitestate machine data-path models on the behavioral domain.

Processor Abstraction Level

Processor level generates system components

computation components

standard processors

custom processors

custom functions

controllers

memories communication components

arbiters

bridges and transducers

controllers (interrupt, memory, Dma)

interfaces

Processor level synthesis

behavior specification (Fsmd, Cdfg,Is)

component structure

synthesis on processor level



10/55

Introduction

The finite state machine data-path model (Fsmd) is a veryconvenient way to describe Pes. AnFsmdis described as a setof states, linked with input conditions and a set of operationsexecuted in each state. One of the popularity ofFsmd is thefact that structured design approaches exist as it will be shownin a subsequent chapter.

FSMD Model

Fsmd

S1

S3

S2

x = |b| ; y = |b| x = (a b) + z

z = max(x, y)

Fsm

set of states and transitions transition executed under conditional statements of

input variables

Fsmd

Fsm + set of variable statements executed in eachstate

cycle accurate timing

Fsmddoes not directly represent programming languagecode but rather hardware designs



11/55

Introduction

Fsmddo not directly represent programming language codesbut rather hardware designs. On the other side, programminglanguage codes can easily be represented by control/data flowgraphs Cdfgconsisting of control flows (hereIfand loop) anddata manipulations packed into Bb blocks with several sequen-tial statements. A Cdfg can be converted to a Fsmd by as-signing a state for each controlIf and several states to eachBb.A Bb can thus be considered as a super state, needing one or

several clocks to execute.

CDFG Model

Control/Data Flow GraphCdfg

If statements and Loopstatements

basic blocks Bbs

reflects a programming lan-guage syntax as C

control dependencies betweenIfs anBbs

data dependencies inside Bbs

no data dependencies outsideBbs

BB2 BB3

BB1

ifyn

ifyn



12/55

Introduction

A processors behavior basically can be modeled by either anFsmd, a Cdfg or an instrucion set flow chart Is. Neverthe-less, the most adequate model is the instruction set flow chartwith its unique mnemonics grouping the processors behavior ina few basic macro instructions. The instruction set flow chartdescribes the fetch, decode and execute instruction stages. Dur-ing the fetch stage, the Instruction Register Ir is loaded withthe new instruction and the Program Counter Pc is incremented

thereafter. Type and mode of the instruction is detected in thedecode stage. Effective Addresses Ea are calculated for imme-diate, direct, relative and indirect address modes.

Instruction Set Flow Chart

super-stateFsmd

fetch, execute, ...states

each state has several as-signments

variable assignment

register assignment

memory loads andstores

each state may need severalclock cycles

IR M[PC]

misc. instr.branch instr.

register instr.

memory instr.immediate

direct

relative

indirect

L/S0123

L/S0123

RF[dest] M[PC]PC PC+1

L/S

Load

EA M[PC]RF[dest] M[EA]

PC PC+1

EA M[PC]M[EA] RF[src1]

PC PC+1

L/S1 0

Store

Load

EA M[PC]+RF[src2]RF[dest] M[EA]

PC PC+1AR M[PC]+RF[src2]

M[AR] RF[src1]PC PC+1

L/S1 0

Store

Load

EA M[M[PC]]RF[dest] M[EA]

PC PC+1

EA M[M[PC]]M[EA] RF[src1]

PC PC+1

L/S1 0

Store

Load



13/55

Introduction

Processing elements (Pe) can be microprocessors or appli-cation specific intellectual property Ip components. The con-trol structure at microprocessors is programmable and thus veryflexible by using address generator, program counter, programmemory and instruction register. In the case of a specific Ip,the control logic can be hard-wired, thus these control compo-nents my be replaced by other ones. Using an Fsm controller,the program counter is then called state register, the program

memory is then the output logic and the address generator isthen the next state logic. Using a specific custom processor,the controller will still have some programmability features andcould thus be built with a control memory Cmem instead of theprogram memory and with a control word register Cwinstead ofan instruction register. Here instead of storing instructions, theCmem directly stores the control words (see Nisc approach).

Processor Structural Model

datapath components

storage (registers, Rf, scratch pads, data memories

functional units (Alus, mul, shifters, special func-tions)

connection (buses, multiplexors, de-muxs, bridges)

controller components

registers (Pc, status register Sr, control word CworIr)

others (addr. generator Ag, control or programmemory)

processor structure

pipelining, chaining, multi-cycling, forwarding



14/55

Introduction

ALU MULAG Memory

RF / scratch pad

Status

PC CMem

CW

B3

B1

B2

const

offset

status

address



15/55

Introduction

The synthesis of standard or instruction set processors startswith manual design of the instructions. The reason for this man-ual design is to get the highest processor performance and mostcompact layout. The synthesis for custom processor elementsor custom Ips starts with the C code of the target applicationor algorithm which is usually transferred into a CdfgorFsmdmodel. The resulting final custom processor element is com-posed of a couple of components connected together as required

by the given behavioral model.

Processor Synthesis

BB2 BB3

BB1

ifyn

ifyn

ALU MULAG Memory

RF / scratch pad

Status

PC CMem

CW

B3

B1

B2

const

offset

status

address

processor

component + connection allocation

cycle accurate scheduling

variable bindingoperation binding

transfer binding

controller synthesis

model refinement

synthesis

standard processor: manual design of instructionset

custom processor: C code, algorithm design of tar-get appl.

several tasks: different sequences possible

different inputs, libraries, features, output

different tools, metrics, quality



16/55

Introduction

1.4 System Abstraction Level

On system level multi processes run in parallel, being imple-mented in hardware and software. A system model should thusmaintain the concept of states and transitions. The systemstates need to extend the computation to process and proce-dures written in programming languages like C/C++. As in asystem many processes run concurrently, we also need a synchro-

nization mechanism for data exchange like the channel conceptfor data encapsulation.

System Abstraction Level

on system level

many processors run concurrently

need of synchronization mechanism for data exchange(ex: channel concept for data encapsulation)

design of multi-core systems

computation components

communication components

synthesis

from behavior specification: MoCs (model of compu-tation)

to system architecture

with systemSwandHw

synthesis on system level



17/55

Introduction

An example model of a process state machinePsmwith hier-archical and parallel/sequential processes is shown. The systemstarts with process P1 which triggers P2 if condition dis true, orif not, it triggers another super-process with the processes P3,P4 and P5. P3 and P4 run sequentially and in parallel with P5,indicated by the dashed line. The execution is finished, wheneither P2 or the P3, P4, P5 block is finished.

System Behavioral Model

many different MoCs

process-based models

state-based models

universal model

process state machine(Psm)

processes

sequential/parallel,hierarchical

channels

message passing

P2

P1

P4

P3

P5

C2

C1

d

d



18/55

Introduction

A system structural model is a netlist or block diagram ofsystem components. Processing elements (Pe) are microproces-sors, custom processors or IPs. Communication elements Ceare buses and routers. Bridges are used if a conversion betweenCpuandIPare needed and arbiters if buses are shared.

System Structural Model

set of computational components

processors, IPs, custom HW components

memories

set of communication components

buses, bridges, arbiters, transducers, interfaces

P3 P4

HW

P1 P2

CPU

C1, C2 C1, C2Arbiter

Bridge

Mem

P5

CPU bus IP bus



19/55

Introduction

1.5 Design Flow

The system level synthesis from behavioral to structural modelstarts with profiling the application code and collecting statisticsabout performance, cost, bus traffic, memory usage, power con-sumption and others. These statistics are then used as designmetrics to optimize the platform and application code. Next, incomponent and connection allocation, library components are

connected and if needed new components generated. It is alsopossible to start with a completely defined platform and upgrad-ing it. Processes are then assigned toPes, variables to memoriesand channels to buses and other hardware links. In this step anoptimization in respect to the design metrics is done, requir-ing a careful partitioning of processes, variables and connectiontraffic. Interface components If have to be inserted. Devicedrivers, routing, messaging and interrupt controllers are suchsystem firmware Sw Ifs, Transducers, interrupt and memory

controllers are Hw If examples. Processes running in parallel onthe samePehave now to be scheduled statically or dynamically,thus an Rtos has to be introduced for dynamical scheduling.Finally, all platform decisions are used to refine the behavioralmodel into a structural model and newly synthesized Hw andSw If are added. The structural model can now be verified bysimulation or formal verification. For cycle-accurate simulation,functional models have to be replaced by cycle-accurate struc-tural models for each custom component and by instruction-set

(Is) models for standard microprocessors. Further refinementleads to cycle-accurateRtlmodels of custom processors andIfcomponents.

System Synthesis



20/55

Introduction

P2

P1

P4

P3

P5

C2

C1

d

d

P 3 P4

HW

P 1 P2

CPU

C1, C2 C1, C2Arbiter

Bridge

Mem

P5

CPU bus IP bus

system

profiling + estimation

component allocation

connection allocationprocess + channel binding

SW/HW IF definition

scheduling

model refinement



21/55

Introduction

several tasks: different sequences possible

different MoCs, libraries, features, platforms

different tools, metrics, quality

profiling

design metrics for platform optimization

performance, power, cost, bus traffic, memory usage...

binding

process to PE, variables to memories

channels to busess and other links SW/HW IF interface

device drivers, routing, messaging

interrupt controllers, transducers

scheduling

processes on same PE need scheduling

introducing RTOS

refinement

functional models replaced by cycle-accurate struct.models

cycle-accurate replaced by RTL models of customPE, IF



22/55

Introduction

Evolution of Design Flow

three evolutionary design flows

capture and simulate

designers complete design and validation throughsimulation

describe and synthesize

introduction of design for synthesis

for given functionality, design structure gener-ated by tools

specify-explore-refine

system design flow extended to four levels large number of levels and metrics for validation

design flow performed in several steps

each step follows describe-and-synthesis concept



23/55

Introduction

Between the 1960s and 1980s hardware and software wasdeveloped separately, leading to the so called System Gap. Soft-ware designers developed some algorithms and later on wrotethe requirement documentation or specification. Thereafter thehardware designers used this specification to develop a blockdiagram. They did not know if their design met the specifica-tion until a gate-level design was produced. As the developmentwas dominated by netlist capturing and simulation, it gave the

design flow its name. The myth that a specification is nevercomplete was born at those times, as the gate-level design sel-dom reflected specification and thus had to be adapted. Thefact that designers waited for the gatel-level design before ver-ifying the system, specification was the main obstacle to closethe system gap between Sw and Hw or between specificationand implementation. There were too many of abstraction levelsinbetween.

Capture-and-Simulate Design Flow



24/55

Introduction

system designers generate

preliminary specification

basic algorithms

no software design

HW designers generate

architecture, RTL, logic logic-level netlist for simu-

lation and capturing

simulate and optimize

system gap between HW andSW

simulation at the end of a de-

sign

manual design, no automation

myth: spec is never completedue to gate-level design itera-tion:designers wait until gate-levelfinished for system spec verifi-cation

Capture &Simulate

SW?

1960s - 1980s

Specs

Algorithms

Design

Logic

Physical

Manufacturing

System Gap

Simulate



25/55

Introduction

New synthesis tools have significantly altered the design flowin the 1980s. On the logic-level now both behavioral and struc-tural models could be described. Designers first described theirdesigns by means of Boolean equations and Fsm descriptionsand thereafter synthesized it into logic-level netlists. This de-sign flow change was a huge evolution step as both, behavioraland structural models, could now be simulated, which was alarge improvement in the verification step. In this period the

register-transfer-level Rtl of abstraction has been introduced,allowing cycle-accurate simulation and synthesis. The systemgap has therefore been reduced, but still existed.

Describe-and-Synthesize Design Flow



26/55

Introduction


preliminary specification

basic algorithms

SW design after HW de-sign

HW designers generate

architecture, RTL, logic

synthesis tools generate logic

designers simulate and op-timize

simulation before and after syn-thesis

designers describe functionality,tools synthesize structure

system gap still persists

simulation of behavioral andstructurel model

RTL level introduced for cycle-

accurate sim

Describe &Synthesize

SW?

1980s - 2000s

Specs

Algorithms

Design

Logic

Physical

Manufacturing

Describe

Simulate



27/55

Introduction

The only way to eliminate the system gap is to further in-crease the abstraction level to the system level and, last butnot least, to include bothHwandSwinto the design flow. Anexecutable specification on the system level Sl is the startingpoint in this new design methodology and represents the systembehavior. The methodology is extended by different models rep-resenting different details of the design decisions. The modelsare used to include different system properties, like functionality,

communication, synchronization, performance, power and so on.Each model can be used as a specification to develop the nextlevel models whereas more implementation information is addedafter more design decisions are made. This new design method-ology is often called specify-explore-refine (Ser) design flow. InSerdesigners first specify their intent, then explore possibilitiesand finally refine the model according their decisions.

Specify-Explore-Refine Design Flow



28/55

Introduction

application designers generate

executable specification

application algorithms

platform model for applica-tion/platform optimization


detailed architecture and net-work

SW and HW components

logic and layout

many design levels and models

many metrics for validation

SER solution: step-by-step strategy

for each model explore design de-cisions

refine model after exploration

refined model = specification forthe next level

models include diff system properties functionality, performance

communication, synchronization

Specify, Explore& Refine

2000s - 2020?

ExecutableSpec

Algorithms

Architecture

Network

SW/HW

LogicPhysical

Manufacturing

Functionality

Algorithms

Connectivity

Protocols

Performance

Timing



29/55

Introduction

Evolution of Design: Summary

concept of describe-and-synthesize was not upgradedadequately to system level

Capture &Simulate

SW?

1960s - 1980

Specs

Algorithms

Design

Logic

Physical

Manufacturing

System Gap

Simulate



30/55

Introduction

In order to find a suitable Ser design methodology, exist-ing design flows have to be analyzed by their advantages andshortcomings.

In Search of a Solution

semantics issue in description language

modeling languages do not reflect design decisions

modeling languages do not reflect implementation

models are ambiguous for synthesis and verification

better model formalism needed

definition of set of models

definition of model composition relation between design decision and model transfor-

mation

automatic model refinement and generation

model automation

automatic metric estimation



31/55

Introduction

Introducing system level abstraction implies introducing moremodels. Clear model semantics are thus crucial. Models writ-ten in hardware description languages, like Vhdl or SystemCcan be simulated, but have some drawbacks at using them forsynthesis. Due to unclear semantics, they can result in ambi-guities that make automated synthesis and verification impossi-ble, thus only a well defined subset of the languages should beused. The caseconstruct, which can be found in any Hdlcom-

prises some implementation ambiguities: it can either be usedto model an Fsm or a look-up table, where every case wouldbe a state or a variable, respectively. Unfortunately Fsms andlook-up tables require completely different implementations, us-ing registers with logic in the first, and memory in the latter. Toconclude, a model which uses thecaseto modelFsms and tablesis good for simulation but not for implementation as it cannot bedetermined which structure was described by the model. Someform of formalism has to be introduced to models and modelinglanguages in order to have well-defined semantics.

Missing Semantics in Languages

ambiguous semantics for hardware and system languages

describes functionality, but not implementation

same model may represent two completely different

implementations

simulatable but not synthesizable or verifiable

needs stricter semantics, describing design decisions



32/55

Introduction

controller memory

finite state machine look-up table

1.4142

7.5672

case X iswhen X1=>

.

.

.

when X2=>



33/55

Introduction

Clear semantics for the different models as well as modeltransformation rules are necessary. Every model is a set of ob-

jects and composition rules, as for example is the case in classicalalgebra. With algebra we can also describe a models structure,like hierarchy, parallelisms or sequentialism. The expression onthe left shows the need of one multiplier and one adder. Theexpression may need 2 clock cycles to complete, by executingthe addition and multiplications sequentially. Using the alge-

bra rules it is clear that this equation is identical with the oneon the right side, where 2 multipliers and one adder is needed,executing the operation in 2 clock cycles as well. In case weare limited to 1 multiplier, the execution time would be 3 cy-cles. The equivalence of such arithmetic algebraic expressionsallows the designer two perform model transformations and op-timizations for some design metrics using algebra rules. Similarto the arithmetic algebra we can also define model algebra de-scribing objects and composition rules. The most importantelements here are processes and communication channels. Withthe composition rules of model algebra we can compose objectshierarchically, sequentially and parallel. If we decide that theprocesses P1 and P2 run on process element PE1 and processP3 run on process element PE2, the sequential dependency ofPE1 to PE3 as seen on the left side can be modeled by a com-munication channel synchronizing the 2 processes such that P3only starts execution after P1 is finished.

Model Algebra



34/55

Introduction

with model transformation we can describe:

parallel, sequential, hieararchy

model algebra:

arithmetic algebra: a (b+c) = a b+a c

arithmetic algebra allows creation of expressions andproving their equivalences

P2 P3

P1

P2

P1

P3

PE1 PE2

model algebequivalence



35/55

Introduction

The specify-explore-refine methodologies may use model al-gebra to perform the model transformation after each step ofdesign decisions. After some design exploration, design deci-sions are made, followed by a model transformation using modelalgebra to preserve execution equivalence. A model transforma-tion usually replaces one object by several objects or does are-composition of objects. Applying Sermethodology to a sys-tem specification we generate several intermediate models and

finally may end up with a cycle-accurate implementation model.

Specify-Explore-Refine Methodology

SER

sequence of models generatedthrough a sequence of design de-

cisions

each design decision requires amodel transformation

transformations generate modelrefinement

model refinement requires objectreplacemenet or re-composition

system specificationmodel

SER

cycle accurateimplementation model

intermediate models

design decisions

model refinement

replacement orrecompilation



36/55

Introduction

A good compromise is needed to define the right numberof models. One model per abstraction level and design met-ric results in too many, and possible incompatible models. Onemodel for several hierarchies may result in a too complex model.A good solution may be to stick number of models to the dif-ferent types of designers: application designer, system designerand implementation designer, resulting in a specification modelSm, a transaction-level model Tlm and a cycle-accurate model

Cam. With an executable specification model the designer canshow that his algorithm runs correctly. Once a platform is de-fined, optimizations can be done by channel partitioning, map-ping and scheduling. Adding new features and functions canalso be done with this model, even when the product is alreadyimplemented on a target technology. The system designer usesthe transaction-level model to estimate design metrics such ascost, performance, communication traffic or power consumption.With the Tlm model he can explore different implementationslike different component selections, connectivity, interfaces andoperating systems. Finally the cycle-accurate model is usedby hardware designers to verify the correct functionality of thegenerated system hardware components (custom processors, in-terfaces, interrupt controllers, bridges, etc). System softwaredesigners use the model to verify firmware, i.e. task schedul-ing, data transfer, synchronization etc. With the technologyadvances, the differentiation between hardware and software is

blurring. Algorithms executed in software today can be imple-mented in hardware tomorrow. The models presented supportthis technology shift.

Necessary Models, Platforms and Tools

design flow with 3 types of designers

application designers



37/55

Introduction

system designers

implementation designers

design flow with 3 design models

executable specification model (SM)

transaction-level model (TLM)

cycle-accurate model (CAM)

platform with 4 component types

processing components

storage components


interface components

environment with 4 types of tools

metric evaluation with estimation tool

design decisions with synthesis tool

model generation with refinement tools

validation with simulation/Verification tool



38/55

Introduction

1.6 System Models

The system model includes application code and system require-ments. The application code is defined in the form of a processstate machinePsm. The model is used to specify the applicationalgorithm and later on to optimize application code for mappingto a platform. In the design phase of defining the system model,the application algorithm must be broken down into processes

and communication channels. The goal must be to balance thechannel traffic that will optimize the local communication andminimize the long-distance data transfers after platform map-ping. Further on, the processes must be grouped and mappedto processing elements which offer the best structure to executethem optimally. Restructuring the code, mapping and schedul-ing is often an iterative design step to find an optimal solution.

System Specification Model (SM)



39/55

Introduction

SM specifies application algorithm

SM includes application code and system require-ments

SM is for platform mapping and optimization

SM uses a MoC (such as PSM)

SM is an executable specification processes and communication

SM synthesis

break down into processes and communicationchannels

balance channel traffic

mapping processes to PEs, scheduling

exploring design space using metrics

iterative design step



40/55

Introduction

The platform architecture can partially be defined by theSm or completely be generated by the synthesis process. It isnot uncommon, that additional components or communicationchannels are added after the synthesis step for some metric op-timization. During synthesis, process are mapped to processingelements, variables are mapped to local or global memories andchannels are mapped to routes, consisting of buses and bridges.The platform with its mapped processes and channels defines the

system structure after manual or automatic system synthesis.Such system structures are usually modeled with a transaction-level model (Tlm). A Tlm basically reflects the structure ofthe system but adds bus interfaces and combines channels intobuses. In our example, channels C1 and C2 use the Cpu busandIpbus through a bridge who converts theCpu andIppro-tocols to each other. In addition, the operating systemOs andcommunication drivers for the bus reside on the Cpu. A Tlmmodel can be timed or un-timed. For a timedTlm model theapplication code and its processing element need to be profiledto estimate its execution time. In addition, the time needed tosend messages through their communication routes need to beestimated as well. A Tlm is used to explore the different Smwith different platforms and different mappings. A Tlmallowsfast simulation by using a reasonable model precision for theneeded profiling. A Tlm serves for the exploration of the plat-form structure and estimation of the system metrics. A Tlmis

a system level model.

System Transaction-Level Model (TLM)



41/55

Introduction

TLM for platform structure exploration

application algorithms

design metrics

reflect platform structure, combines channels tobuses, add bus interfaces, adds OS/drivers

TLM with different details

network TLM, protocol TLM

TLM is a system level model

models

CPU: processes, OS

IP, HW: processes

bus: bus model

TLM

timed or un-timed

profiling code

profiling HW

profiling message through communication routes

P1 P3

OS

CPU

Mem

CPU Bus IP Bus

Bridge

P2 P4

HW

P5

IP



42/55

Introduction

In order to generate a prototype, the system level abstractionmodel of a Tlm has to be lowered to the processor level ofabstraction, resulting into a cycle-accurate model (Cam) for theentire system. By refining the functionality of each componentof aTlm model we can find aCam or Rtlmodel of the system.Thus for custom hardware and interface components we need aprocessor-level synthesis,Ip functional descriptions are replacedby theirRtldescriptions from libraries. Standard processes are

replaced by theirRtlor Is models to run the compiled code. ACammodel must include Rtos and drivers as well.

System Cycle-Accurate Model (CAM)



43/55

Introduction

CAM is for cycle-accurate exploration and design

CAM is processor level model

CAM is for input to RTL tools

ASIC design

FPGA design

CPU model

compiled binary

inserted RTOS

HAL RTL

IP and HW model

process RTL

IF RTL

memory model

controller RTL

IF RTL

bus model

arbiter, IC, bridge & IF RTL



44/55

Introduction

Bridge

IP



45/55

Introduction

1.7 System Platform

The basic platform components are processing components, stor-age components, communication components and interface com-ponents (besides analog components for mixed-mode designs).Todays platforms may have multiple processing and commu-nication components. Also more complicated communicationcomponents like transducers are used to perform the message

routing as seen in networks-on-chips (NoCs). System synthesisis only possible as long as the component and platform struc-ture variety is limited. Using only the above 4 component types,system synthesis is possible.

System Platform Architecture

processing components (PEs)

standard and custom processors

storage components

local and global memories


bridges, transducers

NoCs

interface components

arbiters

controllers

DMAs, UARTs

limitation to 4 basic components fosters system synthe-sis



46/55

Introduction

PE2A(master)

PE2B(slave)

PE3A

memory 3

IF

biter 2

transducer 2-3

arbiter 3

bus 2 bus 3

2

int2.1

int2.2



47/55

Introduction

1.8 Tools and Environments

An automatic model refinement can be obtained in the specify-explore-refine methodology as long as there exists a sequence oftransformations for every design decision. Using a model alge-bra, a verify tool can verify execution equivalence between thetwo models after every refinement step. With a simulation theuser can validate his new model. The user makes the design

decisions with Gui tool, based on profiling results of differentmetrics from the estimation tool and based on available com-ponents. Such a design environment can easily be implementedas long as the abstraction levels of model A and B do not dif-fer significantly. For our specify-explore-refine methodology wehave identified 3 types of models Sm, TlmandCam.


mode A to model B refine-mement

estimation tool formetrics

synthesis tool for de-sign decisions

refinement tool for

transformations verify tool for model

equivalence

simulation tool tovalidation model

component library formodel refinement

GUI for manual over-

ride of synthesis tool

componentlibrary

GUIsynthesis

tool

estimationtool refinement

tool

verifytool

simulationtool

model A

model B



48/55


49/55

Introduction

For our specify-explore-refine methodology we have identi-fied 3 types of models Sm,Tlmand Cam. This means we needtwo tools as described above for the refinement steps between the3 different models: (a) A front-end tool for the application de-velopers to capture the system behavior in a high level languagesuch as C/C++, SystemC, Matlab, UML or similar. The front-end tool is used to test an application idea with a system modeland to refine it to a transaction-level model using platform ar-

chitecture. Exploring the design space, the tool thus generatesa functional or timed Tlm. (b) A back-end tool for implement-ing the system with all Hw and Sw details given the definedplatform. Starting from aTlm description, the tool outputs aCamof the system in Hdl for theHw and an instruction setIsmodel for custom processors. A co-simulation of bothHdl/Ismodels can be used for verification at the micro-architectureabstraction level. The obtained Rtl descriptions can now besynthesized with Rtl tools to get the logic circuit for placingand routing on a chip. The compiled and linked Sw can bedownloaded on the selected processors of the SoCplatform.




50/55

Introduction

front-end

for application devel-opers(C/C++, SystemC,Matlab)

for testing productconcepts

(application ideas) explore design space

back-end

micro-architectureabstraction-level

for SW and HW de-velopment

product prototyping

SoC implementation

prepare for fab

synthesis for gate-level

place and route

compile code for SW

TIMED

CYCLEACCURATE

Create

Select

Partition

Map

Compile

Replace

Compile

Debug

Simulate

Verify

Compile

Check

Simulate

Verify

application tools:compilers/debuggers

commercial tools:FPGA/ASIC place & route

DecisionUser

Interface

ValidationUser

Interface

System Capture &

Platform Development

SW Development &

HW Development

Front-End

Back-End

SM

TLM

CAM



51/55

Introduction

1.9 Conclusion

The past has shown, that simplifying a model always fostersan improvement in productivity: as a first example was the re-striction of the number of elements on chip to Nfet andPfettransistors and combining them to Cmos logic gates. Com-pared to all available circuit types like resistor-transistor-logic,transistor-transistor-logic and diode-transistor-logic this was an

effective simplification. Later on, the restriction to standard-celldesign techniques with its layout routing channels was anothermajor step in design productivity improvement. More recentlywe have observed the abstraction from logic gates to Fsms anddata paths which opened the path for first micro-architecturelevel synthesis tools. It is only natural to continue this moveto higher abstraction levels and thus simplifying the underly-ing models. Another observation will have a big impact to theengineering education: the fact that application algorithms can

either be implemented inSw or Hw, brings the two engineeringdisciplines together and may even merge them in the future.

Conclusion

embedded system synthesis! Does it exist?

well-defined models, decisions, transformations, re-

finements worked in the past: layout, logic, RTL

system level complexity simplified (nfet, std cell, ...)

extreme makeover is necessary for this new paradigm

SW = HW = SoC = embedded systems

simulation based only flow is not acceptable

design methodology must be based on scientific prin-

ciples



52/55

Introduction

benefits

large productivity gain

easy design management

easy derivatives and shorter time-to-market

what is next?

change to more structured system design application oriented EDA

merging SW and HW development & education



53/55

Introduction

abbreviation explanationAg address generatorAlap as late as possibleAsap as soon as possibleBb basic blockBcam bus cycle-accurate modelBfm bus-functional modelCam cycle-accurate model

Ccam computation cycle-accurate modelCcs communication systemCdfg control-data flow graphCe communication elementCla carry-lookahead adderCMem control memoryCpa carry-propagate adderCsa carry-save adderCsp communicating sequential processCw(r) control word (register)Dfg data flow graphDut device under testEdf earliest deadline first (scheduling policy in RTOS)Fsm finite-state-machineFsmd finite-state-machine with data-pathHal hardware abstraction levelHcfsm hierarchical concurrenzt FSM

Hdl hardware description languageHls high-level synthesisHw hardwareIr instruction registerIs instruction setIsr interrupt service routineIss instruction set simulatorIp intellectual property (hardware component)If interface component

Kpn Kahn process network



54/55

Introduction

abbreviation explanationMac media access (layer)MoC model of computationMPSoC multiple processor system-on-chipNoC network-on-chipPc program counterPe processing elementPMem program memory

Psm process state machineRc ressource constrained (scheduling)Rf register fileRm rate monotonic (scheduling policy in RTOS)Rpc remote procedure callSdf synchronous data flowSldl system-level design languageSer specify-explore-refine (design methodology)Sfsmd super FSM with datapathSldl system-level design languageSm specification modelSoC system-on-chipSr status registerSw softwareTc time constrainedTlm transaction-level modelUml unified modelling language



55/55

Introduction

References

[GAGS09] Daniel D. Gajski, Samar Abdi, Andreas Gerstlauer,and Gunar Schirner.Embedded System Design: Mod-eling, Synthesis and Verification. Springer Verlag,2009. Isbn-10 1441905030.

[GZGZ00] Daniel D. Gajski, Jianwen Zhu, Andreas Gerstlauer,and Shuqing Zhao.SpecC: Specification language andMethodology. Kluwer Academic Publishers, 2000.

socintro_a5

Documents