ODYSSEY : O bject-oriented D esign & S y nthe s i s of E mbedded S y stems

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

2. 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

11. ODYSSEY The Final Approach at a Glance

12. High-level System Model:Object-Oriented a3 Message b2 b1 a1 b4 Message Result a2 d2 b3 A d1 D B

13. Low-Level Implementation:OO Network-on-Chip Object-Oriented Network-on-Chip OO-ASIP 1 a3 OO-ASIP 3 Message b2 OO-ASIP 2 b1 a1 b4 Message Result a2 d2 b3 d1

14. ODYSSEY The OO-ASIP (Object-Oriented ASIP)

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

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 A-introduced methods Centralised Data Memory a a a a Instruction Memory D-introduced methods ap->m1() a2.m1() B-introduced methods d d d d d1.m2() b1 b1 b1 b ObjectManagement Unit cache

20. The ODYSSEY OO-ASIP ASIP Hardware A-introduced methods Centralised Data Memory On-chip Network Instruction Memory 1 ap->m1() a a a a D-introduced methods a2.m1() InstructionProcessor B-introduced methods d1.m2() d d d d b1 b1 b1 b ObjectManagement Unit cache

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++) • Assemble a packet as<method, objp, params> • 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 Instruction Memory 1 ap->m1() a2.m1() d1.m2() Centralised Data Memory ASIP Hardware Processor 1 A-introduced methods a a a a On-chip Network D-introduced methods d d d d B-introduced methods Instruction Memory 2 bp->m2() d2.m1() b1 b1 b1 b ObjectManagement Unit a1.m2() cache Processor 2

26. 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: • 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 • Inform the swapper-FU to update its network-address • Destruct itself (i.e. free the hardware blocks allocated)

31. ODYSSEY Single-Processor OO-ASIP Design Flow

32. ApplicationSW Model ASIPClass Lib. A f()h() Object Instantiation Software C++ Compilation D f()g()h() B k() ASIP ISA: f, g, k DD BB ExtendingClass Lib. SystemC (C++) C Hardware ASIP Synthesis ApplicationClass Lib. ASIP Hardware Single-ProcessorODYSSEY Design Elements

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

34. Invariant Templatesin SystemC App. DomainClass lib. Functional-Unit (FU) OO-ASIP HW Methods Definition in C++ Customised FUs GNU C++ Compiler CustomisedOO-ASIP Exec. modelto validate Behavioural SynthesisSynopsys SystemC Compiler Gate-levelOO-ASIP OO-ASIP Synthesis

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

36. A f()h() f()g() D B k() A::f and D::f share the same opcode,but different from A::h, D::g, and B::k 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

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

39. ODYSSEY Case Study

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

41. Case StudyClass Library + programs int stateint elapsed_time open()close()time_keeper() traffic_light 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(); }}

42. Case StudyExperimental Results 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

44. 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

48. ODYSSEY A Look into the Future

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

50. ODYSSEY Multiprocessor NoC1 ≤ Nengines ≤ Nobjects Spectrum between Single-OOASIP and ODETTE approaches a OO-ASIP 1 a a Packet-routingnetwork on chip d OO-ASIP 2 d b d OO-ASIP 3 b b