darpa tri-service hardware/software codesign overviesancheg/ee_ucu2006_thesis/biblio... ·...

1

Methodology

ReinventingElectronic

DesignArchitecture Infrastructure

DARPA Tri-Service

RASSP

Copyright 1995-1999 SCRA

Hardware/Software Codesign Overview RASSP Education & Facilitation Program

Module 14

Version 3.00


All rights reserved. This information is copyrighted by the SCRA, through its Advanced Technology Institute, and may only be used for non-commercial educational purposes. Any other use of this information without the express written permission of the ATI is prohibited. Certain parts of this work belong to other copyright holders and are used with their permission. All information contained herein may be duplicated for non-commercial educational use provided this copyright notice is included. No warranty of any kind is provided or implied, nor is any liability accepted regardless of use.

The United States Government holds “Unlimited Rights” in all data contained herein under Contract F33615-94-C-1457. Such data may be liberally reproduced and disseminated by the Government, in whole or in part, without restriction except as follows: Certain parts of this work belong to other copyright holders and are used with their permission;This information contained herein may be duplicated only for non-commercial educational use. Any vehicle, in which part or all of this data is incorporated into, shall carry this legend.

2

Methodology



DARPA Tri-Service

RASSP


Rapid Prototyping Design Process

SYSTEMDEF.

FUNCTIONDESIGN

HW & SW

PART.

HWDESIGN

SWDESIGN

HWFAB

SWCODE

INTEG.& TEST

VIRTUAL PROTOTYPE

REUSE DESIGN LIBRARIES AND DATABASE

Primarilysoftware

Primarilyhardware

HW & SW CODESIGN

HW & SW

Partitioning

& Codesign

3

Methodology



DARPA Tri-Service

RASSP


Module Goals

l Introduce the fundamentals of HW/SW codesign and partitioning concepts in designing embedded systems

m Discuss the current trends in the codesign of embedded systems

m Provide information on the goals of and methodology for partitioning hardware/software in systems

l Show benefits of the codesign approach over current design process

m Provide information on how to incorporate these techniques into a general digital design methodology for embedded systems

l Illustrate how codesign concepts are being introduced into design methodologies

m Several example codesign systems are discussed

4

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introductionl Unified HW/SW Representationsl HW/SW Partitioning Techniquesl Integrated HW/SW Modeling Methodologiesl HW and SW Synthesis Methodologiesl Industry Approaches to HW/SW Codesign

l Hardware/Software Codesign Research

l Summary

5

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introduction

l Unified HW/SW Representations

l HW/SW Partitioning Techniques

l Integrated HW/SW Modeling Methodologies

l HW and SW Synthesis Methodologies

l Industry Approaches to HW/SW Codesign


l Summary

6

Methodology



DARPA Tri-Service

RASSP


Codesign Definition and Key Concepts

l Codesignm The meeting of system-level objectives by exploiting the

trade-offs between hardware and software in a system through their concurrent design

l Key conceptsm Concurrent: hardware and software developed at the

same time on parallel pathsm Integrated: interaction between hardware and software

development to produce design meeting performance criteria and functional specs

7

Methodology



DARPA Tri-Service

RASSP


Motivations for Codesign

l Factors driving codesign (hardware/software systems):

m Instruction Set Processors (ISPs) available as cores in many design kits (386s, DSPs, microcontrollers,etc.)

m Systems on Silicon - many transistors available in typical processes (> 10 million transistors available in IBM ASIC process, etc.)

m Increasing capacity of field programmable devices - some devices even able to be reprogrammed on-the-fly (FPGAs, CPLDs, etc.)

m Efficient C compilers for embedded processorsm Hardware synthesis capabilities

8

Methodology



DARPA Tri-Service

RASSP


Motivations for Codesign(cont.)

l The importance of codesign in designing hardware/software systems:

m Improves design quality, design cycle time, and costq Reduces integration and test time

m Supports growing complexity of embedded systems

m Takes advantage of advances in tools and technologiesq Processor coresq High-level hardware synthesis capabilitiesq ASIC development

9

Methodology



DARPA Tri-Service

RASSP


Categorizing Hardware/Software Systems

l Application Domainm Embedded systems

q Manufacturing controlq Consumer electronicsq Vehiclesq Telecommunicationsq Defense Systems

m Instruction Set Architecturesm Reconfigurable Systems

l Degree of programmabilitym Access to programmingm Levels of programming

l Implementation Featuresm Discrete vs. integrated componentsm Fabrication technologies

10

Methodology



DARPA Tri-Service

RASSP


Categories of Codesign Problems

l Codesign of embedded systemsm Usually consist of sensors, controller, and actuatorsm Are reactive systemsm Usually have real-time constraintsm Usually have dependability constraints

l Codesign of ISAsm Application-specific instruction set processors (ASIPs)m Compiler and hardware optimization and trade-offs

l Codesign of Reconfigurable Systemsm Systems that can be personalized after manufacture for

a specific applicationm Reconfiguration can be accomplished before execution

or concurrent with execution (called evolvable systems)

11

Methodology



DARPA Tri-Service

RASSP


Components of the Codesign Problem

l Specification of the systeml Hardware/Software Partitioning

m Architectural assumptions - type of processor, interface style between hardware and software, etc.

m Partitioning objectives - maximize speedup, latency requirements, minimize size, cost, etc.

m Partitioning strategies - high level partitioning by hand, automated partitioning using various techniques, etc.

l Schedulingm Operation scheduling in hardwarem Instruction scheduling in compilersm Process scheduling in operating systems

l Modeling the hardware/software system during the design process

12

Methodology



DARPA Tri-Service

RASSP


Embedded Systems

Embedded SystemsApplication-specific systems which contain hardware and software tailored for a particular task and are generally part of a larger system (e.g., industrial controllers)

l Characteristicsm Are dedicated to a particular applicationm Include processors dedicated to specific functionsm Represent a subset of reactive (responsive to external

inputs) systemsm Contain real-time constraintsm Include requirements that span:

q Performanceq Reliabilityq Form factor

13

Methodology



DARPA Tri-Service

RASSP


Embedded Systems:Specific Trends

l Use of microprocessors only one or two generations behind state-of-the-art for desktops

m E.g. N/2 bit width where N is the bit width of current desktop systems

l Contain limited amount of memoryl Must satisfy strict real-time and/or performance

constraintsl Must optimize additional design objectives:

m Costm Reliabilitym Design time

l Increased use of hardware/software codesign principles to meet constraints

14

Methodology



DARPA Tri-Service

RASSP


Embedded Systems: Examples

l Banking and transaction processing applications

l Automobile engine control units

l Signal processing applications

l Home appliances (microwave ovens)

l Industrial controllers in factories

l Cellular communications

15

Methodology



DARPA Tri-Service

RASSP


Embedded Systems: Complexity Issues

l Complexity of embedded systems is continually increasing

l Number of states in these systems (especially in the software) is very large

l Description of a system can be complex, making system analysis extremely hard

l Complexity management techniques are necessary to model and analyze these systems

l Systems becoming too complex to achieve accurate “first pass” design using conventional techniques

l New issues rapidly emerging from new implementation technologies

16

Methodology



DARPA Tri-Service

RASSP


Techniques to Support Complexity Management

l Delayed HW/SW partitioningm Postpone as many decisions as possible that place

constraints on the design

l Abstractions and decomposition techniquesl Incremental development

m “ Growing” softwarem Requiring top-down design

l Description languagesl Simulationl Standardsl Design methodology management framework

17

Methodology



DARPA Tri-Service

RASSP


A Model of the Current Hardware/Software Design

Process

SystemConcepts

Sys/HWRequire.Analysis

Sys/SWRequire.Analysis

HardwareRequire.Analysis

SoftwareRequire.Analysis

Prelim.Design

Prelim.Design

DetailedDesign

DetailedDesign

