Hardware/Software Codesign Environmentspetel71/codesign/lecture... · (control-dominated) embedded systems Includes both synthesis and simulation Environment based on a uniform representation

12/12/01

1

Hardware/SoftwareHardware/SoftwareCodesign EnvironmentsCodesign Environments

Gert JervanGert Jervan

IDA/IDA/SaSSaS/ESLAB/ESLAB

Gert Jervan, IDA/Gert Jervan, IDA/SaSSaS/ESLAB/ESLAB HW/SW Codesign EnvironmentsHW/SW Codesign Environments--22--

OverviewOverview

Embedded system design process�Traditional�Codesign

The COSYMA system The POLIS approach SpecSyn

Credits: Rolf Ernst, Sushant Jain, Vivek Sinha

12/12/01

2


Design processDesign process

reusedcomponents

support(CAD, test, ...)

requirements definition

specification

system architecture development

integration and test

customer/marketing

systemarchitect

SWdeveloper

HWdesigner

SW development• application SW

• compilers etc.

• operating syst.

interface design• SW driver dev.• HW interface

synthesis

HW design• HW architecture design

• HW synthesis

• physical design


Co-synthesis design flowCo-synthesis design flow

HDL generation

constraints anduser directives


OS, component &

communication libraries

system function

compilation&system analysis

intermediatecode generation

object codeobject code HW modelHW model

code generation

HW/SW partitioning& scheduling

HL synthesisco-simulation,

analysis

12/12/01

3


Co-design using co-synthesis and design space explorationCo-design using co-synthesis and design space exploration

HDL generation



OS, component &

communication libraries

system function

compilation&system analysis

intermediate codegeneration

object codeobject code HW modelHW model

code generation

HW/SW partitioning&scheduling

HL synthesisco-simulation

analysis

• specification parameter change• high level transformations

• specification parameter change• high level transformations

hardwaredesigner

softwaredevelopercustomer system

architect

cost, performance, ...

estimations


COSYMACOSYMA

COSYMA (COSYnthesis for eMbedded microArchitectures)

Achim Österling, Thomas Benner, Rolf Ernst,Dirk Herrmann, Thomas Scholz, Wei Ye

Technische Universität BraunschweigGermany

12/12/01

4


COSYMA - an OverviewCOSYMA - an Overview

A platform for exploration of the HW/SWco-synthesis techniques

Covers almost entire design flow Limited target architecture Is used mainly for design-space exploration

where it gives fast response times


The COSYMA Design FlowThe COSYMA Design Flow

Simulation and profiling

Compiler

C Processes

HW/SW Partitioning

Constraintsand userdirectives

C-code gener.& comm. synth.

HDL-code gener.& comm. synth.

SW Synthesis HL synthesis

run-time analysis

Synopsys DC

HW/SW Target model Peripheral modules

Synthesisdirectives

CommunicationModels

obj. codeVHDL netlist

Process scheduling

sim

12/12/01

5




Compiler

C Processes

HW/SW Partitioning





run-time analysis

Synopsys DC

Synthesisdirectives

CommunicationModels



Process scheduling

sim


COSYMA ArchitectureCOSYMA Architecture

Standard RISC processor core (a SPARCarchitecture model with 33 MHz clock and floatingpoint coprocessor with COSYMA)

A fast RAM for program and data with singleclock cycle access time

12/12/01

6


COSYMA ArchitectureCOSYMA Architecture

An automatically generated application specificcoprocessor

Peripheral units must be inserted by the designer

Processor and coprocessor communicate viashared memory in mutual exclusion




Process scheduling

HW/SW Partitioning





run-time analysis

Synopsys DC


Synthesisdirectives

CommunicationModels

sim


C Processes

Compiler

12/12/01

7


System SpecSystem Spec

The input description may consist of severalcommunicating processes with timingrequirements, specified in Cx

(extension of Csupporting parallel processes and timingconstraints)

Internal data structure: Extended Syntax Graph(ESG)



Compiler

C Processes

HW/SW Partitioning





run-time analysis

Synopsys DC


Synthesisdirectives

CommunicationModels

sim



Process scheduling

12/12/01

8


SchedulingScheduling

CX processes are simulated on a RTL model oranalyzed symbolically

Scheduling is done by using ScalablePerformance Scheduling (SPS)�Resulting a single serialized process�Done before partitioning

Alternative approach - combination of schedulingand partitioning


SchedulingScheduling

Speedup factor - to estimate the accelerationfactor of the target architecture compared to thereference processor

