universität dortmund eece **** embedded system design chapter 5a: hardware/software codesign

Universität Dortmund

EECE **** Embedded System Design

Chapter 5A: Hardware/Software Codesign

Universität Dortmund - 2 -

Hardware/Software Codesign

Universität Dortmund - 3 -

Design productivity gap

Universität Dortmund - 4 -

© L

auro

Riz

zatt

iM

arke

tin

g V

ice

Pre

sid

ent

Em

ula

tio

n &

Ver

ific

atio

n

En

gin

eeri

ng

(E

VE

)la

uro@

eve-

usa.

com

Universität Dortmund - 5 -

Platform-based design

Platform instances

Platform abstraction levels

Top-Down:

Map an instance of the upper

platform onto an lower platform

considering appropriate

constrains.

Bottom-Up:

Find the appropriate platform

levels.

Define platform level

parameters

Universität Dortmund - 6 -

Platform-based design

Decouples the application development process from the architectural implementation process.

• System Platform StackThe main application area. The primary notion of PBD originates here.

• Network PlatformsEquivalent to protocol stacks.

• Analog PlatformPerformance models, behavioral models and interconnection models.

• System Platform StackThe main application area. The primary notion of PBD originates here.

• Network PlatformsEquivalent to protocol stacks.

• Analog PlatformPerformance models, behavioral models and interconnection models.

Few design areas suitable for PBD:

Universität Dortmund - 7 -

Iterative approach (1)

Guided by performance evaluation

Guided by performance evaluation

Universität Dortmund - 8 -

Essentially the same with our flow …

System architecture

Performance simulation

Ref

ineSystem behavior

Implementation

Mapping

Universität Dortmund - 9 -

Overview of design activities

• Task level concurrency managementWhich tasks in the final system?

• High level transformationsTransformation that are outside the scope of traditional compilers

• Hardware/software partitioningWhich operation mapped to hardware, which to software?

• CompilationHardware-aware compilation

• SchedulingPerformed several times, with varying precision

• Design space explorationSet of possible designs, not just one.

• Task level concurrency managementWhich tasks in the final system?

• High level transformationsTransformation that are outside the scope of traditional compilers

• Hardware/software partitioningWhich operation mapped to hardware, which to software?

• CompilationHardware-aware compilation

• SchedulingPerformed several times, with varying precision

• Design space explorationSet of possible designs, not just one.

Universität Dortmund - 10 -

Merging of tasks

Reduced overhead of context switches,

More global optimization of machine code,

Reduced overhead for inter-process/task communication.

Reduced overhead of context switches,

More global optimization of machine code,

Reduced overhead for inter-process/task communication.

Universität Dortmund - 11 -

Splitting of tasks

No blocking of resources while waiting for input,

more flexibility for scheduling, possibly improved result.

No blocking of resources while waiting for input,

more flexibility for scheduling, possibly improved result.

Universität Dortmund - 12 -

Example of a mixed TCM

…or they can define a probability for violating the deadline.

t

Deadline

Task1

Task2

Task3

Static (compile-time) methods can ensure WCET feasible schedules, but waste energy in the average case.

t

E

Deadline

Runtime scheduler selects the most energy saving, deadline preserving combination.

t

Deadline

Mixed methods use compile-time analysis to define a set of possible execution parameters for each task.

Universität Dortmund - 13 -

Example of an mixed TCM

„Gray-box“: Extract only the information needed for scheduling.

Transformations: Merge and/or split task. (Functionality comparable to Cortadella’s approach.)

Find Pareto-curves for each task.

Runtime scheduler: uses an heuristic to combine the Pareto-curves.

Universität Dortmund - 14 -

Fundamental considerations of tradeoffsby Brodersen (Berkeley)

Universität Dortmund - 15 -

FridgeFixed-Point Programming and Design Environment

• RWTH Aachen, commercialized by Synopsys as part of the CoCentric tool suite.

• Uses type definition features of C++ to define abstract data types (i.e. ‘fixed’)

• Incorporated into SystemC. (It’s used for bit-true simulation.)

• Needs architecture dependent back-end optimizations.

• RWTH Aachen, commercialized by Synopsys as part of the CoCentric tool suite.

• Uses type definition features of C++ to define abstract data types (i.e. ‘fixed’)

• Incorporated into SystemC. (It’s used for bit-true simulation.)

• Needs architecture dependent back-end optimizations.

Universität Dortmund - 16 -

FridgeFixed-Point Programming and Design Environment

Workflow overview:

• Input: floating-point algorithm + designer supplied annotations.

• Conversion. Iterative, feedback through simulation.

• Back-end exploits architectural features. (i.e. mulh, sat, round)

• Output: Target optimized integer C code.

• Input: floating-point algorithm + designer supplied annotations.

• Conversion. Iterative, feedback through simulation.

• Back-end exploits architectural features. (i.e. mulh, sat, round)

• Output: Target optimized integer C code.

Universität Dortmund - 17 -

FridgeFixed-Point Programming and Design Environment

DSP Back EndDSP Back End

• Designer annotates some operands (with WL, IWL, …)

• Hybrid code: Partially converted to fixed-point.

• Interpolation: Automatic annotate of remaining operands, transfer each operand into fixed-point type.

• Code Gen.: Generates pure C code.

• Back End: Optimize for target.

• Bit-true simulation.

• Designer annotates some operands (with WL, IWL, …)

• Hybrid code: Partially converted to fixed-point.

• Interpolation: Automatic annotate of remaining operands, transfer each operand into fixed-point type.

• Code Gen.: Generates pure C code.

• Back End: Optimize for target.

• Bit-true simulation.

Conversion steps:

Universität Dortmund - 18 -

Today’s summary

• Design-Productivity-Gap: No final remedy available, but step-by-step improvements keep costs in a reasonable range.

• Platform based design: Reuse is the key. PBD is the systematic approach to it.

• Task-Concurrency-Management: Optimize the task set. Goals: Non-blocking job execution / Increased energy efficiency.

• Float-point to Fixed-point: Fixed-point arithmetic uses integer operations Simpler and faster hardware than for float-point operations.

• Design-Productivity-Gap: No final remedy available, but step-by-step improvements keep costs in a reasonable range.

• Platform based design: Reuse is the key. PBD is the systematic approach to it.

• Task-Concurrency-Management: Optimize the task set. Goals: Non-blocking job execution / Increased energy efficiency.

• Float-point to Fixed-point: Fixed-point arithmetic uses integer operations Simpler and faster hardware than for float-point operations.