ODYSSEY:Object-oriented Design & Synthesis of Embedded Systems

Maziar Goudarzi

Department of Computer EngineeringSharif University of Technology

Tehran, Iran

The Computer LaboratoryUniversity of Cambridge

Cambridge, UK

ODYSSEY

We advocate embedded-system development based on

Object-Oriented Application-Specific Instruction-set

Processor (OO-ASIP)

3

Outline

Motivation Approach Case Study Current Status A Look into the Future

4

Introduction Embedded Systems (ES)

Examples Importance General characteristics

Software costs more than hardware %80 vs %20 [ITRS-2001]

An ES “incrementally evolves” but not “suddenly revolve”.

Are not general-purpose computing systems Do not need to be programmable in all

programming models Allow, and encourage, use of special-purpose

models

5

Motivation- Why OO? Design Productivity

Gap By “National

Technology Roadmap for Semiconductors”, 1999

SW Dominance in cost

Routinely accounts for %80 of embedded system development cost [ITRS2001]

Figure from: LSI-Logic

6

Motivation- Why OO? (cont’d) OO Merits for ES development

SW dominance over HW in ES development cost

Reputation in SW engineering Reuse, complexity management, flexibility

Matches embedded system evolution model Makes a clear distinction between functionality

and communication (enables ASIP design) Clearly defines possible operations over data

(enables app.-specific memory architecture)

7

Motivation- Why ASIP?

From: K. Keutzer, S. Malik R. Newton, “From ASIC to ASIP: The Next Design Discontinuity”, ICCD, 2002

8

Motivation-Why ASIP? (cont’d)

Motivations The quadruple whammy Increasing manufacturing cost

ASIPs landscape ISA-based (Instruction-Set Architecture: ISA) Programmable-hardware based (e.g. FPGA)

Contemporary evidence Network processors Communication processors

9

Motivation-Why OO-ASIP?

OO methodology clearly separates functionality from communication Functionality: class methods Communication: method invocations

10

Challenges in ISA-based ASIP design?

How to define the instruction-set How to synthesise the ASIP How to program the ASIP

ODYSSEY

The Final Approach at a Glance

12

High-level System Model:Object-Oriented

A

D B

a1

a2

a3

b1b2

b3

d1

d2

b4

Message

Mes

sage

Resul

t

13

Object-Oriented Network-on-Chip

OO-ASIP 3

OO-ASIP 2OO-ASIP 1

Low-Level Implementation:OO Network-on-Chip

a1

a2

a3

b1b2

b3

d1

d2

b4

Message

Mes

sage

Resul

t

ODYSSEY

The OO-ASIP(Object-Oriented ASIP)

15

One HW-Engine per Class

ASIP Hardware

Centralised Data Memory

a

b1

d

aaa

ddd

b1b1b

The ASIP Approach

Comm.Bus

Instruction Memory

ap->f()

a2.g()

d1.f()

A methodsA::f, A::h

D methodsD::f, D::g

B methodsB::k

A

D B

f()h()

f()g()

k()

one implementation per method declaration

16

What does it mean?

A correspondence between Methods of a class library <-> ISA of an

ASIP Special case

int/float class with add/sub/mul methods corresponds to a traditional processor In other words

add r1,r2,r3 now becomes r1=r2.add(r3)

This view is a generalisation over traditional CPU operations (e.g. int::add, float::mul,…)

17

So What? The OO-ASIP is a superset of

traditional CPUs Still supports traditional CPU operations

e.g. int::add, float::mul, … Enables coarser-grained instructions

CISC-like or worse! Seems harder for compiler to generate code for But, OO addresses this

New view of memory and registers now storage for (possibly large) objects inspires object-based caching approach

18

So What? (cont’d) OO-ASIP is a superset of traditional

CPUs (cont’d) The FU can do field-at-a-time

operand-fetch less mem/reg access for big objects (cf.

network packet processors) Dynamic object (de)allocation

extends HW synthesis scope does not require reconfigurable HW

19

Enhancing ASIP Data-access Performance

ASIP Hardware

Centralised Data Memory

a

b1

d

aaa

ddd

b1b1b Instruction Memory

ap->m1()

a2.m1()

d1.m2()

A-introduced methods

D-introduced methods

B-introduced methods

ObjectManagement

Unitcache

20

The ODYSSEY OO-ASIP

ASIP Hardware

Centralised Data Memory

a

b1

d

aaa

ddd

b1b1b

Instruction Memory 1

ap->m1()

a2.m1()

d1.m2()

A-introduced methods

D-introduced methods

B-introduced methods

ObjectManagement

Unitcache

On-ch

ip

Netw

ork

InstructionProcessor

21

Handling method calls Assuming no polymorphism

Simple, handled statically. Method realisation (HW or SW) is known

SW caller: Compiler generates code to:

evaluate parameters (to stack or registers) branch-and-link if SW callee invoke-functional-unit if HW callee