Information can be retrieved in an early designstage (before partitioning)

12/12/01

9




Compiler

C Processes

Process scheduling





run-time analysis

Synopsys DC


Synthesisdirectives

sim


HW/SW Partitioning

CommunicationModels


PartitioningPartitioning

Inputs:�ESG with profiling information

�CDR file

�Synthesis directives

Basic block level and is automated

SWSW HWHWSWSW

Timing constraints!

12/12/01

10



Partitioning goals:�meet real-time constraints�minimize hardware costs�minimize the CAD system response

time - allow user intervention

Simulated Annealing is deployed asan optimization algorithm

Ord

er o

f im

port

ance

Ord

er o

f im

port

ance



Communication is implicit

Requires communication analysis andcommunication synthesis

DOES NOT require explicit description of thecommunication from the user

12/12/01

11




Compiler

C Processes

HW/SW Partitioning



Synthesisdirectives

CommunicationModels



HL synthesis


SW Synthesis

Process scheduling

sim

Synopsys DC

run-time analysis


SynthesisSynthesis

For high-level synthesis: Braunschweig SynthesisSystem (BSS) ➝ for fast coprocessor designs

Netlist by Synopsys Design Compiler

For software: Standard C compiler

Co-simulation

12/12/01

12


You!You!


COSYMA ConclusionsCOSYMA Conclusions

Software oriented approach Specification can be handled easily (CX) Supports automated partitioning and co-

processor synthesis Design space exploration is possible during

synthesis Synthesis is driven by timing and HW constraints

12/12/01

13


COSYMA ConclusionsCOSYMA Conclusions

Does not support concurrent modules Architecture is limited There is no support for formal verification Quality depends on partitioning and cost

estimation techniques


POLISPOLIS

• Luciano Lavagno, Ellen Sentovich, Kei Suzuki,Alberto Sangiovanni-Vincentelli et al.

• UC Berkeley, Cadence, Magnetti-Marelli, PdT

12/12/01

14


POLISPOLIS

HW/SW codesign framework for reactive(control-dominated) embedded systems

Includes both synthesis and simulation

Environment based on a uniform representationfor hardware and software - a network ofCo-design Finite State Machines (CFSMs)


POLISPOLIS

CFSM has a finite, non-zero, unboundedreaction time

The model is Globally Asynchronous, LocallySynchronous

Each element of a network of CFSMs describes acomponent of the system to be modeled

Hardware and software have different delaycharacteristics

12/12/01

15


POLISPOLISEnvironmentEnvironment


12/12/01

16


System SpecificationSystem Specification

The system can be specified in Esterel to be bedirectly translated into CFSMs�Reactive synchronous language

System is a set of Concurrent Esterel modules(can be hierarchical)

Communication via signals and events


CFSMCFSM

Classical FSM has a synchronouscommunication model

CFSM has a finite, non-zero, unboundedreaction time

A CFSM consists of�sets of input events�sets of output events�a transition relation

12/12/01

17


CFSMCFSM

Each transition emits after an unbounded non-zero time the output event

A synchronous hardware implementation ofCFSM can execute a transition in 1 clock cycle

A software implementation can require more than1 clock cycle

Events move between communicating CFSMs inzero time (like in Esterel)


12/12/01

18


Design PartitioningDesign Partitioning

Implementation selection for every CFSM

CFSM specification is a priori unbiased towards ahardware or software implementation

No support for automatic partitioning


12/12/01

19


SynthesisSynthesis

Each HW partition is implemented as a fullysynchronous circuit�CFSM2BLIF (XNF, VHDL, Verilog)�Logic synthesis

Each SW partition is implemented as astandalone C program�High-level, processor independent representation�Portable C code


SynthesisSynthesis

Simple Real-time Operating System to:�provide communication between modules (HW-SW

and SW-SW)�schedule SW CFSMs (Rate-Monotonic and Deadline-

Monotonic)�generate device drivers for communication�generate an event driven layer which implements the

CFSM event emission/detection primitives

12/12/01

20


InterfacingInterfacing

Interfaces between different implementationdomains (hardware-software) are automaticallysynthesized

Interfaces come in the form of cooperatingcircuits and software procedures (I/O drivers)embedded in the synthesized implementation

Communication can be through I/O portsavailable on the micro-controller, or generalmemory mapped I/O.


12/12/01

21


Formal VerificationFormal Verification

Direct interface with existing FSM based formalverification tools

POLIS includes a translator from the CFSM tothe FSM formalism

