hwsw-codesign.pdf

1

HW/SW CodesignIAY0070

SyllabusBooks

HW/SW Codesign definitionMyths

Codesign introductionKalle Tammemäe, Dept. of CE

TTÜ-ATI © K. Tammemäe

Goals

The couse is intended for Master levelstudents to educate them as futuredesigners of heterogeneous (hardware/software) digital systems.

2


Contents

Hardware and software mixed system design topics: specification, design space exploration, design quality and cost estimation, partitioning source description into different implementation domains, target code generation, interface synthesis and coverification. Partitioning algorithms. Specification refinement. Coverification methods for heterogeneous systems. System design methodology. Commercial and academic codesign packages.


Course structure

32 hours lectures52 hours individual work2.5 CU / 4 ECTS

EssayPresentationLabs 16 hoursFinal examination

30%

30%

10%

30%

3


Syllabusspecification,design space exploration,design quality and cost estimation,partitioning source description into different implementation domains,target code generation,interface synthesis and coverification,partitioning algorithms,specification refinement,coverification methods for heterogeneous systems,system design methodology,commercial and academic codesign packages.


Textbooks

Axel Jantsch, “Modelling Embedded Systems and SOC’s. Concurrency and Time in Models of Computation”, MK, 2004, VB-95792Vahid, Frank. Embedded system design : a unified hardware/software introduction, Wiley, 2002, VB-96179Wolf, Wayne. Computers as components : principles of embedded computing system design, MK, 2001, 004.4/W-81

4


Books“Readings in Hardware / Software Codesign”, edited by Giovanni DeMicheli, Morgan Kaufmann (MK), 2001A.S.Berger, “Embedded Systems Design. An Introductionto Processes, Tools, & Techniques”, CMPBooks, 2002“Hardware/Software Co-Design”, edited by Giovanni De Micheli, Maragiovanna Sami, KAP, 1996 Sanjaya Kumar, “The Codesign of Embedded Systems. A Unified Hardware/ Software Representation” KluwerAcademic Publishers (KAP), 1995, 304 pp. VB-73838 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, Jie Gong, “Specification and Design of Embedded Systems”, Prentice Hall, 1994, 468 pp, VB-73833


Introduction

Definition: HW/SW Codesign means meeting the system-level objectives by exploiting the synergism of hardware and software through their concurrent design.Mixture of three disciplines: System level modelling, HW design, SW designAreas of research interest:

HW/SW partitioningModelling HW/SW systemsEvaluation of HW/SW trade-offsExploration the cross fertilization techniques

5


Myths

Independent development of SW and HW is possibleHW inadequacies can be corrected in SW (later or during servicing phase)SW does not consume power nor require chip resources (SW as an ultimate free lunch)


Design cost

6


Design complexity


Reuse

7


Unified view

From system description to HW/SW system


Performance evaluation

Performance models are used in the early stages of design process to analyze systems in terms of throughput and utilization metrics, also to identify bottlenecks within a system

Petri net model (timed, stochastic)Queuing modelMixed modelsEtc.

8


Evaluation metrics

Metrics from parallel systemsExecution time, speedup, efficiency, overhead ration, utilization, redundancy

Cost functions (S of communication overhead, HW/SW size, bus utilization, processor utilization)Operator sensitivity metric for SW performanceModule sensitivity metric for reliabilityPrice = f(Chip area, SW development)Power

Software procedureHardware module


Design alternatives

ApplicationGeneral computer system (PC)Embedded system (printer, mobile phone, handheld, etc.)Distributed system (GSM, GPRS, ISDN, etc.)

LocalizationSoC (System on Chip)Accelerator board (graphics board)Multichip system

standardized bus/networkdedicated busmixed

etc.

9


HW/SW trade-offDecision regarding the allocation of functions into HW and SW that attempt to satisfy a set of objectives.No free lunch!Cross fertilization: applying the SW engineering concepts to HW design and vice versa.


HW/SW developmentData/control flow concepts are prevalent in both domains

SW development models: waterfall, iterative inhancement, spiral...Abstraction: functional (procedural) and data abstraction

10


Embedded system design path

Target: embedded system


Codesign path

11


Design path alternatives


Breaking the wall

SW designers have to know HW semanticsHW designers have to know SW semantics

12


Codesign systems

