zebo peng, petru elespetel71/codesign/lecture-notes/...hardware/software codesign petru eles 19 of...

1 of 52

September, 2001

Hardware/Software Co-design

Zebo Peng, Petru Eles

Department of Computer and Information Science (IDA)Linköping University

Cour se page: http://www.ida.liu.se/~petel/codesign/

2 of 52

September, 2001

ecture 1/2: Outline

■

■

■

Hardware/Software Codesign

Petru Eles

L

Hardware/Software Codesign: an Introduction

Course Content

Schedule, Organization, etc.

3 of 52

September, 2001

odesign: the Goal

embed ded systems

stems which


Petru Eles

Hardware/Software C

Computer aided hardware/software engineering of

■ Produce heterogeneous (hardware/software) sy

meet certain system-level objectives.

■ Reduce system development time.

4 of 52

September, 2001

f the “Early Days”

odeling

oftware components:


Petru Eles

Topics o

■ Implementation independent specification and m

■ Hardware/Software partitioning

■ Concurrent design refinement of hardware and s

❚ coordination

❚ consistency control

■ Cosimulation, Coverification

“Traditional” Design Flow

CommunicationSynthesis

Hardwaremodel

Softwaremodel

Scheduling,Software

Generation

HardwareSynthesis

Softwareblocks

Hardwareblocks

Prototyping

Product Fabrication

Sim

ulat

ion

Test

ing

Informal Specification,Requirements


Petru Eles

5 of 52

September, 2001

Hw/Sw Co-Design Flow

Systemspecification Simulation

Partitionedmodel

Hardw/SoftwPartitioning

Scheduling

Part. model,Schedule

CommunicationSynthesis

Hardwaremodel

Hardw./Softw.Cosimulation

Softwaremodel

SoftwareGeneration

HardwareSynthesis

Softwareblocks

Hardwareblocks


Emulation,Prototyping

Product Fabrication


Sy

ste

mL

ev

el

Lo

we

rL

ev

els


Petru Eles

6 of 52

September, 2001

7 of 52

September, 2001

“The Early Days”

issuesrdw./Softw. partitioningmmunication Synthesissimulation

r Memory

ardwareccelerator


Petru Eles

A Typical Target Architecture -

■ Specification: a “simple” program■ Main goal: software acceleration■ Architecture is simple

Main ■ Ha■ Co■ Co

µProcesso

HA

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

8 of 52

September, 2001

gurable Systems

quential circuits

ory that determines

number of times.

■

■


Petru Eles

Particularly Interesting: Reconfi

Programmable Hardware Circuits:

❚ They implement arbitrary combinational or se

and can be configured by loading a local mem

the interconnection among logic blocks.

❚ Reconfiguration can be applied an unlimited

Main applications:

❚ Software acceleration

❚ Prototyping

9 of 52

September, 2001

pacial Partitioning

Memory

GAlerator

lly

ned


Petru Eles

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Temporal&S

µProcessor

FPAcce

at t1

at t2

at t 3

at t 4

tempora

partitio

10 of 52

September, 2001

urable Processors

ath

C code

Profiling &Kernel

extraction

Hw/Swpartitioning

Kernels

C codeDatapathsynthesis

Sys


Petru Eles

Reconfig

tem on Chip with dynamically reconfigurable datap

Reconfigurabledatapath

Onchip

mem.

CPU

11 of 52

September, 2001

more Complicated

ram

rogeneous and complex;.

complex!


Petru Eles

It Can Be

• Specification: a “simple” prog• Main goal: acceleration• Architecture is simple

Applications are hetespecifications as well

Not only!

Architecture is very

12 of 52

September, 2001

otive Application)
D

Petru Eles

istributed Embedded System (Autom

Input/Output

Network Interf.

SensorsActuators

Gateway

Gateway

RAM

FLASH

CACHE

TASKS

OSCPU

FPGA

13 of 52

September, 2001

tion Component)

set of tasks&

al-time kernel

trolic In

terf

ace

LAN

RAM


Petru Eles