Fabric.

Coding,Unit test.,Integ. test

HWCITesting

CSCITesting

SystemInteg. and

test

Operation.Testing and

Eval.

SW Development

HW Development

[Franke91]

DOD-STD-2167A

© IEEE 1991

18

Methodology



DARPA Tri-Service

RASSP


Current Hardware/Software Design Process

l Basic features of current process:m System immediately partitioned into hardware and software

componentsm Hardware and software developed separatelym “ Hardware first” approach often adopted

l Implications of these features:m HW/SW trade-offs restricted

q Impact of HW and SW on each other cannot be assessed easily

m Late system integration

l Consequences these features:m Poor quality designsm Costly modificationsm Schedule slippages

19

Methodology



DARPA Tri-Service

RASSP


Incorrect Assumptions in Current Hardware/Software

Design Process

l Hardware and software can be acquired separately and independently, with successful and easy integration of the two later

l Hardware problems can be fixed with simple software modifications

l Once operational, software rarely needs modification or maintenance

l Valid and complete software requirements are easy to state and implement in code

20

Methodology



DARPA Tri-Service

RASSP


Directions of the HW/SW Design Process

SystemConcepts

Sys/HWRequire.Analysis

Sys/SWRequire.Analysis

HardwareRequire.Analysis

SoftwareRequire.Analysis

Prelim.Design

Prelim.Design

DetailedDesign

DetailedDesign

Fabric.

Coding,Unit test.,Integ. test

HWCITesting

CSCITesting

SystemInteg. and test

Operation.Testing and Evaluation

SW Development

HW Development

[Franke91]

Integrated Modeling Substrate


© IEEE 1991

21

Methodology



DARPA Tri-Service

RASSP


Requirements for the Ideal Codesign Environment

l Unified, unbiased hardware/software representationm Supports uniform design and analysis techniques for

hardware and softwarem Permits system evaluation in an integrated design

environmentm Allows easy migration of system tasks to either hardware or

software

l Iterative partitioning techniquesm Allow several different designs (HW/SW partitions) to be

evaluatedm Aid in determining best implementation for a systemm Partitioning applied to modules to best meet design criteria

(functionality and performance goals)

22

Methodology



DARPA Tri-Service

RASSP


Requirements for the Ideal Codesign Environment (cont.)

l Integrated modeling substratem Supports evaluation at several stages of the design processm Supports step-wise development and integration of hardware

and software

l Validation Methodologym Insures that system implemented meets initial system

requirements

23

Methodology



DARPA Tri-Service

RASSP


Cross-fertilization Between Hardware and Software Design

l Fast growth in both VLSI design and software engineering has raised awareness of similarities between the two

m Hardware synthesism Programmable logicm Description languages

l Explicit attempts have been made to “transfer technology” between the domains

24

Methodology



DARPA Tri-Service

RASSP



(cont.)

l EDA tool technology has been transferred to SW CAD systems

m Designer support (not automation)

m Graphics-driven design

m Central database for design information

m Tools to check design behavior early in process

VLSI DESIGN

SOFTWAREENGINEERING

25

Methodology



DARPA Tri-Service

RASSP



(cont.)

l Software technology has been transferred to EDA tools

m Single-language designq Use of 1 common language for architecture spec.

and implementation of a chipm Compiler-like transformations and techniques

q Dead code eliminationq Loop unrolling

m Design change managementq Information hidingq Design families

SOFTWAREENGINEERING

VLSIDESIGN

26

Methodology



DARPA Tri-Service

RASSP


Typical Codesign Process

System Description(Functional)

HW/SWPartitioning

Software Synthesis

Interface Synthesis

Hardware Synthesis

SystemIntegration

Concurrent processesProgramming languages

Unified representation(Data/control flow)

Instruction set levelHW/SW evaluation

SW HW

FSM-directed graphs

Another HW/SWpartition

27

Methodology



DARPA Tri-Service

RASSP


Conventional Codesign Methodology

Analysis of Constraintsand Requirements

System Specs..

HW/SWPartitioning

Hardware Descript. Software Descript.

HW Synth. andConfiguration

Interface Synthesis Software Gen.& Parameterization

ConfigurationModules

HardwareComponents

HW/SWInterfaces

SoftwareModules

HW/SW Integrationand Cosimulation

IntegratedSystem

System Evaluation Design Verification[Rozenblit94]

© IEEE 1994

28

Methodology



DARPA Tri-Service

RASSP


Codesign Features

Basic features of a codesign processl Enables mutual influence of both HW and SW

early in the design cyclem Provides continual verification throughout the design

cyclem Separate HW/SW development paths can lead to costly

modifications and schedule slippages

l Enables evaluation of larger design space through tool interoperability and automation of codesign at abstract design levels

l Advances in key enabling technologies (e.g., logic synthesis and formal methods) make it easier to explore design tradeoffs

29

Methodology



DARPA Tri-Service

RASSP


State of CodesignTechnology

l Current use limited by:m Lack of a standardized representationm Lack of good validation and evaluation methods

l Possible solutions:m Extend existing hardware/software languages to the use

of heterogeneous paradigmsm Extend formal verification techniques to the HW/SW

domain

30

Methodology



DARPA Tri-Service

RASSP


Issues and Problems:Integration

l Errors in hardware and software design become much more costly as more commitments are made

l “ Hardware first” approach often compounds software cost because software must compensate for hardware inadequacies

1

2

3

4

25 50 75 100

Rel

ativ

e P

rog.

Cos

t / In

str.

% Util. of speed and mem capacity

Experience

Folklore

Software Cost Impact of Inadequate Hardware Resources

31

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introduction







l Summary

32

Methodology



DARPA Tri-Service

RASSP


Unified HW/SW Representation

l Unified Representation --m A representation of a system that can be used to

describe its functionality independent of its implementation in hardware or software

m Allows hardware/software partitioning to be delayed until trade-offs can be made

m Typically used at a high-level in the design process

l Provides a simulation environment after partitioning is done, for both hardware and software designers to use to communicate

l Supports cross-fertilization between hardware and software domains

33

Methodology



DARPA Tri-Service

RASSP


Current Abstraction Mechanisms in

Hardware Systems

AbstractionThe level of detail contained within the system model

l A system can be modeled at system, instruction set, register-transfer, logic, or circuit level

l A model can describe a system in the behavioral, structural, or physical domain

34

Methodology



DARPA Tri-Service

RASSP


Abstractions in Modeling:Hardware Systems

Level Behavior Structure Physical

PMS (System) CommunicatingProcesses

ProcessorsMemoriesSwitches (PMS)

Cabinets, Cables

Instruction Set(Algorithm)

Register-Transfer

Logic

Circuit

Input-Output Memory, PortsProcessors

BoardFloorplan

Register Transfers

ALUs, Regs,Muxes, Bus

ICsMacro Cells

Logic Equns. Gates, Flip-flops Std. cell layout

Network Equns. Trans., Connections Transistor layout

[McFarland90]

Start here

Work tohere

© IEEE 1990

35

Methodology



DARPA Tri-Service

RASSP


Current Abstraction Mechanisms for

Software Systems

Virtual machineA software layer very close to the hardware that hides the hardware’s details and provides an abstract and portable view to the application programmer

Attributesm Developer can treat it as the real machinem A convenient set of instructions can be used by

developer to model systemm Certain design decisions are hidden from the

programmerm Operating systems are often viewed as virtual machines

36

Methodology



DARPA Tri-Service

RASSP


Abstractions for Software Systems

Virtual Machine Hierarchy

• Application Programs• Utility Programs• Operating System• Monitor• Machine Language• Microcode• Logic Devices

37

Methodology



DARPA Tri-Service

RASSP


Abstract Hardware-Software Model

Uses a unified representation of system to allow early performance analysis

AbstractHW/SWModel

General PerformanceEvaluation

Evaluation of Design

