System-on-Chip Design Introduction

Marcel Jacomet Bern University of Applied Sciences Bfh-Ti HuCE-microLab, Biel/Bienne

Marcel.Jacomet@bfh.ch

February 20, 2012

Contents
1 SoC Introduction 1.1 Design Gap . . . 1.2 Y-Chart . . . . . 1.3 Processor Level . 1.4 System Level . . 1.5 Design Flow . . . 1.6 System Models . 1.7 System Platform 1.8 Tools . . . . . . . 1.9 Conclusion . . . References References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 5 7 14 17 36 43 45 49 53 53

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

Introduction

Chapter: SoC Introduction

Marcel Jacomet

2012

Introduction Chapter Introduction

Marcel Jacomet

2012

Introduction

1.1

Design Gap

The basic needs for new system design methodologies are the increase in complexity in parallel with the shorter product life time cycles. According to Moores Law, the circuit complexity, or the transistor count, is doubling every 2 years. This prediction has been made by Gordon Moore around 1965 and it is still valid. The increase in complexity and the shortening of the product lifetime fosters the so called design gap. In order to nd an answer to these challenges, systematic design approaches based on higher abstraction levels have to be introduced - not only in the past and present, but also in the future. Such new design methodologies also have to be supported by Cad tools. Design Gap system design complexity is increasing product lifetime is decreasing design eciency is essential systematic design approaches are needed higher abstraction levels are needed leading to new design methodologies new Cad tools are needed: tools have to implement design methodologies tools have to handle large amount of data/simulation

Marcel Jacomet

2012

Introduction

Moores Law

Marcel Jacomet

2012

Introduction The rising complexity of Asics has forced the designer to go to higher abstraction levels. The Y-chart introduced by Gajski in the early eighties allows us to clearly discuss dierences between design tools. The Y-chart model distinguishes between 3 abstraction domains or views and four abstraction levels. In the following text design tools and methodologies are discussed with reference to the Y-chart.

1.2

Y-Chart

Y-Chart

Marcel Jacomet

2012

Introduction 3 design views behavioral (functionality) structural (netlist) physical (layout) 4 abstraction layers system processor logic circuit 4 to 5 component libraries system (MoC, NoC) processor (std, custom) ALUs (RFs, mem) logic (standard, cells) transistor Physical Behavioral
system processor logic circuit

Structural
processor components RTL components logic components transistor components

Marcel Jacomet

2012

Introduction

1.3

Processor Abstraction Level

On the processor level the processing elements (Pe) are dened. Pes can be described as algorithms, data ow graphs or nite state 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 arbiters bridges and transducers controllers (interrupt, memory, Dma) interfaces

communication components

Processor level synthesis behavior specication (Fsmd, Cdfg, Is) component structure synthesis on processor level

Marcel Jacomet

2012

Introduction The nite state machine data-path model (Fsmd) is a very convenient way to describe Pes. An Fsmd is described as a set of states, linked with input conditions and a set of operations executed in each state. One of the popularity of Fsmd is the fact that structured design approaches exist as it will be shown in a subsequent chapter. FSMD Model
x = |b| ; y = |b| x = (a b) + z

S1 S3
z = max(x, y )

S2

Fsmd

Fsm set of states and transitions transition executed under conditional statements of input variables Fsmd Fsm + set of variable statements executed in each state cycle accurate timing Fsmd does not directly represent programming language code but rather hardware designs

Marcel Jacomet

2012

Introduction Fsmd do not directly represent programming language codes but rather hardware designs. On the other side, programming language codes can easily be represented by control/data ow graphs Cdfg consisting of control ows (here If and loop) and data manipulations packed into Bb blocks with several sequential statements. A Cdfg can be converted to a Fsmd by assigning a state for each control If and several states to each Bb. A Bb can thus be considered as a super state, needing one or several clocks to execute. CDFG Model Control/Data Cdfg Flow Graph

If statements and Loop statements basic blocks Bbs reects a programming language syntax as C control dependencies between Ifs an Bbs data dependencies inside Bbs no data dependencies outside Bbs
n BB2 if BB1

y BB3

if

Marcel Jacomet

2012