System on Chip (Telecommunica

application program&

I/O drivers re

High-SpeedDSP Blocks

ConLog

A/D&

D/ARF

DSP core RAM RISC core

14 of 52

September, 2001

edded Application

ed;

ated and

ted).


Petru Eles

The Typical Emb

■ Applications are heterogeneous:

❚ hardware and software components are mix

❚ in both hardware and software:control domin

dataflow components;

❚ digital and analog components interact.

■ Specifications are multi-language/multi-model.

■ Target architectures are complex (often distribu

15 of 52

September, 2001

ints/Requirements


Petru Eles

Design Constra

■ Legacy hardware/software

■ Time constraints

■ Quality of service

■ Fault tolerance

■ Cost

■ Power consumption

■ Flexibility

■ Time to Market

■ ...

System Design Flow

System model

Fabrication

Informal Specification,Constraints

FunctionalSimulation

Modeling

Testing

Arch. Selection

Systemarchitecture Mapping

Estimation

Mapped andscheduled model

Scheduling

OK

not OK not OK

OK

not OK

FormalVerification

Softw. model Hardw. model

Softw. Generation Hardw. Synthesis

Softw. blocks Hardw. blocksSimulation

Simulation

Sy

st

em

L

ev

el

Lo

we

r L

eve

ls

SimulationFormal

Verification

Prototype


Petru Eles

16 of 52

September, 2001

17 of 52

September, 2001

em Design (cont’d)

space exploration and

underlying architecture

ystems.


Petru Eles

Syst

■ Given a certain application, perform design

find an efficient implementation in terms of

and the software running on it.

■ Hw/Sw codesign ⇒ design of embedded s

18 of 52

September, 2001

Some Issues

ms


Petru Eles

■ Distributed Systems & System on chip

■ Processor design & Reconfigurable syste

■ Compiling (software synthesis)

■ Low power

■ IP-based design (reuse)

■ System specification

■ Formal methods

■ Verification and testing

■ Real-time Systems

19 of 52

September, 2001

eal-Time Systems

and is not considered as

;

re.

Cla

■

■


Petru Eles

Distributed R

ssical real-time research

Covers only a limited part of the design flow

Assumptions are often unrealistic

❚ Task models are too simple

❚ The underlying architecture is assumed fixed

part of the global design/optimization problem

The same for the communication infrastructu

❚ Emphasis on the “worst case”.

❚ - - - - - - - - - - - - - -

20 of 52

September, 2001

System on Chip

and digital on the same chip

s related to interconnections

oming dominant.

closure.

sed architectures will be

d by “networks on chip”.

ized cashes and memories.

lity!

- - - - - - - - - - -

µP


Petru Eles

rocessor DMA Memory

PeripheralRecon-

figurablelogic

Cache

InterconnectionNetwork

❚ Analog

❚ Problem

are bec

❚ Timing

❚ Bus-ba

replace

❚ Custom

❚ Testabi

❚ - - - - - -

AD/DA

21 of 52

September, 2001

Processor Design

.... see next slide

re

e

Instruction set

gramming environments!

Pa


Petru Eles

rtitioning across the horizontal line, as opposed to ..

---------------------------------------------

---------------------------------------------

---------------------------------------------

Profiling,Analysis

Hardwa(ASIP)

Softwar

A main issue:compilers and pro

22 of 52

September, 2001

sor Design (cont’d)

ardware(ASIC)

Hardware(ASIC)

Pa


Petru Eles

Proces

rtitioning across the vertical line

Software(µProcessor)

H

------------------------------------------------------------------------------------------------------------------------



Par

titi

onin

g&

map

pin

g

23 of 52

September, 2001

eterized Platforms

Applicationdevelopment(on ref. chip)

Detailedstructural

model

Parameteroptimization

(sim. & estim.)

Product

New Systemgeneration


Petru Eles

Param

µProcessor DMA Memory Bridge

PeripheralRecon-

figurablelogic

System bus

Peripheral bus

Cache

24 of 52

September, 2001

Software Synthesis

stems different?

to make use of

tecture.

compilation.

able compilers .


Petru Eles

What makes software synthesis for embedded sy

■ The need of highly optimized code in order

the particular features of the underlying archi

■ Large compilation times can be tolerated.

■ Time constraints have to be considered during

■ Scheduling aspects:

❚ at instruction level;

❚ at task level.

■ The need of performant easy-to-use retarget

25 of 52

September, 2001

Synthesis (cont’d)

g software generation.

s for concurrent

rdware

retargetable compiling.

W

■

■

■


Petru Eles

Software

hat makes it a Hardware/Software problem?

The hardware support has to be considered durin

Efficient retargetable compilers are important tool

development of software and of the underlying ha

(for example ASIPs).

Hardware Specification is an important aspect of

26 of 52

September, 2001

Low Power

e-offs: flexibility, power,

rmance, time to market.

e is an obvious trend

rds software implementation.

use of power/performance,

of the functionality is imple-

ed with ASIC/FPGA/ASIP.

makes the difference!

orde

r of

mag

nitu

deor

der

ofm

agni

tude


Petru Eles

flexibility

ener

gyco

nsum

ed

low

low

med.

med.

high

high

ASIC

FPGA

ASIP

GP proc.

❚ Trad

perfo

❚ Ther

towa

❚ Beca

part

ment

This

27 of 52

September, 2001

Low Power (cont’d)

tion

ry access and bus traffic)