A methodology which incorporates a set ofabstraction and assumption rules specific toPOLIS and CFSMs


System SimulationSystem Simulation

System level HW-SW Co-simulation is a way togive designers feedback on their design choices.�HW-SW partitioning

�CPU selection

�Scheduler selection.

Fast timed co-simulation due to the softwaresynthesis and performance estimationtechniques.

PTOLEMY co-simulation environment

12/12/01

22


It’s YouIt’s Youagain!again!Guess what!Guess what!


POLIS - ConclusionsPOLIS - Conclusions

Suitable for small control dominated systems

FSM based approach

Basic communication primitives: events

Flexible design space exploration (HW & SW aretreated similarly, can be derived from the sameCFSM)

12/12/01

23


POLIS - ConclusionsPOLIS - Conclusions

Co-simulation supported by Ptolemy Support for formal verification both at

specification and implementation levels Not suitable for very large computationally

dominated systems Architecture is limited - single processor

surrounded by a combinational HW. No supportfor shared memory


A Comparison of the FeaturesA Comparison of the Features

Features Polis Cosyma ChinookSystem Spec. Language Esterel Cx Verilog

Constraint Spec. No Yes Yes

Abstract Comm. Event Send/receive Signals

Model of Computation CFSMs RAM Model

Concurrency Concurrentmodules

Single thread ofexecution

Concurrentmodules

Partitioning Manual Automated Manual

Granularity Level User definedmodules

C Instruction level module and tasklevel

Formal Verification Supported No No

Co-Simulation PTOLEMY CoSim Pia

12/12/01

24


A Comparison of the FeaturesA Comparison of the Features

Features Polis Cosyma ChinookHW Synthesis BLIF, VHDL, XNF BSS Tool Netlist

SW Synthesis S-Graphs; C C C

OS Synthesis Automated - -

Process Scheduling Part of OS Static Static

SW PerformanceEstimation

S-Graphs andEmpirical results

Sparc Simulator

HW Estimation Single cycleexecution

List scheduling

HW/SW Communication I/O Ports Shared Memory I/O Ports

Target Architecture Processor andCFSMs imple-mented in HW

Processor,coprocessor andshared memory

MultipleProcessors, ASICs

Processor supported MIPS R3000 Sparc


SpecSynSpecSyn

SpecSyn environment for SER paradigm

UC Irvine

Daniel Gajski et al.

12/12/01

25


SpecSyn SpecSyn EnvironmentEnvironment

Pre-estimators

SLIF

Allocator

Partitioner

Transformer

Online-estimators

Refiner

VHDL system-level functional description

SW synthesis HW synthesis

SpecSyn

VHDL or SpecCharts functional specification


SpecSynSpecSyn

Outputs a system-level description, which differsfrom the input only by the addition of system-levelarchitectural features

SpecSyn was intended to support wide variety ofimplementation component technologies,architectures and heuristics, and new versions ofsuch items could be added

12/12/01

26


Why Why SpecSynSpecSyn??

There was no model available to supportembedded systems design (state-transitions,exceptions, forking and program-likecomputations)

New program-state machine model (PSM)�Combination of hierarchical FSM (Statecharts) and�Communicating sequential processes (CSP)

Supports subset of constraints


Internal RepresentationInternal Representation

Specification-level intermediate format (SLIF)

Access Graph (AG) to show relations betweenthe behaviors/variables (access)

AG is generic version of a procedure-call graph

12/12/01

27


ExplorationExploration

Any number of standard processors, customprocessors, memories and buses can beallocated

Three types of functional objects to bepartitioned:�Variables ⇒ memory components�Behaviors ⇒ custom or standard processors�Channels ⇒ buses



Hardware/Hardware and Hardware/Software -both are supported

Generic partitioning engine (evolving)

Supports manual partitioning

Partitioning is guided by cost functions

12/12/01

28


EstimationEstimation

Two level approach:�Preestimation�Online-Estimation

Three metric types:�Performance�Hardware size�Software size


TransformationsTransformations

Procedure exlining�Redundancy exlining�Distinct-comutation exlining

Procedrue inlining Process merging Process splitting Preclustering Procedure calling Port calling

12/12/01

29


RefinmentRefinment

Interface generation Memories Arbitration

Generation

Validation


What’s next?

12/12/01

30


Next slide:Next slide:

13:1513:15

Documents

Hardware/Software Codesign Environmentspetel71/codesign/lecture... · (control-dominated) embedded systems Includes both synthesis and simulation Environment based on a uniform representation