Alternatives

Evaluation of HW/SW Trade-offs

Identification of Bottlenecks

38

Methodology



DARPA Tri-Service

RASSP


Examples of Unified HW/SW Representations

Systems can be modeled at a high level as:

l Data/control flow diagramsl Concurrent processesl Finite state machinesl Object-oriented representationsl Petri Nets

39

Methodology



DARPA Tri-Service

RASSP


Unified Representations (Cont.)

l Data/control flow graphsm Graphs contain nodes corresponding to operations in

either hardware or softwarem Often used in high-level hardware synthesism Can easily model data flow, control steps, and

concurrent operations because of its graphical nature

Example: +

+

+

+

5 X 4 Y

Control Step 1

Control Step 2

Control Step 3

40

Methodology



DARPA Tri-Service

RASSP



l Concurrent processesm Interactive processes executing concurrently with other

processes in the system-level specificationm Enable hardware and software modeling

l Finite state machinesm Provide a mathematical foundation for verifying system

correctness, simulation, hardware/software partitioning, and synthesis

m Multiple FSMs that communicate can be used to model reactive real-time systems

41

Methodology



DARPA Tri-Service

RASSP



l Object-oriented representations:m Use techniques previously applied to software to

manage complexity and change in hardware modelingm Use C++ to describe hardware and display OO

characteristicsm Use OO concepts such as

q Data abstractionq Information hidingq Inheritance

m Use building block approach to gain OO benefitsq Higher component reuseq Lower design costq Faster system design processq Increased reliability

42

Methodology



DARPA Tri-Service

RASSP



Object-oriented representation

Example:

3 Levels of abstraction:Register

Read

Write

ALU Processor

AddSub

ANDShift

MultDivLoadStore

43

Methodology



DARPA Tri-Service

RASSP



l Petri Nets: a system model consisting of places, tokens, transitions, arcs, and a marking

m Places - equivalent to conditions and hold tokens m Tokens - represent information flow through systemm Transitions - associated with events, a “firing” of a

transition indicates that some event has occurredm Marking - a particular placement of tokens within places

of a Petri net, representing the state of the net

Example:Token

Transition

Input Places

OutputPlace

44

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introduction







l Summary

45

Methodology



DARPA Tri-Service

RASSP


Hardware/Software Partitioning

l Definitionm The process of deciding, for each subsystem, whether

the required functionality is more advantageously implemented in hardware or software

l Goalm To achieve a partition that will give us the required

performance within the overall system requirements (in size, weight, power, cost, etc.)

l This is a multivariate optimization problem that when automated, is an NP-hard problem

46

Methodology



DARPA Tri-Service

RASSP


HW/SW Partitioning Issues

l Partitioning into hardware and software affects overall system cost and performance

l Hardware implementationm Provides higher performance via hardware speeds and

parallel execution of operations

m Incurs additional expense of fabricating ASICs

l Software implementationm May run on high-performance processors at low cost

(due to high-volume production)

m Incurs high cost of developing and maintaining (complex) software

47

Methodology



DARPA Tri-Service

RASSP


Partitioning Approaches

l Start with all functionality in software and move portions into hardware which are time-critical and can not be allocated to software (software-oriented partitioning)

l Start with all functionality in hardware and move portions into software implementation (hardware-oriented partitioning)

48

Methodology



DARPA Tri-Service

RASSP


System Partitioning(Functional Partitioning)

l System partitioning in the context of hardware/software codesign is also referred to as functional partitioning

l Partitioning functional objects among system components is done as follows

m The system’s functionality is described as collection of indivisible functional objects

m Each system component’s functionality is implemented in either hardware or software

l An important advantage of functional partitioning is that it allows hardware/software solutions

49

Methodology



DARPA Tri-Service

RASSP


Partitioning Metrics

l Deterministic estimation techniquesm Can be used only with a fully specified model with all

data dependencies removed and all component costs known

m Result in very good partitions

l Statistical estimation techniquesm Used when the model is not fully specifiedm Based on the analysis of similar systems and certain

design parameters

l Profiling techniquesm Examine control flow and data flow within an

architecture to determine computationally expensive parts which are better realized in hardware

50

Methodology



DARPA Tri-Service

RASSP


Binding Softwareto Hardware

l Binding: assigning software to hardware components

l After parallel implementation of assigned modules, all design threads are joined for system integration

m Early binding commits a design process to a certain course

m Late binding, on the other hand, provides greater flexibility for last minute changes

51

Methodology



DARPA Tri-Service

RASSP


Hardware/Software System Architecture Trends

l Some operations in special-purpose hardwarem Generally take the form of a coprocessor

communicating with the CPU over its busq Computation must be long enough to compensate

for the communication overheadm May be implemented totally in hardware to avoid

instruction interpretation overheadq Utilize high-level synthesis algorithms to generate a

register transfer implementation from a behavior description

l Partitioning algorithms are closely related to the process scheduling model used for the software side of the implementation

52

Methodology



DARPA Tri-Service

RASSP


HW/SW PartitionFormal Definition

l A hardware/software partition is defined using two sets H and S, where H ⊂ O, S ⊂ O, H ∪ S = O, H ∩ S = φ

l Associated metrics:

m Hsize(H) is the size of the hardware needed to implement the functions in H (e.g., number of transistors)

m Performance(G) is the total execution time for the group of functions in G for a given partition {H,S}

m Set of performance constraints, Cons = (C1, ... Cm), where Cj = {G, timecon}, indicates the maximum execution time allowed for all the functions in group G and G ⊂ O

53

Methodology



DARPA Tri-Service

RASSP


Performance Satisfying Partition

l A performance satisfying partition is one for which performance(Cj.G) ≤ Cj.timecon, for all j=1...m

l Given O and Cons, the hardware/software partitioning problem is to find a performance satisfying partition {H,S} such that Hsize(H) is minimized

l The all-hardware size of O is defined as the size of an all hardware partition (i.e., Hsize(O))

54

Methodology



DARPA Tri-Service

RASSP


Issues in Partitioning

l Specification abstraction levell Granularityl System-component allocationl Metrics and estimationsl Partitioning algorithmsl Objective and closeness functionsl Partitioning algorithmsl Outputl Flow of control and designer interaction

55

Methodology



DARPA Tri-Service

RASSP


Issues in Partitioning (Cont.)

Output

High Level Abstraction

Decomposition of functional objects

• Metrics and estimations• Partitioning algorithms• Objective and closeness functions

Component allocation

56

Methodology



DARPA Tri-Service

RASSP


Specification Abstraction Levels

l Task-level dataflow graphm A Dataflow graph where each operation represents a

task

l Taskm Each task is described as a sequential program

l Arithmetic-level dataflow graphm A Dataflow graph of arithmetic operations along with

some control operationsm The most common model used in the partitioning

techniques

l Finite state machine (FSM) with datapathm A finite state machine, with possibly complex

expressions being computed in a state or during a transition

57

Methodology



DARPA Tri-Service

RASSP


Specification Abstraction Levels (Cont.)

l Register transfersm The transfers between registers for each machine state

are described

l Structurem A structural interconnection of physical componentsm Often called a netlist

58

Methodology



DARPA Tri-Service

RASSP


Granularity Issues in Partitioning

l The granularity of the decomposition is a measure of the size of the specification in each object

l The specification is first decomposed into functional objects, which are then partitioned among system components

m Coarse granularity means that each object contains a large amount of the specification.

m Fine granularity means that each object contains only a small amount of the specification

q Many more objectsq More possible partitions

í Better optimizations can be achieved

59

Methodology



DARPA Tri-Service

RASSP


System ComponentAllocation

l The process of choosing system component types from among those allowed, and selecting a number of each to use in a given design

l The set of selected components is called an allocation

m Various allocations can be used to implement a specification, each differing primarily in monetary cost and performance

m Allocation is typically done manually or in conjunction with a partitioning algorithm

