ODYSSEY Objectoriented Design Synthesis of Embedded Systems Maziar

ODYSSEY: Object-oriented Design & Synthesis of Embedded Systems Maziar Goudarzi Department of Computer Engineering Sharif University of Technology Tehran, Iran The Computer Laboratory University of Cambridge, UK

ODYSSEY We advocate embedded-system development based on Object-Oriented Application-Specific Instruction-set Processor (OO-ASIP)

Outline n n n Motivation Approach Case Study Current Status A Look into the Future 3

Introduction n Embedded Systems (ES) n n n Examples Importance General characteristics n Software costs more than hardware n n n %80 vs %20 [ITRS-2001] An ES “incrementally evolves” but not “suddenly revolve”. Are not general-purpose computing systems n n Do not need to be programmable in all programming models Allow, and encourage, use of special-purpose models 4

Motivation- Why OO? n Design Productivity Gap n n By “National Technology Roadmap for Semiconductors”, 1999 SW Dominance in cost n Routinely accounts for %80 of embedded system development cost [ITRS 2001] Figure from: LSI-Logic 5

Motivation- Why OO? (cont’d) n OO Merits for ES development n n SW dominance over HW in ES development cost Reputation in SW engineering n n 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) 6

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

Motivation-Why ASIP? (cont’d) n Motivations n n n ASIPs landscape n n n The quadruple whammy Increasing manufacturing cost ISA-based (Instruction-Set Architecture: ISA) Programmable-hardware based (e. g. FPGA) Contemporary evidence n n Network processors Communication processors 8

Motivation-Why OO-ASIP? n OO methodology clearly separates functionality from communication n n Functionality: class methods Communication: method invocations 9

Challenges in ISA-based ASIP design? n n n How to define the instruction-set How to synthesise the ASIP How to program the ASIP 10

ODYSSEY The Final Approach at a Glance

High-level System Model: Object-Oriented a 3 Message b 1 a 1 b 2 lt Re M a 2 su es s ag e b 4 d 2 A b 3 d 1 D B 12

Low-Level Implementation: OO Network-on-Chip a 3 Message b 1 a 1 b 2 lt Re M a 2 su es s ag e b 4 d 2 d 1 OO-ASIP 1 b 3 OO-ASIP 2 Object-Oriented Network-on-Chip 13

ODYSSEY The OO-ASIP (Object-Oriented ASIP)

One HW-Engine per Class D aaaa Comm. Bus dddd b 1 b 1 b A methods A: : f, A: : h D methods D: : f, D: : g B methods B: : k Centralised Data Memory ASIP Hardware The ASIP Approach A f() h() f() g() B k() ap->f() a 2. g() d 1. f() Instruction Memory one implementation per method declaration 15

What does it mean? n A correspondence between n n Methods of a class library <-> ISA of an ASIP Special case n n n int/float class with add/sub/mul methods corresponds to a traditional processor In other words n n add r 1, r 2, r 3 now becomes r 1=r 2. add(r 3) This view is a generalisation over traditional CPU operations (e. g. int: : add, float: : mul, …) 16

So What? n The OO-ASIP is a superset of traditional CPUs n Still supports traditional CPU operations n n e. g. int: : add, float: : mul, … Enables coarser-grained instructions n CISC-like or worse! n n n Seems harder for compiler to generate code for But, OO addresses this New view of memory and registers n n now storage for (possibly large) objects inspires object-based caching approach 17

So What? (cont’d) n OO-ASIP is a superset of traditional CPUs (cont’d) n The FU can do field-at-a-time operandfetch n n less mem/reg access for big objects (cf. network packet processors) Dynamic object (de)allocation n n extends HW synthesis scope does not require reconfigurable HW 18

Enhancing ASIP Data-access Performance A-introduced methods aaaa D-introduced methods B-introduced methods dddd b 1 b 1 b Centralised Data Memory Object cache Management Unit ASIP Hardware ap->m 1() a 2. m 1() d 1. m 2() Instruction Memory 19

The ODYSSEY OO-ASIP A-introduced methods aaaa B-introduced methods dddd b 1 b 1 b Centralised Data Memory On-chip Network D-introduced methods ap->m 1() Object cache Management Unit ASIP Hardware Instruction Processor a 2. m 1() d 1. m 2() Instruction Memory 1 20