HW caller: The same, but done in HW ODYSSEY-preprocessor modifies source-code to

make synthesiser generate proper RTL operations.

22

Handling Method Calls (cont’d) Now, considering polymorphism

The key point in OO methodology Method realisation not-known at

compile-time Run-time method-despatch required

Implies area/performance/power overhead

Main criticism made to OO We implement it for free!

Unify method-despatch with packet-routing in the NoC OO-ASIP

23

Polymorphism in NoC OO-ASIP

FU-identifier: FU=<method.class>

Object-identifier: object=<class.num>

Method call = invoke a method on an object <method.object> = <method.<class.num>> = <<method.class>.num> = <FU.num> = Packet destined to the node addressed FU

24

Polymorphism in NoC OO-ASIP (cont’d) To dynamically bind a method call

(e.g. objp->method(params) in C++)1. Assemble a packet as

<method, objp, params>2. Send it over the on-chip network

Polymorphism is unified with network packet routing

Packet routing inevitable in NoC Hence, polymorphism for free!

Parameter passing Transmitted as data payload of the packet

25

Multiple Processors inThe NoC OO-ASIP

ASIP Hardware

Centralised Data Memory

a

b1

d

aaa

ddd

b1b1b

Instruction Memory 1

ap->m1()

a2.m1()

d1.m2()

A-introduced methods

D-introduced methods

B-introduced methods

ObjectManagement

Unitcache

On-ch

ip

Netw

ork

Processor2

Processor1

Instruction Memory 2

bp->m2()

d2.m1()

a1.m2()

ODYSSEY

Direct Consequences of The OO-ASIP Approach

27

Direct Consequences HW Patching through SW

Dynamic binding supported SW methods can override out-dated or buggy HW

methods HW/SW Co-design

Partitioning quantum is the class methods Is hinted by the designer and his intuition

Having the ODYSSEY-preprocessor, rapid design-space exploration is possible

App.-Specific Dynamic Power Management An approach to Reconfigurable Computing

28

Application-SpecificDynamic Power Management

Distributed DPM Each FU manages itself

The network-access unit of each FU awakens the FU when a packet is received.

29

Application-SpecificDynamic Power Management (cont’d)

Switch-off done by Clock gating, using Synopsys BC PLL still active

negligible wake-up time (one clock cycles)

Orthogonal to other CPU dynamic power-management schemes e.g. OS-based power-management

30

An Approach to Reconfigurable Computing Add a swapper FU receiving all packets

destined to FUs not currently swapped-in Algorithm:

1. Identify the target FU2. Swap-in the FU implementation3. Invoke the FU passing it the packet4. Update own network-address not to receive packets

for this new FU When the swapped-in FU finishes

1. Inform the swapper-FU to update its network-address2. Destruct itself (i.e. free the hardware blocks allocated)

ODYSSEY

Single-Processor OO-ASIP Design Flow

32

Software

Application

SW Model Object

Instantiation

ApplicationClass Lib.

Single-ProcessorODYSSEY Design Elements

A

D B

f()h()

f()g()h()

k()

ASIPClass Lib.

DD BB

CExtendingClass Lib.

CompilationC++

Hardware

ASIP Hardware

ASIP SynthesisSystemC (C++)

ASIP ISA: f, g, k

33

Single-ProcessorODYSSEY Design Flow

OO-ASIP Design Flow

Disciplined Benchmarking

Hardware Class lib.

OO-ASIP Synthesis

The OO-ASIP

(OO-ASIP, HW Class Lib.)

Database

OO-System Development Flow

Choose proper class lib.

HW class lib.

Model+verify the App.

Compile toward the ASIPOO ASIP

Data memory Instr. memory

34

OO-ASIP Synthesis

App. DomainClass lib.

HW Methods Definition in C++

Functional-Unit (FU)

OO-ASIP

Invariant Templatesin SystemC

Customised OO-ASIP

Behavioural SynthesisSynopsys SystemC Compiler

Gate-level OO-ASIP

GNU C++ Compiler

Exec. modelto validate

Customised FUs

35

Model and verify the Application

HW class lib.C++

Augment to match application needs

Software class lib.

System class lib.C++

GNU C++ Compiler

Executable for functional validation

OO model of the application

36

Compile toward the OO-ASIP

Need Retargettable compiler To replace method calls with proper ASIP

opcode Efficiently manipulate registers

Non-uniform (not a register-file) Differ from OO-ASIP to OO-ASIP

Identical encoding for a virtual method and all its overriding definitions

Otherwise the method would be compile-time decidable

A

D B

f()h()

f()g()

k()

A::f and D::f share the same opcode,but different from A::h, D::g, and B::k

37

ODYSSEY ApproachSummary Establishes a correspondence between

methods in a class library and instructions of an ASIP Enables dynamic hardware patching by

software Enables OO HW/SW Co-design