Research: CADLab, SIR/CASTLE (Germany), Chinook, COSMOS, COSYMA, CoWare, DICE, COMET, LYCOS (Denmark), POLIS, Ptolemy, Riley, TOSCA, AKKA, CODES, VIOOL, COOL, etc., etc.

Commercial: ArchGen (Synergy System Design, Inc.), Mentor Graphics, Synthesia→Cadence, Codesign Automation →Synopsys, Celoxica, CoWare, etc.


Limitations

Limitations of commercial systems so far:Typically manual partitioningFixed application domain (carefully very specialized)Incremental evaluation is supported weakly (no abstract models)Focusing mainly on performanceModel continuity is not supported during design refirement

1


HSCO Modeling

Conceptual modelsMethods and methodologyAutomation of abstraction


Conceptual modelsA model is a simplification of another entity, whichcan be a physical thing or another model. Themodel contains exactly those charactereristics and properties of the modeled entity that are relevantfor a given task. A model is minimal with therespect to a task if it does not contain any othercharacteristics than those relevant to the task.[A. Jantsch, Modelling embedded systems …, 2004]

Y-modelX-modelDesign cubeRugby model

2


System and model

SYSTEM

MODEL

Inputs Outputs

u(t) y=f(u)


Classification of systems

Systems

Static Dynamic

Time-varying Time-invariant

Linear Nonlinear

Continuous state Discrete state

Continuous time Discrete time

Event driven Time driven

Deterministic Stochastic Nondeterministic

3


Y-model

Authors: D.D. Gajski, R.H. Kuhn, IEEE Computer, Dec. 1983Limitations: No representation for time, communication and data abstraction.


Y model transformations

4


X-model

X-model extends the Y-model by including additional axis for testing, still preserving the limitations of Y-model.

Behavioraldomain

Testing domain

Physical domain

Structural domain


Design cube

W. Ecker, M. Hofmeister, S. März-Rössel, EURO-DAC 1992Limited to HDL language, no ability to represent physicalimplementations.

5


Rugby model

Axel Jants, Shashi Kumar, Ahmed Hemani: Royal Institute of Technology, Electrum, ESDlab, 1999.


Ways to handle complexity

Complexity

Domains Hierarchy Abstraction

Analyticalapproach

Horizontalapproach

Verticalapproach

A domain is an aspect which can logically beanalyzed independently from other aspectsRugby domains: Time, Computation, Communication, Data

6


Rugby: Separation ofcomputation and communication

FSM – computation withoutcommunicationPetri net – communication withoutcomputation

Process can be divided into process core, capturing computation and processs shell, capturing communicaton.


Rugby: Computation

Derived from Y-Chart's behavioural domain (only outside observable behaviour).Focuses on the way the results are computed independent from the exact data types involved and from the exact timing behaviour of the system.

7


Rugby: Communication

Relatively new dimension, joins parts of structural and physical domains of Y-chart.The topology level is only concerned with the presence or absence of connections between design elements.


Rugby: Data

For the modeling of mixed HW/SW systems it is desirable to treat data and data types as an independent aspect.

8


Rugby: Time

Time is of the utmost concern if the system contains concurrent activities.Time is not bound to particular kinds of computation.


Rugby: Design manipulation

There are no tools to describe and execute methodologies!There is no systematic and well understood relation betweenthe three levels: Instance Manipulation, Synthesis Algorithms, and Methodology.

9


Design methodology

Design methodology can be defined bygiving the order refinements from higherto lower abstraction levels.Design phases:

Requirements definitionSpecificationDesignImplementation

Design phases and abstraction levels are interrelated (there is ‘common practice’)


Rygby: models inNetwork Terminal design

Physical time

bitsTopologyLogic blocksSynthesizedNetlist

ClockedSymbols/bits

TopologyAlgorithm/FSM

VHDL model

Processor cycle time

Processor data types

Parameter passing

Instruction set

Assembler

CausalitySymbols/numbers

Parameter passing

AlgorithmC model

CausalitySymbolsInter-process communication

Algorithm/FSM

System model

Performance constraints

ATM cell definition

Interface constraints

Functional constraints

Require-ments

TimeDataCommuni-cation

Compu-tation

Abstraction

10


Abstraction and automation

hwsw-codesign.pdf

Documents

embedded systems design

embedded system design

hw design

design quality

system design methodology

concurrent design

design space exploration

codesign of embedded