Introduction A processors behavior basically can be modeled by either an Fsmd, a Cdfg or an instrucion set ow chart Is. Nevertheless, the most adequate model is the instruction set ow chart with its unique mnemonics grouping the processors behavior in a few basic macro instructions. The instruction set ow chart describes the fetch, decode and execute instruction stages. During the fetch stage, the Instruction Register Ir is loaded with the new instruction and the Program Counter Pc is incremented thereafter. Type and mode of the instruction is detected in the decode stage. Eective Addresses Ea are calculated for immediate, direct, relative and indirect address modes. Instruction Set Flow Chart

IR M[PC]

super-state Fsmd fetch, states execute, ...

L/S 3210 misc. instr. register instr. branch instr. L/S memory instr. 3210 indirect direct L/S 1 0 Load RF[dest] M[PC] PC PC+1

immediate L/S

each state has several assignments variable assignment register assignment memory stores loads and
L/S 1 0 relative L/S 1 0

Load

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

EA M[PC] Store M[EA] RF[src1] PC PC+1

Load

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

AR M[PC]+RF[src2] Store M[AR] RF[src1] PC PC+1 EA M[M[PC]] RF[dest] M[EA] PC PC+1

each state may need several clock cycles

Load

EA M[M[PC]] Store M[EA] RF[src1] PC PC+1

Marcel Jacomet

10

2012

Introduction Processing elements (Pe) can be microprocessors or application specic intellectual property Ip components. The control structure at microprocessors is programmable and thus very exible by using address generator, program counter, program memory and instruction register. In the case of a specic Ip, the control logic can be hard-wired, thus these control components 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 is then the next state logic. Using a specic custom processor, the controller will still have some programmability features and could thus be built with a control memory Cmem instead of the program memory and with a control word register Cw instead of an instruction register. Here instead of storing instructions, the Cmem 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 functions) connection (buses, multiplexors, de-muxs, bridges) controller components registers (Pc, status register Sr, control word Cw or Ir) others (addr. generator Ag, control or program memory) processor structure pipelining, chaining, multi-cycling, forwarding

Marcel Jacomet

11

2012

Introduction

const CMem CW PC B2 B1

RF / scratch pad

offset status address Status AG ALU MUL Memory

B3

Marcel Jacomet

12

2012

Introduction The synthesis of standard or instruction set processors starts with manual design of the instructions. The reason for this manual design is to get the highest processor performance and most compact layout. The synthesis for custom processor elements or custom Ips starts with the C code of the target application or algorithm which is usually transferred into a Cdfg or Fsmd model. The resulting nal custom processor element is composed of a couple of components connected together as required by the given behavioral model. Processor Synthesis
operation binding variable binding transfer binding cycle accurate scheduling controller synthesis model refinement

component + connection allocation

processor

BB1
const RF / scratch pad B2 B1 CW Status PC

n BB2

if

y BB3

CMem

offset AG

if

status address

ALU

MUL

Memory

synthesis

B3

standard processor: manual design of instruction set custom processor: C code, algorithm design of target appl. several tasks: dierent sequences possible dierent inputs, libraries, features, output dierent tools, metrics, quality

Marcel Jacomet

13

2012

Introduction

1.4

System Abstraction Level

On system level multi processes run in parallel, being implemented in hardware and software. A system model should thus maintain the concept of states and transitions. The system states need to extend the computation to process and procedures written in programming languages like C/C++. As in a system many processes run concurrently, we also need a synchronization mechanism for data exchange like the channel concept for 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 specication: MoCs (model of computation) to system architecture with system Sw and Hw synthesis on system level

Marcel Jacomet

14

2012

Introduction An example model of a process state machine Psm with hierarchical and parallel/sequential processes is shown. The system starts with process P1 which triggers P2 if condition d is true, or if 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 nished, when either P2 or the P3, P4, P5 block is nished. System Behavioral Model many dierent MoCs process-based models state-based models universal model process state machine (Psm) processes sequential/parallel, hierarchical channels message passing
P1 d P2 P4 C2 d P3 C1 P5

Marcel Jacomet

15

2012

Introduction A system structural model is a netlist or block diagram of system components. Processing elements (Pe) are microprocessors, custom processors or IPs. Communication elements Ce are buses and routers. Bridges are used if a conversion between Cpu and IP are 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
CPU P1 P2 Mem

Arbiter

CPU bus

Bridge

C1, C2

C1, C2

IP bus

P3 HW

P4

P5

Marcel Jacomet

16

2012

Introduction

1.5

Design Flow