Handling method calls n Assuming no polymorphism n Simple, handled statically. n n Method realisation (HW or SW) is known SW caller: n Compiler generates code to: n n evaluate parameters (to stack or registers) branch-and-link if SW callee invoke-functional-unit if HW callee HW caller: n n The same, but done in HW ODYSSEY-preprocessor modifies source-code to make synthesiser generate proper RTL operations. 21

Handling Method Calls (cont’d) n Now, considering polymorphism n n n The key point in OO methodology Method realisation not-known at compiletime Run-time method-despatch required n n n Implies area/performance/power overhead Main criticism made to OO We implement it for free! n Unify method-despatch with packet-routing in the No. C OO-ASIP 22

Polymorphism in No. C OO-ASIP n FU-identifier: n n Object-identifier: n n FU=<method. class> object=<class. num> Method call = invoke a method on an object n <method. object> = <method. <class. num>> = <<method. class>. num> = <FU. num> = Packet destined to the node addressed FU 23

Polymorphism in No. C OO-ASIP (cont’d) n To dynamically bind a method call (e. g. objp->method(params) in C++) 1. 2. n Polymorphism is unified with network packet routing n n n Assemble a packet as <method, objp, params> Send it over the on-chip network Packet routing inevitable in No. C Hence, polymorphism for free! Parameter passing n Transmitted as data payload of the packet 24

Multiple Processors in The No. C OO-ASIP ap->m 1() a 2. m 1() d 1. m 2() aaaa Processor 1 A-introduced methods Instruction Memory 1 D-introduced methods B-introduced methods On-chip Network dddd bp->m 2() b 1 b 1 b Centralised Data Memory d 2. m 1() Object cache Management Unit ASIP Hardware a 1. m 2() Processor 2 Instruction Memory 2 25

ODYSSEY Direct Consequences of The OO-ASIP Approach

Direct Consequences n HW Patching through SW n Dynamic binding supported n n HW/SW Co-design n Partitioning quantum is the class methods n n SW methods can override out-dated or buggy HW methods Is hinted by the designer and his intuition Having the ODYSSEY-preprocessor, rapid designspace exploration is possible App. -Specific Dynamic Power Management An approach to Reconfigurable Computing 27

Application-Specific Dynamic Power Management n Distributed DPM n n Each FU manages itself The network-access unit of each FU awakens the FU when a packet is received. 28

Application-Specific Dynamic Power Management (cont’d) n Switch-off done by n n Clock gating, using Synopsys BC PLL still active n n negligible wake-up time (one clock cycles) Orthogonal to other CPU dynamic power -management schemes n e. g. OS-based power-management 29

An Approach to Reconfigurable Computing Add a swapper FU receiving all packets destined to FUs not currently swapped-in n n Algorithm: 1. 2. 3. 4. n Identify the target FU Swap-in the FU implementation Invoke the FU passing it the packet Update own network-address not to receive packets for this new FU When the swapped-in FU finishes 1. 2. Inform the swapper-FU to update its networkaddress Destruct itself (i. e. free the hardware blocks allocated)30

ODYSSEY Single-Processor OO-ASIP Design Flow

Single-Processor ODYSSEY Design Elements Application SW Model Software C++ ASIP ISA: Hardware Compilation f, g, k System. C (C++) ASIP Synthesis ASIP Hardware In Obj sta ec nti t ati on ASIP Class Lib. A f() h() D f() g() h() B DD Extending Class Lib. k() BB C Application Class Lib. 32

Single-Processor ODYSSEY Design Flow OO-ASIP Design Flow OO-System Development Flow Disciplined Benchmarking (OO-ASIP, HW Class Lib. ) Choose proper class lib. Database Hardware Class lib. HW class lib. Model+verify the App. OO-ASIP Synthesis The OO-ASIP Data memory OO ASIP Compile toward the ASIP Instr. memory 33

OO-ASIP Synthesis App. Domain Class lib. Invariant Templates in System. C Functional-Unit OO-ASIP (FU) HW Methods Definition in C++ Customised FUs Customised OO-ASIP GNU C++ Compiler Exec. model to validate Behavioural Synthesis Synopsys System. C Compiler Gate-level OO-ASIP 34

Model and verify the Application HW class lib. C++ Augment to match application needs Software class lib. System class lib. C++ OO model of the application GNU C++ Compiler Executable for functional validation 35

Compile toward the OO-ASIP n Need Retargettable compiler n n To replace method calls with proper ASIP opcode Efficiently manipulate registers n n n D A f() h() f() g() B Non-uniform (not a register-file) Differ from OO-ASIP to OO-ASIP Identical encoding for a virtual method and all its overriding definitions k() n Otherwise the method would be compile-time decidable A: : f and D: : f share the same opcode, but different from A: : h, D: : g, and B: : k 36