l A partitioning technique must designate the types of system components to which functional objects can be mapped

m ASICs, memories, etc.

60

Methodology



DARPA Tri-Service

RASSP


Metrics and Estimations Issues

l A technique must define the attributes of a partition that determine its quality

m Such attributes are called metricsq Examples include monetary cost, execution time,

communication bit-rates, power consumption, area, pins, testability, reliability, program size, data size, and memory size

q Closeness metrics are used to predict the benefit of grouping any two objects

l Need to compute a metric’s value m Because all metrics are defined in terms of the structure

(or software) that implements the functional objects, it is difficult to compute costs as no such implementation exists during partitioning

61

Methodology



DARPA Tri-Service

RASSP


Metrics in HW/SW Partitioning

l Two key metrics are used in hardware/software partitioning

m Performance: Generally improved by moving objects to hardware

m Hardware size: Hardware size is generally improved by moving objects out of hardware

62

Methodology



DARPA Tri-Service

RASSP


Computation of Metrics

l Two approaches to computing metricsm Creating a detailed implementation

q Produces accurate metric valuesq Impractical as it requires too much time

m Creating a rough implementationq Includes the major register transfer

components of a designq Skips details such as precise routing or optimized

logic, which require much design timeq Determining metric values from a rough

implementation is called estimation

63

Methodology



DARPA Tri-Service

RASSP


Objective and Closeness Functions

l Multiple metrics, such as cost, power, and performance are weighed against one another

m An expression combining multiple metric values into a single value that defines the quality of a partition is called an Objective Function

m The value returned by such a function is called costm Because many metrics may be of varying importance, a

weighted sum objective function is usedq e.g., Objfct = k1 * area + k2 * delay + k3 * power

m Because constraints always exist on each design, they must be taken into account

q e.g Objfct = k1 * F(area, area_constr) + k2 * F(delay, delay_constr)

+ k3 * F(power, power_constr)

64

Methodology



DARPA Tri-Service

RASSP


Partitioning Algorithm Issues

l Given a set of functional objects and a set of system components, a partitioning algorithm searches for the best partition, which is the one with the lowest cost, as computed by an objective function

l While the best partition can be found through exhaustive search, this method is impractical because of the inordinate amount of computation and time required

l The essence of a partitioning algorithm is the manner in which it chooses the subset of all possible partitions to examine

65

Methodology



DARPA Tri-Service

RASSP


Partitioning Algorithm Classes

l Constructive algorithmsm Group objects into a complete partitionm Use closeness metrics to group objects, hoping for a

good partitionm Spend computation time constructing a small number of

partitions

l Iterative algorithmsm Modify a complete partition in the hope that such

modifications will improve the partitionm Use an objective function to evaluate each partitionm Yield more accurate evaluations than closeness

functions used by constructive algorithms

l In practice, a combination of constructive and iterative algorithms is often employed

66

Methodology



DARPA Tri-Service

RASSP


Iterative Partitioning Algorithms

l The computation time in an iterative algorithm is spent evaluating large numbers of partitions

l Iterative algorithms differ from one another primarily in the ways in which they modify the partition and in which they accept or reject bad modifications

l The goal is to find global minimum while performing as little computation as possible

A

B

C

A, B - Local minima

C - Global minimum

67

Methodology



DARPA Tri-Service

RASSP


Iterative Partitioning Algorithms (Cont.)

l Two broad categories:m Greedy algorithms

q Only accept moves that decrease costq Can get trapped in local minima

m Hill-climbing algorithmsq Allow moves in directions increasing cost

(retracing)í Through use of stochastic functions

q Can escape local minimaq E.g., simulated annealing

68

Methodology



DARPA Tri-Service

RASSP


Output Issues in Partitioning

l Any partitioning technique must define the representation format and potential use of its output

m E.g., the format may be a list indicating which functional object is mapped to which system component

m E.g., the output may be a revised specificationq Containing structural objects for the system

componentsq Defining a component’s functionality using the

functional objects mapped to it

69

Methodology



DARPA Tri-Service

RASSP


Flow of Control andDesigner Interaction

l Sequence in making decisions is variable, and any partitioning technique must specify the appropriate sequences

m E.g., selection of granularity, closeness metrics, closeness functions

l Two classes of interactionm Directives

q Include possible actions the designer can perform manually, such as allocation, overriding estimations, etc.

m Feedbackq Describe the current design information available to

the designer (e.g., graphs of wires between objects, histograms, etc.)

70

Methodology



DARPA Tri-Service

RASSP


Comparing Partitions Using Cost Functions

l A cost function is a function Cost(H, S, Cons, I ) which returns a natural number that summarizes the overall quality of a given partition

m I contains any additional information that is not contained in H or S or Cons

m A smaller cost function value is desired

l An iterative improvement partitioning algorithm is defined as a procedure Part_Alg(H, S, Cons, I, Cost( ) )which returns a partition H’, S’ such that

Cost(H’, S’, Cons, I) ≤ Cost(H, S, Cons, I )

71

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introduction







l Summary

72

Methodology



DARPA Tri-Service

RASSP


Cosimulation

l An HDL (VHDL or Verilog) simulation environment is used to perform behavioral simulation of the system hardware processes

l A Software environment (C or C++) is used to develop the code

l SW and HW execute as separate processes linked through UNIX IPC (interprocessor communications) mechanisms (sockets)

73

Methodology



DARPA Tri-Service

RASSP


Verilog Cosimulation Example

Verilog HW Simulator

Module: Application specific hardware

HWproc 1

HWproc 2

Module: Bus Interface

Verilog PLI

SWproc 1

SW proc 2

Software processes communicate with hardware simulatorvia UNIX sockets

Verilog PLI (programminglanguage interface) serves astranslator, allowing hardware simulation models to communicate with softwareprocesses.

[Thomas93]

UNIXsockets

© IEEE 1993

74

Methodology



DARPA Tri-Service

RASSP


VHDL Cosimulation Example

VHDL Simulator

Hardware Model in VHDL:

VHDL Foreign LanguageInterface

Software processes communicate with hardware simulatorvia foreign language interface

Allowing hardware simulation models to “ cosimulate” with softwareprocesses.

SWproc 1

SW proc 2

RS232module

VMEmodule

75

Methodology



DARPA Tri-Service

RASSP


Architecture - VHDL

Communications Network

CPU 1 CPU 2 CPU 3 CPU 4

Scheduler - CMapping Function (e.g.):� Round Robin� Computational

Requirements Based� Communications

Requirements Based

VHDL-C Based HW/SW Cosimulation for DSP

Multicomputer Application

Algorithm - C

76

Methodology



DARPA Tri-Service

RASSP


VHDL-C Based HW/SW Cosimulation for DSP

Multicomputer ApplicationUnix C Program

System State (e.g.):

CPU:Time to instruction completion

Comm Agent:Messages in Send QueueMessages in Recv Queue

Network:Communications Channels Busy

Next Instruction for CPU to Execute (e.g.):

Send(destination, message_length)Recv(source, message_length)Compute(time)

VHDL Simulator

Architecture Model

INSTRUMENT

PACKAGE

CPU 1 CPU 2 CPU 3 CPU 4

Comm

Agent 1

Comm

Agent 2

Comm

Agent 3

Comm

Agent 4

Communications Network

SchedulerAlgorithm/

77

Methodology



DARPA Tri-Service

RASSP


Model Continuity Problem

Model Continuity Problem Inability to gradually define a system-level model into a hardware/software implementation

l Model continuity problems exist in both hardware and software systems

l Model continuity can help address several system design problems

m Allows validation of system level models with corresponding HW/SW implementation

m Addresses subsystem integration

78

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introduction




l HW and SW Synthesis Methodologiesl Industry Approaches to HW/SW Codesign


l Summary

79

Methodology



DARPA Tri-Service

RASSP