The system level synthesis from behavioral to structural model starts with proling the application code and collecting statistics about performance, cost, bus trac, memory usage, power consumption and others. These statistics are then used as design metrics to optimize the platform and application code. Next, in component and connection allocation, library components are connected and if needed new components generated. It is also possible to start with a completely dened platform and upgrading it. Processes are then assigned to Pes, variables to memories and channels to buses and other hardware links. In this step an optimization in respect to the design metrics is done, requiring a careful partitioning of processes, variables and connection trac. Interface components If have to be inserted. Device drivers, routing, messaging and interrupt controllers are such system rmware Sw Ifs, Transducers, interrupt and memory controllers are Hw If examples. Processes running in parallel on the same Pe have now to be scheduled statically or dynamically, thus an Rtos has to be introduced for dynamical scheduling. Finally, all platform decisions are used to rene the behavioral model into a structural model and newly synthesized Hw and Sw If are added. The structural model can now be veried by simulation or formal verication. For cycle-accurate simulation, functional models have to be replaced by cycle-accurate structural models for each custom component and by instruction-set (Is) models for standard microprocessors. Further renement leads to cycle-accurate Rtl models of custom processors and If components. System Synthesis

Marcel Jacomet

17

2012

process + channel binding connection allocation SW/HW IF definition component allocation scheduling profiling + estimation system

Introduction

model refinement

CPU P1 P2

Mem

Arbiter

CPU bus

Bridge

P1 d P2

P3

C1 P5

C1, C2

C1, C2

IP bus

P4

C2

P3 HW

P4

P5

Marcel Jacomet

18

2012

Introduction several tasks: dierent sequences possible dierent MoCs, libraries, features, platforms dierent tools, metrics, quality

proling design metrics for platform optimization performance, power, cost, bus trac, 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 renement functional models replaced by cycle-accurate struct. models cycle-accurate replaced by RTL models of custom PE, IF

Marcel Jacomet

19

2012

Introduction

Evolution of Design Flow three evolutionary design ows capture and simulate designers complete design and validation through simulation describe and synthesize introduction of design for synthesis for given functionality, design structure generated by tools specify-explore-rene system design ow extended to four levels large number of levels and metrics for validation design ow performed in several steps each step follows describe-and-synthesis concept

Marcel Jacomet

20

2012

Introduction Between the 1960s and 1980s hardware and software was developed separately, leading to the so called System Gap. Software designers developed some algorithms and later on wrote the requirement documentation or specication. Thereafter the hardware designers used this specication to develop a block diagram. They did not know if their design met the specication until a gate-level design was produced. As the development was dominated by netlist capturing and simulation, it gave the design ow its name. The myth that a specication is never complete was born at those times, as the gate-level design seldom reected specication and thus had to be adapted. The fact that designers waited for the gatel-level design before verifying the system, specication was the main obstacle to close the system gap between Sw and Hw or between specication and implementation. There were too many of abstraction levels inbetween. Capture-and-Simulate Design Flow

Marcel Jacomet

21

2012

Introduction system designers generate preliminary specication basic algorithms no software design HW designers generate architecture, RTL, logic logic-level netlist for simulation and capturing simulate and optimize
System Gap SW? Design
Simulate

Capture & Simulate Specs Algorithms

system gap between HW and SW simulation at the end of a design manual design, no automation myth: spec is never complete due to gate-level design iteration: designers wait until gate-level nished for system spec verication

Logic Physical Manufacturing 1960s - 1980s

Marcel Jacomet

22

2012

Introduction New synthesis tools have signicantly altered the design ow in the 1980s. On the logic-level now both behavioral and structural models could be described. Designers rst described their designs by means of Boolean equations and Fsm descriptions and thereafter synthesized it into logic-level netlists. This design ow change was a huge evolution step as both, behavioral and structural models, could now be simulated, which was a large improvement in the verication step. In this period the register-transfer-level Rtl of abstraction has been introduced, allowing cycle-accurate simulation and synthesis. The system gap has therefore been reduced, but still existed. Describe-and-Synthesize Design Flow

Marcel Jacomet

23

2012

Introduction system designers generate preliminary specication basic algorithms SW design after HW design HW designers generate architecture, RTL, logic synthesis tools generate logic designers simulate and optimize
Describe

Describe & Synthesize Specs Algorithms