ODYSSEY Approach Summary n Establishes a correspondence between methods in a class library and instructions of an ASIP n n n Enables dynamic hardware patching by software Enables OO HW/SW Co-design Implementation approach results in n No-overhead polymorphism in No. C realisation Dynamic power management Reconfigurable computing 37

ODYSSEY Approach Summary (cont’d) n Limiting factors: n No recursive call through hw 38

ODYSSEY Case Study

Case Study Traffic-light controller problem n n n Highway always open If somebody on farmroad 1. Wait until highway open at least for min_green time, 1. 2. Open farmroad for fixed_green time Reopen highway 40

Case Study Class Library + programs traffic_light int state int elapsed_time open() close() time_keeper() farmroad_light int fixed_green open() highway_light 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(); } } 41

Case Study Experimental Results Synthesis results as reported by Leonardo. Spectrum® over a sample 0. 5 u process Area (equivalent gates) Functional Units Total MIU traffic_light OMU farmroad highway open close time_ keeper open Close Freque ncy (MHz) 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 42

Case Study Reusing the OO-ASIP n New problem n 4 TLCs at junction of 4 roads n Each light has a fixed green time farmroad_lights[4]; main() { forever do { lights[0]. open(); lights[0]. close(); } } n n lights[1]. close(); lights[1]. open(); lights[1]. close(); lights[2]. close(); lights[2]. open(); lights[2]. close(); lights[3]. close(); lights[3]. open(); No class extension required Could statically turn-off (or purge if FPGA) the unwanted FUs 43

ODYSSEY Current Status

Current Status n MIU-based OO-ASIP synthesis path n ISA n n n ODYSSEY-preprocessor n n a subset of JVM, no new instructions added. invokevirtual is dispatched by MIU to either HW or SW missing, currently manual Target technology n n A sample ASIC technology from Synopsys For FPGA, hope to use Synopsys FPGA Compiler 45

Current Status (cont’d) n No. C-based OO-ASIP n The FUs are no longer closely coupled coprocessors of the traditional processor n n Easier integration of any processor core Network layer is under development 46

Current Status (cont’d) n ASIP programming path n n manual, compiler is under investigation ODYSSEY web page http: //www. cl. cam. ac. uk/users/mg 342/odyssey 47

ODYSSEY A Look into the Future

Realising an OO Model in HW: One HW-engine per object ODETTE Project http: //odette. offis. de HW engine HW HWengine for for. AA aa a dd d for A methods HW HWengine for DD Dfor engine b b b Fixed Wiring B engine 49

ODYSSEY Multiprocessor No. C 1 ≤ Nengines ≤ Nobjects Spectrum between Single-OOASIP and ODETTE approaches aa a OO-ASIP 1 Packet-routing d network on chip OO-ASIP 2 d b b OO-ASIP 3 50

Application-specific memory architectures n OO merit n n inhibits arbitrary operations on data Results in n n Data need not be routable to everywhere Main Random-access memory not essential n Hint: Keep objects near their corresponding engines 51

Enhancing The OO-ASIP itself: VLIW Architecture aaaa A methods dddd D methods B methods Data Memory 2 aaaa dddd Dispatcher Data Memory 1 b 1 b ap->m 1() b 1 b 1 b Network aaaa A methods d 1. m 1() B methods b 1 b 1 b Data Memory 3 a 2. m 1() Instruction Memory/FPGA VLIW OO-ASIP Hardware 52

Enhancing The OO-ASIP itself: FPGA instead of instructions A-introduced methods ap->m 1() aaaa B-introduced methods dddd b 1 b 1 b Centralised Data Memory cache On-chip Network D-introduced methods a 2. m 1() d 1. m 1() b 2. m 2() O M U FPGA Blocks OO-ASIP Hardware Reminds of VLIW Architecture, but with HW instructions instead 53

Enhancing The OO-ASIP itself n Evolvable ISA processor n n FPGA blocks for new FUs No modification to the processor core required 54

A Look into the Future: Other concepts to consider n High-level model of time n n Formal verification n n to enable early performance evaluation Message-Flow Graph maybe? Recursive call through hardware n n Synthesise methods so that save required internal state before getting re-invoked Use tail-recursive calls 55

ODYSSEY Thanks + Q&A