■

■


Petru Eles

Power optimization at circuit and gate level

Power optimization at system level

❚ Dynamic power management

- shutdown of idle resources

- variable supply voltage

❚ Mapping and scheduling with power optimiza

❚ Code generation for low power

❚ Customized cache memory (to reduce memo

❚ Information encoding

28 of 52

September, 2001

- IP Based Design

a new system design

reuse library?

■

■

■


Petru Eles

Reuse

IP based design is the process of composing

by reusing existing components.

Problem: How to specify an existing core for the

❚ functionality

❚ timing

❚ interface properties

❚ power consumption, ...

Some essential design issues in this context:

❚ specification, simulation, estimation, exploration

❚ integration (interfaces)

❚ verification, testing


Petru Eles

29 of 52

September, 2001

• Arch. selection• Partitioning• Scheduling• Estimation• Simulation

Block levelsynthesis&verification

Instantiate-lib. blocks-


Softwaremodel

Architecture &mapping

Functional test(refine model)

Executablemodel

Systemrequirements

Preliminaryspecification

DESIGN SPACEEXPLORATION

Componentlibrary

(hardware/soft-ware cores)

Defineinterfaces

Hardwaremodel

Specify-new blocks-

Block levelsynthesis&verification

Develop-new modules-

Hardwareblocks

Softwaremodules

Emulation&Prototyping


Product Fabrication

Instantiate-lib. modules-

30 of 52

September, 2001

ed Design (cont’d)

Design

Inte


Petru Eles

Reuse - IP Bas

rface (Communication) - Based Design

Interfaces

Behaviours

31 of 52

September, 2001

deling/Verification

ataflow discreteevent

g

HLS LS

ASIC glue logic

Em


Petru Eles

FSMs

Specification/Mo

bedded systems are inherently heterogeneous

imperative d

partitionin

compiling softw. synth

processormodel

SWprocessor

model

SW

Specification

Refinement

Lower levelof abstraction

32 of 52

September, 2001

rification (cont’d)

f a design methodology.

of the design.

ll-defined.

s.

■

■

■

■


Petru Eles

Specification/Modeling/Ve

A formal model (possibly more) has to be part o

Allows unambiguous specification and analysis

The effect of transformations on the design is we

It is possible to formally reason about correctnes

Complexity!

33 of 52

September, 2001

rification (cont’d)

listic FSM-based model for

997]:

described as a network of

nd globally asynchronous .

tions of complex systems

, Int. Jrn. of Comp. Sim. ‘94]:

according to different

, communicating sequential

■

■


Petru Eles

Specification/Modeling/Ve