SW? Design Logic Physical Manufacturing 1980s - 2000s

simulation before and after synthesis designers describe functionality, tools synthesize structure system gap still persists simulation of behavioral and structurel model RTL level introduced for cycleaccurate sim

Simulate

Marcel Jacomet

24

2012

Introduction The only way to eliminate the system gap is to further increase the abstraction level to the system level and, last but not least, to include both Hw and Sw into the design ow. An executable specication on the system level Sl is the starting point in this new design methodology and represents the system behavior. The methodology is extended by dierent models representing dierent details of the design decisions. The models are used to include dierent system properties, like functionality, communication, synchronization, performance, power and so on. Each model can be used as a specication to develop the next level models whereas more implementation information is added after more design decisions are made. This new design methodology is often called specify-explore-rene (Ser) design ow. In Ser designers rst specify their intent, then explore possibilities and nally rene the model according their decisions. Specify-Explore-Rene Design Flow

Marcel Jacomet

25

2012

Introduction application designers generate executable specication application algorithms platform model for application/platform optimization system designers generate detailed architecture and network 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 decisions rene model after exploration rened model = specication for the next level models include di system properties functionality, performance communication, synchronization
Specify, Explore & Refine Executable Spec Algorithms Architecture Network SW/HW Logic Physical Manufacturing 2000s - 2020?
Functionality

Algorithms Connectivity Protocols Performance Timing

Marcel Jacomet

26

2012

Introduction

Evolution of Design: Summary

Capture & Simulate Specs

concept of describe-and-synthesize was not upgraded adequately to system level System Gap

Algorithms

SW? Design
Simulate

Logic Physical

Manufacturing

1960s - 1980s

Marcel Jacomet

27

2012

Introduction In order to nd a suitable Ser design methodology, existing design ows have to be analyzed by their advantages and shortcomings. In Search of a Solution semantics issue in description language modeling languages do not reect design decisions modeling languages do not reect implementation models are ambiguous for synthesis and verication better model formalism needed denition of set of models denition of model composition relation between design decision and model transformation automatic model renement and generation model automation automatic metric estimation

Marcel Jacomet

28

2012

Introduction Introducing system level abstraction implies introducing more models. Clear model semantics are thus crucial. Models written in hardware description languages, like Vhdl or SystemC can be simulated, but have some drawbacks at using them for synthesis. Due to unclear semantics, they can result in ambiguities that make automated synthesis and verication impossible, thus only a well dened subset of the languages should be used. The case construct, which can be found in any Hdl comprises some implementation ambiguities: it can either be used to model an Fsm or a look-up table, where every case would be a state or a variable, respectively. Unfortunately Fsms and look-up tables require completely dierent implementations, using registers with logic in the rst, and memory in the latter. To conclude, a model which uses the case to model Fsms and tables is good for simulation but not for implementation as it cannot be determined which structure was described by the model. Some form of formalism has to be introduced to models and modeling languages in order to have well-dened semantics. Missing Semantics in Languages ambiguous semantics for hardware and system languages describes functionality, but not implementation same model may represent two completely dierent implementations simulatable but not synthesizable or veriable needs stricter semantics, describing design decisions

Marcel Jacomet

29

2012

Introduction

1.4142 7.5672

finite state machine

case X is when X1=> . . . when X2=>

look-up table

controller

memory

Marcel Jacomet

30

2012

Introduction Clear semantics for the dierent models as well as model transformation rules are necessary. Every model is a set of objects and composition rules, as for example is the case in classical algebra. With algebra we can also describe a models structure, like hierarchy, parallelisms or sequentialism. The expression on the left shows the need of one multiplier and one adder. The expression may need 2 clock cycles to complete, by executing the addition and multiplications sequentially. Using the algebra rules it is clear that this equation is identical with the one on the right side, where 2 multipliers and one adder is needed, executing the operation in 2 clock cycles as well. In case we are limited to 1 multiplier, the execution time would be 3 cycles. The equivalence of such arithmetic algebraic expressions allows the designer two perform model transformations and optimizations for some design metrics using algebra rules. Similar to the arithmetic algebra we can also dene model algebra describing objects and composition rules. The most important elements here are processes and communication channels. With the composition rules of model algebra we can compose objects hierarchically, sequentially and parallel. If we decide that the processes P1 and P2 run on process element PE1 and process P3 run on process element PE2, the sequential dependency of PE1 to PE3 as seen on the left side can be modeled by a communication channel synchronizing the 2 processes such that P3 only starts execution after P1 is nished. Model Algebra