Hardware DesignMethodology

Hardware Design Process:Waterfall Model

HardwareRequirements

PreliminaryHardware

Design

DetailedHardware

DesignFabrication Testing

80

Methodology



DARPA Tri-Service

RASSP


Hardware DesignMethodology (Cont.)

l Use of HDLs for modeling and simulation

l Use of lower-level synthesis tools to derive register transfer and lower-level designs

l Use of high-level hardware synthesis tools

m Behavioral descriptions

m System design constraints

l Introduction of synthesis for testability at all levels

81

Methodology



DARPA Tri-Service

RASSP


Hardware Synthesis

l Definitionm The automatic design and implementation of hardware

from a specification written in a hardware description language

l Goals/benefits

m To quickly create and modify designs

m To support a methodology that allows for multiple design alternative consideration

m To remove from the designer the handling of the tedious details of VLSI design

m To support the development of correct designs

82

Methodology



DARPA Tri-Service

RASSP


Hardware Synthesis Categories

l Algorithm synthesism Synthesis from design requirements to control-flow

behavior or abstract behaviorm Largely a manual process

l Register-transfer synthesism Also referred to as “high-level” or “behavioral”

synthesism Synthesis from abstract behavior, control-flow behavior,

or register-transfer behavior (on one hand) to register-transfer structure (on the other)

m Logic synthesism Synthesis from register-transfer structures or Boolean

equations to gate-level logic (or physical implementations using a predefined cell or IC library)

83

Methodology



DARPA Tri-Service

RASSP


Hardware Synthesis Process Overview

BehavioralSimulation

Optional RTLSimulation

BehavioralSynthesis

Synthesis &Test Synthesis

Gate-levelSimulation

Gate-levelAnalysis

Place and Route

Specification Implementation

Verification

Silicon Vendor

Silicon

BehavioralFunctional

RTLFunctional

Gate

Layout

84

Methodology



DARPA Tri-Service

RASSP


Software DesignMethodology

Software Design Process:Waterfall Model

SoftwareRequirements

Software Design Coding Testing Maintenance

85

Methodology



DARPA Tri-Service

RASSP


Software DesignMethodology (Cont.)

l Software requirements includes bothm Analysism Specification

l Design: 2 levels:m System level - module specs.m Detailed level - process design language (PDL) used

l Coding - in high-level languagem C/C++

l Maintenance - several levelsm Unit testingm Integration testingm System testingm Regression testingm Acceptance testing

86

Methodology



DARPA Tri-Service

RASSP


Software Synthesis

l Definition: the automatic development of correct and efficient software from specifications and reusable components

l Goals/benefits

m To Increase software productivity

m To lower development costs

m To Increase confidence that software implementation satisfies specification

m To support the development of correct programs

87

Methodology



DARPA Tri-Service

RASSP


Why UseSoftware Synthesis?

l Software development is becoming the major cost driver in fielding a system

l To significantly improve both the design cycle time and life-cycle cost of embedded systems, a new software design methodology, including automated code generation, is necessary

l Synthesis supports a correct-by-construction philosophy

l Techniques support software reuse

88

Methodology



DARPA Tri-Service

RASSP


Software SynthesisCategories

l Language compilers

m ADA and C compilers

m YACC - yet another compiler compiler

m Visual Basic

l Domain-specific synthesis

m Application generators from software libraries

89

Methodology



DARPA Tri-Service

RASSP


Software Synthesis Examples

l Mentor Graphics Concurrent Design Environment System

m Uses object-oriented programming (written in C++)m Allows communication between hardware and software

synthesis toolsl Index Technologies Excelerator and Cadre’s

Teamwork Toolsetsm Provide an interface with COBOL and PL/1 code

generatorsl KnowledgeWare’s IEW Gamma

m Used in MIS applicationsm Can generate COBOL source code for system designers

l MCCI’s Graph Translation Tool (GrTT)m Used by Lockheed Martin ATLm Can generate ADA from Processing Graph Method

(PGM) graphs

90

Methodology



DARPA Tri-Service

RASSP


GrTT Tool Architecture

SPGN*PARCER

GRAPHANALYSIS

AUTOCODER

SPGNFile

GVSets

Validated GraphObject

Behavioral Specification

Ada SourceCode File

Domain Primitive Database

Constraints/Error Cond.

Behavior

CodeFragments

MCCI

*Signal Processing Graph Notation

91

Methodology



DARPA Tri-Service

RASSP


Interface Synthesis

l Definition: the automatic design and implementation of hardware (glue logic) and the software (drivers) components between the processor and the dedicated hardware

l Goals/benefitsm To quickly create and modify designs

m To remove from the designer the handling of the tedious details of VLSI design

92

Methodology



DARPA Tri-Service

RASSP


Interface Synthesis Approaches

l Typical approaches use standard interface schemes

m memory-mapped

m serial port

m parallel port

m self-timed

m synchronous

m blocking

93

Methodology



DARPA Tri-Service

RASSP


Cosynthesis

l Methodical approach to system implementations using automated synthesis-oriented techniques

l Methodology and performance constraints determine partitioning into hardware and software implementations

l The result is “optimal” system that benefits from analysis of hardware/software design trade-off analysis

94

Methodology



DARPA Tri-Service

RASSP


Cosynthesis Approach to System Implementation

MemoryBehavioral

Specification and Performance criteria

SystemInput

Per

form

ance

Cost

MixedImplementation

Pure SW

Pure HW

Constraints

[Gupta93]

SystemOutput

© IEEE 1993

95

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introduction







l Summary

96

Methodology



DARPA Tri-Service

RASSP


Sanders Codesign Methodology

Integrate& Test

Global influences

LibrariesDesignrules

Toolselect.

Virtual Environ.

Costmodels

Design Development Software Modules

Hardware Modules

Feedbackto user

Requirements

Req.Analysis

AlgorithmDevelop.

HW/SWTradeoffAnalysis

SW Req.Partition.

HW Req.Partition.

At allsteps

Design Code Test

Integrated HW/SWSimulation

Logical& Phys.Design

Anal. &Simul.

Fab &Test

SystemCheckout

[HOOD94]

97

Methodology



DARPA Tri-Service

RASSP




Gate LevelModel

Arch Ind.Proc Model

BehaviorLevel Model

ISAModel

HardwarePerf. Model

SystemRequirements

RTL Model

PrototypeHardware

SoftwarePerf. Model

Arch Dep.Proc Model

Source Code

LoadModule

SIMULATION

LIBRARY

HOL

Assembly

[RASSP94]

98

Methodology



DARPA Tri-Service

RASSP



l Subsystems processm Processing requirements are modeled in an

architecture-independent mannerm Codesign not an issue

l Architecture processm HW/SW allocation analyzed via modeling of SW

performance on candidate architecturesm Hierarchical verification is performed using finer grain

modeling (ISA and below)l Detailed design

m Downloadable executable application and test code is verified to maximum extent possible

l Library supportm SW models validated on test datam HW models validated using existing SW modelsm HW & SW models jointed iterated throughout designs

99

Methodology



DARPA Tri-Service

RASSP


Lockheed Martin ATL Codesign Methodology

Req. &

Spec.

Top levelArch.

Algor.develop.& simul.

SW Req.Spec.

Partition.

HWSpec..

Partition

HW/SWTradeoff

HWDesign

HW/SWCosimul.

SWDesign

SWCode

PrototypeUser

Interface

HWDev.

HWSim.

HWAnal.& Fab

HWTest

SWDebug

SWTest

HW/SWInteg.

SystemCheckout

[RASSP94]

100

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introduction







l Summary

101

Methodology



DARPA Tri-Service

RASSP


Major Codesign Research Efforts

l Chinook - University of Washington - Chou, Ortega, Borriello

l Cosmos - Grenoble University - Ismail, Jerrayal Cosyma - University of Braunschweig - Ernst,

