1 / 56

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

ODYSSEY : O bject-oriented D esign & S y nthe s i s of E mbedded S y stems. Maziar Goudarzi. Department of Computer Engineering Sharif University of Technology Tehran, Iran. The Computer Laboratory University of Cambridge Cambridge, UK. ODYSSEY.

tino
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related