Marcel Jacomet

31

2012

Introduction with model transformation we can describe: parallel, sequential, hieararchy model algebra: arithmetic algebra: <variables, operations> a (b + c ) = a b + a c arithmetic algebra allows creation of expressions and proving their equivalences
P1

P1

model algebr equivalences

P2 P3 P2 PE1 P3 PE2

Marcel Jacomet

32

2012

Introduction The specify-explore-rene methodologies may use model algebra to perform the model transformation after each step of design decisions. After some design exploration, design decisions are made, followed by a model transformation using model algebra to preserve execution equivalence. A model transformation usually replaces one object by several objects or does a re-composition of objects. Applying Ser methodology to a system specication we generate several intermediate models and nally may end up with a cycle-accurate implementation model.

Specify-Explore-Rene Methodology SER sequence of models generated through a sequence of design decisions
design decisions

system specification model

each design decision requires a model refinement model transformation transformations generate model replacement or recompilation renement model renement requires object replacemenet or re-composition
intermediate models

SER

cycle accurate implementation model

Marcel Jacomet

33

2012

Introduction A good compromise is needed to dene the right number of models. One model per abstraction level and design metric results in too many, and possible incompatible models. One model for several hierarchies may result in a too complex model. A good solution may be to stick number of models to the different types of designers: application designer, system designer and implementation designer, resulting in a specication model Sm, a transaction-level model Tlm and a cycle-accurate model Cam. With an executable specication model the designer can show that his algorithm runs correctly. Once a platform is dened, optimizations can be done by channel partitioning, mapping and scheduling. Adding new features and functions can also be done with this model, even when the product is already implemented on a target technology. The system designer uses the transaction-level model to estimate design metrics such as cost, performance, communication trac or power consumption. With the Tlm model he can explore dierent implementations like dierent component selections, connectivity, interfaces and operating systems. Finally the cycle-accurate model is used by hardware designers to verify the correct functionality of the generated system hardware components (custom processors, interfaces, interrupt controllers, bridges, etc). System software designers use the model to verify rmware, i.e. task scheduling, data transfer, synchronization etc. With the technology advances, the dierentiation between hardware and software is blurring. Algorithms executed in software today can be implemented in hardware tomorrow. The models presented support this technology shift. Necessary Models, Platforms and Tools design ow with 3 types of designers application designers

Marcel Jacomet

34

2012

Introduction system designers implementation designers design ow with 3 design models executable specication model (SM) transaction-level model (TLM) cycle-accurate model (CAM) platform with 4 component types processing components storage components communication components interface components environment with 4 types of tools metric evaluation with estimation tool design decisions with synthesis tool model generation with renement tools validation with simulation/Verication tool

Marcel Jacomet

35

2012

Introduction

1.6

System Models

The system model includes application code and system requirements. The application code is dened in the form of a process state machine Psm. The model is used to specify the application algorithm and later on to optimize application code for mapping to a platform. In the design phase of dening the system model, the application algorithm must be broken down into processes and communication channels. The goal must be to balance the channel trac that will optimize the local communication and minimize the long-distance data transfers after platform mapping. Further on, the processes must be grouped and mapped to processing elements which oer the best structure to execute them optimally. Restructuring the code, mapping and scheduling is often an iterative design step to nd an optimal solution.

System Specication Model (SM)

Marcel Jacomet

36

2012

Introduction SM species application algorithm SM includes application code and system requirements SM is for platform mapping and optimization SM uses a MoC (such as PSM) SM is an executable specication processes and communication SM synthesis break down into processes and communication channels balance channel trac mapping processes to PEs, scheduling exploring design space using metrics iterative design step

Marcel Jacomet

37

2012