Henkel, Bennerl Polis - U. C. Berkeley - Chiodo, Giusto, Jurecska,

Hsieh, Lavagno, Sangiovanni-Vincentellil Ptolemy - U. C. Berkeley - Kalavade, Leel Siera- U. C. Berkeley - Srivastava, Broderson

102

Methodology



DARPA Tri-Service

RASSP


Chinook

l Unified representation: Event Graph (CDFG)

l Partitioning: constraint driven by scheduling requirements

l Scheduling: timing driven

l Modeling substrate: based on Verilog HDL

l Validation: simulation based (Verilog)

l Main emphasis on synthesis of hardware/software interfaces

103

Methodology



DARPA Tri-Service

RASSP


Cosmos

l Unified representation: Initial description is done in SDL (specification description language) which is translated into SOLAR, an intermediate form that allows several description levels (CSPs, FSMs, etc.)

l Partitioning: user driven using a tool that allows processes to be grouped together or split into sub-processes

l Scheduling: based on the partitioningl Modeling substrate: VHDL simulation after

architecture mappingl Validation: simulation basedl Main emphasis on synthesis of communications

mechanisms between processes - reuse of existing communication models

104

Methodology



DARPA Tri-Service

RASSP


Cosyma

l Unified representation: ES graph (CDFG)l Partitioning: combined method based on course

partitioning by user with cost guidance and finer scheduling done by simulated annealing

l Scheduling: no specific methodl Modeling substrate: based on C++l Validation: simulation based (C++)l Main emphasis on partitioning for hardware

accelerators

105

Methodology



DARPA Tri-Service

RASSP


Polis

l Unified representation: Codesign Finite State Machine (CFSM) based

l Partitioning: user driven with cost estimated provided by co-simulation

l Scheduling: classical real-time algorithmsl Modeling substrate: Ptolemy based (C++)l Validation: co-simulation and formal FSM

verificationl Main emphasis on verifiable specification not

biased to either hardware or software implementation

106

Methodology



DARPA Tri-Service

RASSP


Ptolemy

l Unified representation: Data Flow Graphl Partitioning: greedy algorithm based on

scheduling constraintsl Scheduling: linear based on sorting blocks by

“criticality”l Modeling substrate: heterogeneous modeling

and simulation framework based on C++l Validation: based on simulationl Main emphasis on heterogeneous modeling

framework (mixing different models of computation)

107

Methodology



DARPA Tri-Service

RASSP


Siera

l Unified representation: static, hierarchical network of concurrent sequential processes communicating via message queues (similar to DFG)

l Partitioning: manual user drivenl Scheduling: static process to processor mapping,

priority based preemptive schedulers available within real-time OS on processors

l Modeling substrate: based on VHDL - includes support for modeling continuous time systems such as sensors and actuators

l Validation: based on simulationl Main emphasis on the design of embedded systems

targeted towards a predefined architectural template

108

Methodology



DARPA Tri-Service

RASSP


Chinook

l Hardware/Software Co-synthesis system developed at the University of Washington

l Targeted at real-time reactive embedded systems

l Control dominated designs constructed from off-the-shelf components

109

Methodology



DARPA Tri-Service

RASSP


Chinook’s Principal Innovations

l Single Specification - one specification, with explicit timing/performance constraints is used for the system’s hardware and software

l One Simulation Environment - the high level specification, the final result, and any intermediate steps can be simulated to verify and debug the design

l Software Scheduling - the appropriate software architecture is synthesized to meet the timing requirements

l Interface Synthesis - the hardware and software necessary to interface between system components (glue logic and device drivers) is automatically synthesized

l Complete Information for Physical Prototyping - a complete netlist is generated for the hardware, and C source code is generated for the software

110

Methodology



DARPA Tri-Service

RASSP


The Chinook System

VerilogSpecification

Processor &Device Libraries

parser scheduler

comm.synthesizer

codegenerator

driversynthesizer

interfacesynthesizer

program

netlist

BehavioralSimulation

MixedSimulation

StructuralSimulation

111

Methodology



DARPA Tri-Service

RASSP


System Specification in Chinook

(Unified Representation)

l The system specification is written in a dialect of Verilog and includes the system’s behavior and the structure of the system architecture

l The behavior is specified as a set of tasks in a style similar to communicating finite state machines - control states of the system are organized as modes which are behavioral regimes similar to hierarchical states

l In a given mode, the system’s responses are defined by a set of handlers which are essentially event-triggered routines

l The designer must tag tasks or modules with the processor that is preferred for their implementation - untagged tasks are implemented in software

l The designer can specify response times and rate constraints for tasks in the input description

112

Methodology



DARPA Tri-Service

RASSP


Scheduling in Chinook

l Chinook provides an automated scheduling algorithml Low-level I/O routines and high level routines grouped in

modes are scheduled staticallyl A static, nonpreemptive scheduling algorithm is used to

meet min/max timing constraints on low-level operationsm Determines serial ordering for operationsm Inserts delays as necessary to meet minimum constraintsm Includes heuristics in the scheduling algorithm to help exact

algorithm generate valid solution to NP-hard scheduling problem

l A customized dynamic scheduler may be generated for the top-level modes

113

Methodology



DARPA Tri-Service

RASSP


Interface Synthesis in Chinook

l Realization of communication between system components is an area of emphasis in the Chinook system

l Chinook synthesizes device drivers from timing diagramsl Custom code for the processor being used is generated

m For processors with I/O ports, an efficient heuristic is used to connect devices with minimal interface hardware

m For processors w/o I/O ports, a memory mapped I/O interface is generated including allocating address spaces, and generating the required bus logic and instructions

l Portions of the interface that cannot be implemented in software are synthesized into external hardware

114

Methodology



DARPA Tri-Service

RASSP


Communications Synthesis and System Simulation in

Chinookl Chinook provides methods for synthesizing

communications systems between multiple processors if a multicomputer implementation is chosen

m Bus-based, point-to-point, and hybrid communications schemes are supported

m Communications library that includes FIFOs, arbiters, and interconnect templates is provided

l Simulation of the design at different levels of detail is supported

m Verilog-XL Programming Language is usedm Verilog PLI is used to interface to device models written in Cm Each device supports the same API for simulation and

synthesis - API calls can be used by the designer to animate the model interactively

m RTL level models of the processors are used to simulate the final implementation of the system (software)

115

Methodology



DARPA Tri-Service

RASSP


Cosynthesis of Embedded Applications (COSYMA)

l Developed at the Technical University of Braunschweig, Germany

l An experimental system for HW/SW codesign of small embedded real time systems

m Implements as many operations as possible in software running on a processor core

m Generates external hardware only when timing constraints are violated

l Target architecture:m Standard RISC processor corem Application-specific processor

l Communication between HW and SW through shared memory with a communicating sequential processes (CSP) type protocol

116

Methodology



DARPA Tri-Service

RASSP


COSYMA (Cont.)

l Input description of system in C* is translated into an internal graph representation supporting

m Partitioningm Generating hardware descriptions for parts moved to

hardware

l Internal graph representation combinesm Control and dataflow graphm Extended syntax (ES) graph

q Syntax graph q Symbol tableq Local data/control dependencies

117

Methodology



DARPA Tri-Service

RASSP


Design Flow in aCOSYMA System

C* Mode

Simulator

C* Compiler

ES Flowgraph ES to HW C

HW-C Model

ES to C

C Program

C Compiler

Object Code

Partitioning

CostEstimation

Run timeAnalysis

Olympus

118

Methodology



DARPA Tri-Service

RASSP


COSYMA - Aims and Strategies

l Major aim is automating HW/SW partitioning process, for which very few tools currently exist

l COSYMA partitions at the basic block and function level (including hierarchical function calls)

m Simulated annealing algorithm is used because of its flexibility in the cost function and the possibility to trade-off computation time vs result quality