Implementation approach results in No-overhead polymorphism in NoC realisation Dynamic power management Reconfigurable computing

38

ODYSSEY ApproachSummary (cont’d)

Limiting factors: No recursive call through hw

ODYSSEY

Case Study

40

Case Study

Traffic-light controller problem Highway always open If somebody on farmroad

1. Wait until highway open at least for min_green time,1. Open farmroad for fixed_green time2. Reopen highway

41

Case StudyClass Library + programs

traffic_light

farmroad_light highway_light

int stateint elapsed_time

open()close()time_keeper()

int fixed_green

open()

int min_green

close()farmroad_light frl(1);highway_light hwl(5);

main() { frl.close(); hwl.open(); forever do { if(frl_sensor) { hwl.close(); frl.open(); frl.close(); //unnecessary hwl.open(); }}}

traffic_light *p;

ISR() { for all objects obj do { p = &obj; p->time_keeper(); }}

42

Case StudyExperimental Results

Area (equivalent gates)

Frequency

(MHz)Total MIU OMU

Functional Units

traffic_light farmroad highway

open closetime_keeper

open Close

TLC ASIP 7088 433 1845 429 887 564 1558 1372 98.6

Share in total area (%)

100 6.1 26.0 6.1 12.5 8.0 22.0 19.4 -

Synthesis results as reported by LeonardoSpectrum® over a sample 0.5u process

43

Case StudyReusing the OO-ASIP New problem

4 TLCs at junction of 4 roads Each light has a fixed green time

farmroad_light lights[4];

main() { forever do { lights[0].open(); lights[1].close(); lights[2].close(); lights[3].close(); lights[0].close(); lights[1].open(); lights[2].close(); lights[3].close(); lights[0].close(); lights[1].close(); lights[2].open(); lights[3].close(); lights[0].close(); lights[1].close(); lights[2].close(); lights[3].open(); }}

No class extension required Could statically turn-off (or purge if FPGA) the

unwanted FUs

ODYSSEY

Current Status

45

Current Status MIU-based OO-ASIP synthesis path

ISA a subset of JVM, no new instructions

added. invokevirtual is dispatched by MIU to

either HW or SW ODYSSEY-preprocessor

missing, currently manual Target technology

A sample ASIC technology from Synopsys For FPGA, hope to use Synopsys FPGA

Compiler

46

Current Status (cont’d)

NoC-based OO-ASIP The FUs are no longer closely coupled

co-processors of the traditional processor

Easier integration of any processor core Network layer is under development

47

Current Status (cont’d)

ASIP programming path manual, compiler is under

investigation ODYSSEY web page

http://www.cl.cam.ac.uk/users/mg342/odyssey

ODYSSEY

A Look into the Future

49

aHW engine

for AaHW engine

for A

dHW engine

for DdHW engine

for D

bb

Realising an OO Model in HW:One HW-engine per object

a

d

b

HW engine for A methods

D engine

B engine

ODETTE Project

http://odette.offis.de

Fixed Wiring

50

ODYSSEY Multiprocessor NoC1 ≤ Nengines ≤ Nobjects

aa

d

d

bb

a

db

OO-ASIP 1

OO-ASIP 2

OO-ASIP 3

Packet-routing

network on chip

Spectrum between Single-OOASIP and ODETTE approaches

51

Application-specific memory architectures

OO merit inhibits arbitrary operations on data

Results in Data need not be routable to

everywhere Main Random-access memory not

essential Hint: Keep objects near their corresponding

engines

52

Enhancing The OO-ASIP itself:VLIW Architecture

VLIW OO-ASIP Hardware

Data Memory 1

a

b1

d

aaa

ddd

b1b1b

Instruction Memory/FPGA

ap->m1()

a2.m1()

d1.m1()

A methods

D methods

B methods

Disp

atch

er

A methods

B methods

B methods

Data Memory 3

a

b1

d

aaa

ddd

b1b1b

Data Memory 2

a

b1

d

aaa

ddd

b1b1b

Netw

ork

53

Enhancing The OO-ASIP itself:FPGA instead of instructions

OO-ASIP Hardware

Centralised Data Memory

a

b1

d

aaa

ddd

b1b1b

FPGA Blocks

ap->m1()

a2.m1()

d1.m1()

A-introduced methods

D-introduced methods

B-introduced methods

b2.m2()

Reminds of VLIW Architecture, but with HW instructions instead

OMU

cache

On-ch

ip

Netw

ork

54

Enhancing The OO-ASIP itself

Evolvable ISA processor FPGA blocks for new FUs No modification to the processor core

required

55

A Look into the Future:Other concepts to consider

High-level model of time to enable early performance evaluation

Formal verification Message-Flow Graph maybe?

Recursive call through hardware Synthesise methods so that save

required internal state before getting re-invoked

Use tail-recursive calls

ODYSSEY

Thanks + Q&A