Co-design Finite State Machines (CFSM) is a rea

Hardware/Software systems [Balarin et al, Kluwer 1

❚ One CFSM is an extended FSM; a system is

communicating CFSMs.

❚ The CFSM model is locally synchronous a

Ptolemy is an environment which accepts specifica

which are designed heterogeneously [Buck et al

❚ Different parts of the system can be specified

computation models: data-flow , finite-state

processes , event-driven , etc.

34 of 52

September, 2001

fication Languages

he whole system; does not

ecification:

cation

are part;

on the selected model of

■

■


Petru Eles

Speci

A single specification language can be used for t

necessarily mean that we have a homogeneous sp

Several languages can be used for system specifi

❚ specific languages for the hardware and softw

❚ different languages can be used, depending

computation or because of other reasons.

❚ How to perform (co)simulation?

35 of 52

September, 2001

anguages (cont’d)

mC, Java, UML, Matlab)

)

ustre , Signal, StateCharts .

tos , SDL.

L.

he standard?

■

■

■

■

■

■

■

■

■


Petru Eles

Specification L

General purpose languages ( Ada, C, C++, Syste

Hardware description languages ( VHDL, Verilog

Synchronous languages (FSM based): Esterel , L

Networks of communicating processes: CSP, Lo

Data-flow languages: Silage

Functional programming languages: Haskell , SM

Algebraic notations: VDM, Z, B.

Will we get the System Specification Language ?

Will multi-language specification become (remain) t

Verification and Testing

looks for: design errorsfabrication defects

physical failures

model_s k

Systemspecification

Ref_step 1

model 1

Ref_step 2

model 2

Ref_step n

Ref_step_h 1

model_h 1

Ref_step_h m

model_h m

Ref_step_s 1

model_s 1

Ref_step_s k

model_h model_s

Fabrication

PRODUCT

Sys

tem

-lev

el s

ynth

esis

Har

dw

are

syn

thes

is

Sof

twar

e sy

nth

esis

DE

SI

GN

VA

LI

DA

TI

ON

form

al v

erif

icat

ion

& s

imu

lati

on(l

ook

sfo

rer

rors

insp

ecif

icat

ion

&d

esig

n)

PRODUCT TESTING

systemarchitecture


Petru Eles

36 of 52

September, 2001

Verification and Testing

System model



Modeling

Testing

Arch. Selection


Estimation


Scheduling

OK

not OK not OK

OK

not OK

FormalVerification




Simulation

Sy

st

em

L

ev

el

Lo

we

r L

eve

ls

SimulationFormal

Verification

Prototype


Petru Eles

37 of 52

September, 2001

38 of 52

September, 2001

Final Remarks

n level

ly developed

articular aspects.

ting tools.

■

■

■


Petru Eles

The real issue here is design of embedded systems

❚ Start from the specification at high abstractio

❚ Consider complex trade-offs

❚ Concentrate on early design steps

❚ Hardware architecture and software are joint

❚ Keep a global view and master heterogeneity

Important progress has been achieved on certain p

Some progress towards a methodology and suppor

39 of 52

September, 2001

Lecture 1&2

s: Introduction and

Hw/Sw systems

■


Petru Eles

Hardware/Software Codesign of Embedded System

Course Organization

❚ Difficulties with the design of heterogeneous

❚ Requirements of modern embedded systems

❚ Embedded system design flow

❚ Research issues

❚ Course topics

40 of 52

September, 2001

Lecture 3&4

anguages

on

dels of computation

tion

■


Petru Eles

System Modelling.

Models of Computation and System Specification L

❚ Models of Computation

- Basic models, specific features, comparis

- Multimodel specification

❚ Specification Languages

- Spec. Languages and their relation to mo

- Multilanguage specification and Cosimula

❚ Formal verification

- Formal verification approaches

- Model checking

Lecture 3&4

System model



Modeling

Testing

Arch. Selection


Estimation


Scheduling

OK

not OK not OK

OK

not OK

FormalVerification




Simulation

Sy

st

em

L

ev

el

Lo

we

r L

eve

ls

FormalVerification

Prototype

Simulation


Petru Eles

41 of 52

September, 2001

42 of 52

September, 2001

Lecture 5&6

s

cessors

control

figurable processors

■


Petru Eles

Processors and Architectures for Embedded System

❚ General Purpose vs. Application Specific Pro

- Instruction set, Memory, Interconnect and

- DSPs, Microcontrollers, VLIW processors

- Design Challenges

❚ Core (IP) - based design

- Reusable components

- Communication-based design

- Platform-based design

❚ Reconfigurable Systems

- Hardware/Software partitioning with recon

- Dynamically reconfigurable systems

Lecture 5&6

System model



Modeling

Testing

Arch. Selection


Estimation


Scheduling

OK

not OK not OK

OK

not OK

FormalVerification




Simulation

Sy

st

em

L

ev

el

Lo

we

r L

eve

ls

SimulationFormal

Verification

Prototype


Petru Eles

43 of 52

September, 2001

44 of 52

September, 2001

Lecture 7&8

pilers

or architectures

■


Petru Eles

Code Generation and Retargetable Compilers

❚ Compiler Generators and Retargetable Com

- Front end processing

- Back end processing

- Processor modeling

❚ Specific issues related to embedded process

- DSP processors

- SIMD instructions

- VLIW processors

Lecture 7&8

System model



Modeling

Testing

Arch. Selection


Estimation


Scheduling

OK

not OK not OK

OK

not OK

FormalVerification




Simulation

Sy

st

em

L

ev

el

Lo

we

r L

eve

ls

SimulationFormal

Verification

Prototype


Petru Eles

45 of 52

September, 2001

46 of 52

September, 2001

Lecture 9

s
■

Petru Eles

Software Performance Estimation by Static Analysi

❚ Program path analysis

❚ Microarchitecture modeling

- Cache memory

- Pipeline architecture

- Branch prediction

Lecture 9

System model



Modeling

Testing

Arch. Selection


Estimation


Scheduling

OK

not OK not OK

OK

not OK

FormalVerification




Simulation

Sy

st

em

L

ev

el

Lo

we

r L

eve

ls

SimulationFormal

Verification

Prototype


Petru Eles

47 of 52

September, 2001

48 of 52

September, 2001

Lecture 10&11

S

timization

iques

neration

stems

■


Petru Eles

ystem-Level Power/Energy Optimization

❚ Main issues in system-level power/energy op

- System modeling

- Hardware and software implementation

- Dynamic power management

- Computing, memory, communication

❚ Dynamic power management

- Modeling issues

- Predictive, adaptive, and stochastic techn

❚ Power estimation and low power software ge

❚ Low power/energy scheduling for real-time sy

- Variable voltage systems

- Static and dynamic approaches

- Energy efficient priority-based scheduling

Lecture 10&11

System model



Modeling

Testing

Arch. Selection


Estimation


Scheduling

OK

not OK not OK

OK

not OK

FormalVerification




Simulation

Sy

st

em

L

ev

el

Lo

we

r L

eve

ls

SimulationFormal

Verification

Prototype


Petru Eles

49 of 52

September, 2001

50 of 52

September, 2001

Lecture 12&13

■


Petru Eles

Hardware/Software Codesign Environments

❚ The Cosyma System

❚ The Cosmos Environment

❚ The SpecSyn Environment

❚ Synthesis of Distributed Embedded Systems

❚ The POLIS Environment

❚ The CoWare Environment

51 of 52

September, 2001

Lecture X (X ≅ 14)

■


Petru Eles

Guest Lecturer from Ericsson

52 of 52

September, 2001

nts for the 4 Points

r each topic and

be handed in before (at) the

■

■

■


Petru Eles

Requireme

Participation at the lectures

Presentation at one of the lectures

Reading of the mandatory literature indicated fo

preparation of an one page position report to

lecture.

zebo peng, petru elespetel71/codesign/lecture-notes/...hardware/software codesign petru eles 19 of...

Documents