m Starts with an unfeasible all-software solution

119

Methodology



DARPA Tri-Service

RASSP


COSYMA - Cost Function and Metrics

l The cost function is defined to force the annealing to reach a feasible solution before other optimization goals (e.g., area)

l The metrics used in cost computation are: m Expected hardware execution timesm Software execution timesm Communicationm Hardware costs

l The cost function is updated in each step of the simulated annealing algorithm

120

Methodology



DARPA Tri-Service

RASSP


COSYMA - Cost Function and Metrics (Cont.)

l After partitioning, the parts selected to be realized in software are translated to a C program, thereby inserting code for communicating with the coprocessor

l The rest of the system is translated to the input description of the high-level synthesis system, and an application-specific coprocessor is synthesized

l Lastly, a fast-timing analysis of the whole HW/SW system is performed to test whether all constraints are satisfied

121

Methodology



DARPA Tri-Service

RASSP


Ptolemy

l A software environment for simulation and prototyping of heterogeneous systems

l Attributesm Facilitates mixed-mode system simulation,

specification, and design m Supports generation of DSP assembly code from a

block diagram description of algorithmm Uses object-oriented representations to model

subsystems efficientlym Supports different design styles called domains

122

Methodology



DARPA Tri-Service

RASSP


Codesign MethodologyUsing Ptolemy

l Ptolemy supports a framework for hardware/software codesign, called the Design Assistant

l The Design Assistant consists of two components

m Specific point tools for estimation, partitioning, synthesis, and simulation

m An underlying design methodology management infrastructure for design space exploration

123

Methodology



DARPA Tri-Service

RASSP


Codesign MethodologyUsing Ptolemy (Cont.)

[Rozenblit94]

Design constraints Design specs. User inputs

Design Flow Area/TimeEstimation

HW/SWPartitioning

InterfaceSynthesis

NetlistGeneration

HardwareSynthesis

SoftwareSynthesis

Simulation

PtolemyVHDL/Synopsys

System

ManualCPLEX(ILP)GCLP...

Layout + Software © IEEE 1994

124

Methodology



DARPA Tri-Service

RASSP


Ptolemy Heterogeneous Simulation Environment

Structural Components

l Data encapsulated in “particles”l “ Block” objects send and receive messagesl Particles travel to/from external world through

“portholes”

Geodesic

Plasma

Block BlockPorthole Porthole Porthole Porthole

Universe(Ptolemy Simulation Kernel)

Separate Model of Computation(e.g. discrete event)

Separate Model of Computation(e.g. data flow)

125

Methodology



DARPA Tri-Service

RASSP


POLIS

l Hardware/Software Codesign and synthesis system developed at the University of California, Berkeley

l Targeted towards small, scale, reactive, control dominated embedded systems

l Includes an “unbiased” mechanism for specifying the system’s function that allows for maximum flexibility in mapping to hardware or software and also allows for formal verification

126

Methodology



DARPA Tri-Service

RASSP


POLISUnified Representation

l System behavior is specified in a formal manner using Codesign Finite State Machines (CFSMs)

m CFSMs translate a set of inputs to a set of outputs with only a finite amount of internal state

m Unlike traditional FSMs, CFSMs do not all change state exactly at the same time (globally asynchronous)

l CFSMs are designed to be unbiased towards hardware or softwarel Translators exist to convert other specification languages (e.g.

ESTEREL) into CFSMsl CFSMs can be translated into traditional FSMs to allow formal

verificationl CFSMs can communicate with each other using events

m Events are unidirectional and happen in non-zero, unbounded timem Events can be used to communicate across all domains (hardware or

software)m Events are unbuffered and can be overwritten - however, they can be used to

implement fully interlocked handshakingl CFSMs are translated into behavioral FSMs for hardware synthesis and

into S-graphs for software synthesis

127

Methodology



DARPA Tri-Service

RASSP


Codesign Finite State Machines

l Specification: “Five seconds after the key is turned on, if the belt has not been fastened, an alarm will beep for ten seconds or until the key is turned off”

Wait

Alarm

Off

(*Key == On) → *Start

(*End == 5) → *Alarm = On(*Key == Off) or(*Belt == On) →

(*End == 10) or(*Belt == On) or(*Key == Off) → *Alarm = Off

(*Key == ON) and(*Belt == On) →

128

Methodology



DARPA Tri-Service

RASSP


S-graph Software Specification

Begin

S==Off

S==Wait*Key==On

*END==5 *END==10

*Alarm=On

S=Alarm

*Belt==On

*Key==Off

*Alarm=Off

*Key==Off

S=Off

End

*Belt==On

*Start

S=Wait

[Chiodo94]

Next

Next

Next

Next Next

Next

True False

True False

TrueFalse

TrueFalse

TrueFalse

TrueFalseNextTrueFalse

True

False

TrueFalse

© IEEE 1994

129

Methodology



DARPA Tri-Service

RASSP


Partitioning and Scheduling in POLIS

l Partitioning based on mapping CFSMs to either hardware or software

l This mapping is left to the user - performance feedback is provided by simulation

l Interfaces between partitions are automatically generated

l Scheduling based on executing CFSMsl Selection of scheduling algorithm left to user -

built into RTOSm Round-robin cyclic executivem Off-line I/O rate-based cyclic executivem Static pre-emptive: rate monotonic schedulingm Dynamic pre-emptive: Earliest Deadline First

130

Methodology



DARPA Tri-Service

RASSP


Interfaces Among Partitions

l Interfaces use strobe/data protocol (corresponding to the event/value primitive)

A B CSender Receiver

Sender’s Domain Receiver’s DomainChannel’s Domain

l Example HW to SW interface

0 1 -0 / 1

10 / 1

-1 / 011 + 0- / 0

x ack / y

X

y

ack

y

HW HW to SW SW

ack

X

131

Methodology



DARPA Tri-Service

RASSP


The POLIS Co-design Environment

Compilers

SW SynthesisInterface

Synthesis

HW Synthesis

FormalVerification

Partitioning

Simulation

Graphical EFSM ESTEREL (Other)…

CFSMs

SW Code +RTOS

Prototype

Logic Netlist

132

Methodology



DARPA Tri-Service

RASSP


Module Outline

l Introduction







l Summary

133

Methodology



DARPA Tri-Service

RASSP


Module Summary

l The synergistic design of hardware and software in a digital system, called Hardware/Software Codesign, has been explored

l Elements of a HW/SW Codesign methodology have been outlined

l Industrial design flows that contain aspects of codesign have been presented

l Present day research into automating portions of the codesign problem have been explored

l As digital systems become more complex and performance criteria become more stringent, codesign will become a necessity

l Better design tools and unified design environments will allow codesign techniques to become standard practice

134

Methodology



DARPA Tri-Service

RASSP


References

[Boehm73] Boehm, B.W. “Software and its Impact: A Quantitative Assessment,” Datamation, May 1973, p. 48-59.

[Buchenrieder93] Buchenrieder, K., “Codesign and Concurrent Engineering” , Hot Topics, IEEE Computer, R. D. Williams, ed., January, 1993, pp. 85-86

[Buck94] Buck, J., et al., “Ptolemy: a Framework for Simulating and Prototyping Heterogeneous Systems,” International Journal of Computer Simulation, Vol. 4, April 1994, pp. 155-182.

[Chiodo92] Chiod0, M., A. Sangiovanni-Vincentelli, “Design Methods for Reactive Real-time Systems Codesign,” International Workshop on Hardware/Software Codesign, Estes Park, Colorado, September 1992.

[Chiodo94] Chiodo, M., P. Giusto, A. Jurecska, M. Marelli, H. C. Hsieh, A. Sangiovanni-Vincentelli, L. Lavagno, “Hardware-Software Codesign of Embedded Systems,” IEEE Micro, August, 1994, pp. 26-36; © IEEE 1994.