Introduction The platform architecture can partially be dened by the Sm or completely be generated by the synthesis process. It is not uncommon, that additional components or communication channels are added after the synthesis step for some metric optimization. During synthesis, process are mapped to processing elements, variables are mapped to local or global memories and channels are mapped to routes, consisting of buses and bridges. The platform with its mapped processes and channels denes the system structure after manual or automatic system synthesis. Such system structures are usually modeled with a transactionlevel model (Tlm). A Tlm basically reects the structure of the system but adds bus interfaces and combines channels into buses. In our example, channels C1 and C2 use the Cpu bus and Ip bus through a bridge who converts the Cpu and Ip protocols to each other. In addition, the operating system Os and communication drivers for the bus reside on the Cpu. A Tlm model can be timed or un-timed. For a timed Tlm model the application code and its processing element need to be proled to estimate its execution time. In addition, the time needed to send messages through their communication routes need to be estimated as well. A Tlm is used to explore the dierent Sm with dierent platforms and dierent mappings. A Tlm allows fast simulation by using a reasonable model precision for the needed proling. A Tlm serves for the exploration of the platform structure and estimation of the system metrics. A Tlm is a system level model. System Transaction-Level Model (TLM)

Marcel Jacomet

38

2012

Introduction TLM for platform structure exploration application algorithms design metrics reect platform structure, combines channels to buses, add bus interfaces, adds OS/drivers TLM with dierent details network TLM, protocol TLM TLM is a system level model
CPU

models CPU: processes, OS IP, HW: processes bus: bus model TLM timed or un-timed proling code proling HW

Mem P1 OS Bridge P3

CPU Bus

IP Bus

P2 HW

P4 IP

P5

proling message through communication routes

Marcel Jacomet

39

2012

Introduction In order to generate a prototype, the system level abstraction model of a Tlm has to be lowered to the processor level of abstraction, resulting into a cycle-accurate model (Cam) for the entire system. By rening the functionality of each component of a Tlm model we can nd a Cam or Rtl model of the system. Thus for custom hardware and interface components we need a processor-level synthesis, Ip functional descriptions are replaced by their Rtl descriptions from libraries. Standard processes are replaced by their Rtl or Is models to run the compiled code. A Cam model must include Rtos and drivers as well. System Cycle-Accurate Model (CAM)

Marcel Jacomet

40

2012

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

Marcel Jacomet

41

2012

Introduction

Bridge

IP

Marcel Jacomet

42

2012

Introduction

1.7

System Platform

The basic platform components are processing components, storage components, communication components and interface components (besides analog components for mixed-mode designs). Todays platforms may have multiple processing and communication components. Also more complicated communication components like transducers are used to perform the message routing as seen in networks-on-chips (NoCs). System synthesis is only possible as long as the component and platform structure 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 communication components bridges, transducers NoCs interface components arbiters controllers DMAs, UARTs limitation to 4 basic components fosters system synthesis

Marcel Jacomet

43

2012

Introduction

arbiter 2
int2.1

PE2A (master) PE2B (slave) arbiter 3

r 1-2

int2.2

int3.1 int3.2

transducer 2-3

PE3A

memory 3 IF bus 2 bus 3

Marcel Jacomet

44

2012

Introduction

1.8

Tools and Environments

An automatic model renement can be obtained in the specifyexplore-rene methodology as long as there exists a sequence of transformations for every design decision. Using a model algebra, a verify tool can verify execution equivalence between the two models after every renement step. With a simulation the user can validate his new model. The user makes the design decisions with Gui tool, based on proling results of dierent metrics from the estimation tool and based on available components. Such a design environment can easily be implemented as long as the abstraction levels of model A and B do not differ signicantly. For our specify-explore-rene methodology we have identied 3 types of models Sm, Tlm and Cam. System Platform Architecture mode A to model B renemement estimation metrics tool for
model A

synthesis tool for design decisions renement tool transformations for

GUI estimation tool

refinement tool

simulation tool

verify tool for model equivalence simulation tool to validation model component library for model renement

synthesis tool verify tool component library

model B

GUI for manual override of synthesis tool Marcel Jacomet 45 2012

Introduction

Marcel Jacomet

46

2012

Introduction For our specify-explore-rene methodology we have identied 3 types of models Sm, Tlm and Cam. This means we need two tools as described above for the renement steps between the 3 dierent models: (a) A front-end tool for the application developers to capture the system behavior in a high level language such as C/C++, SystemC, Matlab, UML or similar. The frontend tool is used to test an application idea with a system model and to rene it to a transaction-level model using platform architecture. Exploring the design space, the tool thus generates a functional or timed Tlm. (b) A back-end tool for implementing the system with all Hw and Sw details given the dened platform. Starting from a Tlm description, the tool outputs a Cam of the system in Hdl for the Hw and an instruction set Is model for custom processors. A co-simulation of both Hdl/Is models can be used for verication at the micro-architecture abstraction level. The obtained Rtl descriptions can now be synthesized with Rtl tools to get the logic circuit for placing and routing on a chip. The compiled and linked Sw can be downloaded on the selected processors of the SoC platform. System Platform Architecture

