darpa tri-service hardware/software codesign overviesancheg/ee_ucu2006_thesis/biblio... ·...
TRANSCRIPT
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
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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 Hardware/Software Codesign Research
l Summary
6
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
Integrated Modeling Substrate
© IEEE 1991
21
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Cross-fertilization Between Hardware and Software Design
(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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Cross-fertilization Between Hardware and Software Design
(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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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 Hardware/Software Codesign Research
l Summary
32
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Abstractions for Software Systems
Virtual Machine Hierarchy
• Application Programs• Utility Programs• Operating System• Monitor• Machine Language• Microcode• Logic Devices
37
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Unified Representations (Cont.)
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Unified Representations (Cont.)
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Unified Representations (Cont.)
Object-oriented representation
Example:
3 Levels of abstraction:Register
Read
Write
ALU Processor
AddSub
ANDShift
MultDivLoadStore
43
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Unified Representations (Cont.)
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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 Hardware/Software Codesign Research
l Summary
45
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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 Hardware/Software Codesign Research
l Summary
72
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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 Methodologiesl Industry Approaches to HW/SW Codesign
l Hardware/Software Codesign Research
l Summary
79
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Hardware DesignMethodology
Hardware Design Process:Waterfall Model
HardwareRequirements
PreliminaryHardware
Design
DetailedHardware
DesignFabrication Testing
80
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Software DesignMethodology
Software Design Process:Waterfall Model
SoftwareRequirements
Software Design Coding Testing Maintenance
85
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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 Hardware/Software Codesign Research
l Summary
96
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Sanders Codesign Methodology
Integrated Modeling Substrate
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
Sanders Codesign Methodology
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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 Hardware/Software Codesign Research
l Summary
101
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
The Chinook System
VerilogSpecification
Processor &Device Libraries
parser scheduler
comm.synthesizer
codegenerator
driversynthesizer
interfacesynthesizer
program
netlist
BehavioralSimulation
MixedSimulation
StructuralSimulation
111
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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 Hardware/Software Codesign Research
l Summary
133
Methodology
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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
ReinventingElectronic
DesignArchitecture Infrastructure
DARPA Tri-Service
RASSP
Copyright 1995-1999 SCRA
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.