[Chou95] P. Chou, R. Ortega, G. Borriello, “The Chinook hardware/software Co-design System,” Proceedings ISSS, Cannes, France, 1995, pp. 22-27.

[DeMicheli93] De Micheli, G., “Extending CAD Tools and Techniques” , Hot Topics, IEEE Computer, R. D. Williams, ed., January, 1993, pp. 84

[DeMicheli94] De Micheli, G., “Computer-Aided Hardware-Software Codesign” , IEEE Micro, August, 1994, pp. 10-16

[DeMichelli97] De Micheli, G., R. K. Gupta, “Hardware/Software Co-Design,” Proceedings of the IEEE, Vol. 85, No. 3, March 1997, pp. 349-365.

[Ernst93] Ernst, R., J. Henkel, T. Benner, “Hardware-Software Cosynthesis for Micro-controllers” , IEEE Design and Test, December, 1993, pp. 64-75

[Franke91] Franke, D.W., M.K. Purvis. “Hardware/Software Codesign: A Perspective,” Proceedings of the 13th International Conference on Software Engineering, May 13-16, 1991, p. 344-352; © IEEE 1991

135

Methodology



DARPA Tri-Service

RASSP


References (Cont.)

[Gajski94] Gajski, D. D., F. Vahid, S. Narayan, J. Gong, Specification and Design of Embedded Systems, Prentice Hall, Englewood Cliffs, N J, 07632, 1994

[Gupta92] Gupta, R.K., C.N. Coelho, Jr., G.D. Micheli. “Synthesis and Simulation of Digital Systems Containing Interactive Hardware and Software Components,” 29th Design Automation Conference, June 1992, p.225-230.

[Gupta93] Gupta, R.K., G. DeMicheli, “Hardware-Software Cosynthesis for Digital Systems,” IEEE Design and Test, September 1993, p.29-40; © IEEE 1993.

[Hermann94] Hermann, D., J. Henkel, R. Ernst, “An approach to the estimation of adapted Cost Parameters in the COSYMA System”, 3rd International Conference on Hardware/Software codesign, Grenoble, France, September 22-24, 1994, pp. 100-107

[Hood94] Hood, W., C. Myers, "RASSP: Viewpoint from a Prime Developer," Proceedings 1st Annual RASSP Conference, Aug. 1994.

[IEEE] All referenced IEEE material is used with permission.[Ismail95] T. Ismail, A. Jerraya, “Synthesis Steps and Design Models for Codesign,” IEEE Computer,

no. 2, pp. 44-52, Feb 1995.[Kalavade93] A. Kalavade, E. Lee, “A Hardware-Software Co-design Methodology for DSP

Applications,” IEEE Design and Test, vol. 10, no. 3, pp. 16-28, Sept. 1993.[Klenke96] Klenke, R. H., J. H. Aylor, R. Hillson, D. J. Kaplan, “VHDL-Based Performance Modeling for

the Processing Graph Method Tool (PGMT) Environment,” Proceedings of the VHDL International Users Forum, Spring 1996, pp. 69-73.

[Kumar95] Kumar, S., “A Unified Representation for Hardware/Software Codesign”, Doctoral Dissertation, Department of Electrical Engineering, University of Virginia, May, 1995

[Jalote91] Jalote, P., An Integrated Approach to Software Engineering, Springer-Verlag, New York, 1991.

[McFarland90] McFarland, M.C., A.C. Parker, R. Camposano. “The High-Level Synthesis of Digital Systems,” Proceedings of the IEEE, Vol. 78, No. 2, February 1990, p.301-318, © IEEE 1990.

136

Methodology



DARPA Tri-Service

RASSP


References (Cont.)

[Parker84] Parker, A.C., “Automated Synthesis of Digital Systems,” IEEE Design and Test,, November 1984, p. 75-81.

[RASSP94] Proceedings of the 1st RASSP Conference, Aug. 15-18, 1994.[Rozenblit94] Rozenblit, J. and K. Buchenrieder (editors). Codesign Computer -Aided

Software/Hardware Engineering, IEEE Press, Piscataway, NJ, 1994; © IEEE 1994.[Smith86] Smith, C.U., R.R. Gross. “Technology Transfer between VLSI Design and Software

Engineering: CAD Tools and Design Methodologies,” Proceedings of the IEEE, Vol. 74, No. 6, June 1986, p.875-885.

[Srivastava91] M. B. Srivastava, R. W. Broderson, “Rapid prototyping of Hardware and Software in a Unified Framework,” Proceedings ICCAD, 1991, pp. 152-155.

[Subrahmanyam93] Subrahmanyam, P. A., “Hardware-Software Codesign -- Cautious optimism for the future” , Hot Topics, IEEE Computer, R. D. Williams, ed., January, 1993, pp. 84

[Tanenbaum87] Tanenbaum, A.S., Operating Systems: Design and Implementation, Prentice-Hall, Inc., Englewood Cliffs, N.J., 1987.

[Terry90] Terry, C. “Concurrent Hardware and Software Design Benefits Embedded Systems,” EDN, July 1990, p. 148-154.

[Thimbleby88] Thimbleby, H. “Delaying Commitment,” IEEE Software, Vol. 5, No. 3, May 1988, p. 78-86.[Thomas93] Thomas, D.E., J.K. Adams, H. Schmitt, “A Model and Methodology for Hardware-Software

Codesign,” IEEE Design and Test, September 1993, p.6-15; © IEEE 1993.[Turn78] Turn, R., “Hardware-Software Tradeoffs in Reliable Software Development,” 11th Annual

Asilomar Conference on Circuits, Systems, and Computers, 1978, p.282-288.[Vahid94] Vahid, F., J. Gong, D. D. Gajski, “A Binary Constraint Search Algorithm for Minimizing

Hardware During Hardware/Software Partitioning” , 3rd International Conference on Hardware/Software Codesign, Grenoble, France, Sepetember22-24, 1994, pp. 214-219

[Wolf94] Wolf, W.H. “Hardware-Software Codesign of Embedded Systems,” Proceedings of the IEEE, Vol. 82, No.7, July 1994, p.965-989.

137

Methodology



DARPA Tri-Service

RASSP


References (Cont.)

Additional Reading:Aylor, J.H. et al., "The Integration of Performance and Functional Modeling in VHDL” in Performance

and Fault Modeling with VHDL, J. Schoen, ed., Prentice-Hall, Englewood Cliffs, N.J., 1992.D’Ambrosio, J. G., X. Hu, “Configuration-level Hardware-Software Partitioning for Real-time Embedded

Systems” , 3rd International Conference on Hardware/Software codesign, Grenoble, France, September 22-24, 1994, pp. 34-41

Eles, P., Z. Peng, A. Doboli, “VHDL System-Level Specification and Partitioning in a Hardware-Software Cosynthesis Environment” , 3rd International Conference on Hardware/Software codesign, Grenoble, France, September 22-24, 1994, pp. 49-55

Gupta, R.K., G. DeMicheli, “Hardware-Software Cosynthesis for Digital Systems,” IEEE Design and Test, September 1993, p.29-40.

Richards, M., Gadient, A., Frank, G., eds. Rapid Prototyping of Application Specific Signal Processors, Kluwer Academic Publishers, Norwell, MA, 1997

Schultz, S.E., “An Overview of System Design,” ASIC and EDA, January 1993, p.12-21.Thomas, D. E, J. K. Adams, H. Schmit, “A Model and Methodology for Hardware-Software Codesign” ,

IEEE Design and Test, September, 1993, pp. 6-15Zurcher, F.W., B. Randell, “ Iterative Multi-level Modeling - A Methodology for Computer System

Design,” Proceedings IFIP Congress ‘68, Edinburgh, Scotland, August 1968, p.867-871.

darpa tri-service hardware/software codesign overviesancheg/ee_ucu2006_thesis/biblio... ·...

Documents