Marcel Jacomet

47

2012

Introduction front-end for application developers (C/C++, SystemC, Matlab) for testing product concepts (application ideas) explore design space back-end micro-architecture abstraction-level for SW and HW development product prototyping SoC implementation prepare for fab synthesis level for gateCreate Select Partition Map Compile Replace SW Development & HW Development CAM TLM System Capture & Platform Development Decision User Interface SM Validation User Interface

Front-End
Compile Debug Simulate Verify TIMED CYCLE ACCURATE Compile Check Simulate Verify

Back-End

application tools: compilers/debuggers

commercial tools: FPGA/ASIC place & route

place and route compile code for SW

Marcel Jacomet

48

2012

Introduction

1.9

Conclusion

The past has shown, that simplifying a model always fosters an improvement in productivity: as a rst example was the restriction of the number of elements on chip to Nfet and Pfet transistors and combining them to Cmos logic gates. Compared to all available circuit types like resistor-transistor-logic, transistor-transistor-logic and diode-transistor-logic this was an eective simplication. Later on, the restriction to standard-cell design techniques with its layout routing channels was another major step in design productivity improvement. More recently we have observed the abstraction from logic gates to Fsms and data paths which opened the path for rst micro-architecture level synthesis tools. It is only natural to continue this move to higher abstraction levels and thus simplifying the underlying models. Another observation will have a big impact to the engineering education: the fact that application algorithms can either be implemented in Sw or Hw, brings the two engineering disciplines together and may even merge them in the future. Conclusion embedded system synthesis! Does it exist? well-dened models, decisions, transformations, renements worked in the past: layout, logic, RTL system level complexity simplied (nfet, std cell, ...) extreme makeover is necessary for this new paradigm SW = HW = SoC = embedded systems simulation based only ow is not acceptable design methodology must be based on scientic principles Marcel Jacomet 49 2012

Introduction benets 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

Marcel Jacomet

50

2012

Introduction abbreviation Ag Alap Asap Bb Bcam Bfm Cam Ccam Ccs Cdfg Ce Cla CMem Cpa Csa Csp Cw(r) Dfg Dut Edf Fsm Fsmd Hal Hcfsm Hdl Hls Hw Ir Is Isr Iss Ip If Kpn explanation address generator as late as possible as soon as possible basic block bus cycle-accurate model bus-functional model cycle-accurate model computation cycle-accurate model communication system control-data ow graph communication element carry-lookahead adder control memory carry-propagate adder carry-save adder communicating sequential process control word (register) data ow graph device under test earliest deadline rst (scheduling policy in RTOS) nite-state-machine nite-state-machine with data-path hardware abstraction level hierarchical concurrenzt FSM hardware description language high-level synthesis hardware instruction register instruction set interrupt service routine instruction set simulator intellectual property (hardware component) interface component Kahn process network

Marcel Jacomet

51

2012

Introduction abbreviation Mac MoC MPSoC NoC Pc Pe PMem Psm Rc Rf Rm Rpc Sdf Sldl Ser Sfsmd Sldl Sm SoC Sr Sw Tc Tlm Uml explanation media access (layer) model of computation multiple processor system-on-chip network-on-chip program counter processing element program memory process state machine ressource constrained (scheduling) register le rate monotonic (scheduling policy in RTOS) remote procedure call synchronous data ow system-level design language specify-explore-rene (design methodology) super FSM with datapath system-level design language specication model system-on-chip status register software time constrained transaction-level model unied modelling language

Marcel Jacomet

52

2012

Introduction

References
[GAGS09] Daniel D. Gajski, Samar Abdi, Andreas Gerstlauer, and Gunar Schirner. Embedded System Design: Modeling, Synthesis and Verication. Springer Verlag, 2009. Isbn-10 1441905030. [GZGZ00] Daniel D. Gajski, Jianwen Zhu, Andreas Gerstlauer, and Shuqing Zhao. SpecC: Specication language and Methodology. Kluwer Academic Publishers, 2000.

Marcel Jacomet

53

2012