18
Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

Embed Size (px)

Citation preview

Page 1: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

Universität Dortmund

EECE **** Embedded System Design

Chapter 5A: Hardware/Software Codesign

Page 2: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

Universität Dortmund - 2 -

Hardware/Software Codesign

Page 3: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

Universität Dortmund - 3 -

Design productivity gap

Page 4: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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

Page 5: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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

Page 6: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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:

Page 7: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

Universität Dortmund - 7 -

Iterative approach (1)

Guided by performance evaluation

Guided by performance evaluation

Page 8: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

Universität Dortmund - 8 -

Essentially the same with our flow …

System architecture

Performance simulation

Ref

ineSystem behavior

Implementation

Mapping

Page 9: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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.

Page 10: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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.

Page 11: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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.

Page 12: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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.

Page 13: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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.

Page 14: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

Universität Dortmund - 14 -

Fundamental considerations of tradeoffsby Brodersen (Berkeley)

Page 15: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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.

Page 16: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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.

Page 17: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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:

Page 18: Universität Dortmund EECE **** Embedded System Design Chapter 5A: Hardware/Software Codesign

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.