1 / 33

Metropolis Design Environment for Heterogeneous Systems

etropolis. Metropolis Design Environment for Heterogeneous Systems. Luciano Lavagno Cadence Berkeley Labs & Politecnico di Torino Metropolis Project Team. Outline. System-level design scenario Metropolis design flow Meta-model syntax processes and media constraints and schedulers

Gabriel
Download Presentation

Metropolis Design Environment for Heterogeneous Systems

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. etropolis MetropolisDesign Environment for Heterogeneous Systems Luciano Lavagno Cadence Berkeley Labs & Politecnico di Torino Metropolis Project Team

  2. Outline • System-level design scenario • Metropolis design flow • Meta-model syntax • processes and media • constraints and schedulers • Meta-model semantics • Conclusions

  3. Multiplexed Systems IVHS Infrastructure Cellular Phone Body Control Info/Comms/ AV Bus Vehicle CAN Bus Navigation Suspension Transmission Stereo/CD Display ABS GPS ECU Electronic Toll Collection Collision Avoidance Vehicle ID Tracking Wireless Communications/DataGlobal Positioning SW Architecture Performance Modelling Network Design/Analysis Function / Protocol Validation Supplier Chain Integration A Modern Car, an Electronic System

  4. Constraints Simple env. model Kernel benchmarks System specification Sub-function specifications Detailed env. models Abstract local architectures Refined global architecture Design Roles and Interactions System architect Algorithm+SW developer Algorithm+SW developer Platform developer Detailed local architectures Platform developer Algorithm+SW developer Platform developer CPU + RTOS + HW implementations Sub-function implementations System integrator Systemimplementation

  5. f f f f f ?? f f f f f f f f f f f f ?? f f f f f ?? f f f f f Design Scenarios

  6. etropolis Metropolis Project • Goal: develop a formal design environment • Design methodologies: abstraction levels, design problem formulations • Design automation tools: A modeling mechanism: heterogeneous semantics, concurrency Formal methods for automatic synthesis and verification • Participants: • Cadence Berkeley Labs (USA): methodologies, modeling, formal methods • UC Berkeley (USA): methodologies, modeling, formal methods • Politecnico di Torino (Italy): modeling, formal methods • Universitat Politecnica de Catalunya (Spain): modeling, formal methods • CMU (USA): formal methods • Philips (Netherlands): methodologies (multi-media) • Nokia (USA, Finland): methodologies (wireless communication) • BWRC (USA): methodologies (wireless communication) • BMW (USA, Germany): methodologies (fault-tolerant automotive controls) • Intel (USA): methodologies (microprocessors)

  7. Orthogonalization of concerns Separate: • functionality from architectural platform(function requires services offered by architecture) • increased re-use • use same level of abstraction for HW and SW • design space exploration • drive synthesis algorithms (compiler, scheduler, …) • separates behavior from performance (time, power, …) • performance derives from mapping • computation from communication • computation (functionality) is scheduled and compiled • communication (interfacing) is refined via patterns based on mapping

  8. Function Specification Metropolis Formal Methods: Synthesis/Refinement Metropolis Formal Methods: Analysis/Verification Metropolis Framework Architecture Specification Design Constraints • Metropolis Infrastructure • Design methodology • Meta model of computation • Base tools • - Design imports • - Meta model compiler • - Simulation

  9. Function Specification Metropolis Formal Methods: Synthesis/Refinement Metropolis Formal Methods: Analysis/Verification Metropolis Framework: methodology Architecture Specification Design Constraints • Metropolis Infrastructure • Design methodology • Meta model of computation • Base tools • - Design imports • - Meta model compiler • - Simulation

  10. Functional Decomposition MPEG Decoder VLD IDCT MC DISPLAY

  11. Communication VLD IDCT MC DISPLAY BA IZ,IQ BA MEM BA MEM VLD IDCT MC DISPLAY M BA IZ,IQ M M BA MEM M M BA MEM M M

  12. CA CA Refinement Lossless VLD IDCT MC DISPLAY M BA IZ,IQ M M BA MEM M M BA MEM M M Lossy M’ Mi Mi M

  13. M Refinement VLD IDCT MC DISPLAY BA IZ,IQ M M BA MEM M M BA MEM M M VLD IDCT MC DISPLAY BA IZ,IQ M BA MEM M BA MEM M M M M M M M M SEG SEG REAS SEG REAS REAS BUS

  14. MC M BA MEM Optimization VLD IDCT DISPLAY BA IZ,IQ M BA MEM M M M M M M M M SEG SEG REAS SEG REAS REAS BUS

  15. Function Specification Metropolis Formal Methods: Synthesis/Refinement Metropolis Formal Methods: Analysis/Verification Metropolis Framework: meta-model Architecture Specification Design Constraints • Metropolis Infrastructure • Design methodology • Meta model of computation • Base tools • - Design imports • - Meta model compiler • - Simulation

  16. Metropolis Meta Model • Do not commit to the semantics of a particular Model of Computation (MoC) • Define a set of “building blocks”: • specifications with many useful MoCs can be described using the building blocks. • unambiguous semantics for each building block. • syntax for each building block a language of the meta model. • Represent behavior at all design phases; mapped or unmapped Question: What is a good set of building blocks?

  17. computation • f: X Z • firing rule Metropolis Meta Model • coordination • constraints on concurrent actions • action annotation with quantity requests (time, energy, memory) • algorithms to enforce the constraints The behavior of a concurrent system: • communication • state • methods to • - store data • - retrieve data processes media constraints andquantity managers process P1{ port pX, pZ; thread(){ // condition to read X // an algorithm for f(X) // condition to write Z } } P1 P2 M pX pZ pX pZ medium M{ int[] storage; int space; void write(int[] z){ ... } int[] read(){ ... } } M’ M’ S P1.pZ.write()  P2.pX.read()

  18. p0 c0 m0 p1 p2 c1 m1 p3 Netlist • Define • processes, media, schedulers, netlists • connections among the objects • constraints • used also for specifying refinements DoubleStream

  19. w0 IntM ByteM r0 wk Communication and computation refinement RefIntM refine Define a refinement “pattern”: 1. Define objects that constitute the refinement. 2. Define connections among the refinement objects. 3. Specify connections with objects outside the refinement netlist: • Some objects in the refinement may be internally created; others may be given externally. • write a constructor of the refinement netlist for each refinement scenario.

  20. p0 c0 m0 p1 p2 m1 c1 p3 Netlist after Refinement // create mb, and then refine m0 and m1. ByteM mb = new ByteM(); RefIntM refm0 = new RefIntM(m0, mb); RefIntM refm1 = new RefIntM(m1, mb); But, we need coordination: - if p0 has written to mb, c0 must read. - if p2 has written to mb, c1 must read. - ... refm0 w0 r0 w1 mb w0 r0 w1 refm1

  21. Constraints Two mechanisms are supported to specify constraints: 1. Propositions over temporal orders of states • execution is a sequence of states • specify constraints using linear temporal logic • good for functional constraints, e.g. “if process P starts to execute a statement s1, no other process can start the statement until P reaches a statement s2.” 2. Propositions over instances of transitions between states • particular transitions in the current execution: called “actions” • annotate actions with quantity, such as time, power. • specify constraints over actions with respect to the quantities • good for performance constraints, e.g. “any successive actions of starting a statement s1 by process P must take place with at most 10ms interval.”

  22. MyArchNetlist … … … Bus Arbiter Bus CPU + OS Mem Arbiter Mem Cpu OsSched Master Slave Meta-model: architecture netlist Architecture netlist specifies configurations of architecture components. Each netlist constructor - instantiates architectural components, - connects them, - takes as input mapping processes.

  23. thread(){ while(true){ await { (true; ; ;) readCpu(); (true; ; ;) mapf(); (true; ; ;) readWrite(); }}} B(P, X.read) <=> B(MapP, readCpu); E(P, X.read) <=> E(MapP, readCpu); B(P, f) <=> B(MapP, mapf); E(P, f) <=> E(MapP, mapf); … Meta-model: mapping processes Mapping process Function process process MapP{ port CpuService Cpu; void readCpu(){ Cpu.exec(); Cpu.cpuRead(); } void mapf(){ …} … } process P{ port reader X; port writer Y; thread(){ while(true){ ... z = f(X.read()); Y.write(z); }}}

  24. MyFncNetlist P1 P2 M Env2 Env1 MyArchNetlist … MyArchNetlist … mP1 mP1 mP2 mP2 … Bus Arbiter Bus Arbiter Bus Bus Mem Mem Cpu Cpu OsSched OsSched Meta-model: mapping netlist MyMapNetlist B(P1, M.write) <=> B(mP1, mP1.writeCpu); E(P1, M.write) <=> E(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, mP1.mapf); B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, M.read) <=> E(mP2, mP2.readCpu); B(P2, P2.f) <=> B(mP2, mP2.mapf); E(P2, P2.f) <=> E(mP2, mP2.mapf);

  25. B(Q2, S.cdx) <=> B(Q2, mQ2.excCpu); E(Q2, M.cdx) <=> E(mQ2, mQ2.excCpu); B(Q2, Q2.f) <=> B(mQ2, mQ2.mapf); E(Q2, P2.f) <=> E(mQ2, mQ2.mapf); N' N S MyMapNetlist1 B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf); P1 P2 MyFncNetlist MyArchNetlist B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, ) B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf); M M P1 P2 MyFncNetlist MyArchNetlist M Meta-model: recursive platforms

  26. Execution semantics • Processes take actions • statements and function calls are actions • e.g. y=x+port.f();, x+port.f(), port.f() • only calls to media functions are observable actions • Behaviors are sequences of vectors of events • events are beginning of an action (B port.f()), end of an action (E port.f()), no-op (N), • one event per (sequential) process in a vector • A sequence of vectors of events is a legal behavior if it • satisfies all constraints • is accepted by all action automata(one for each action of each process)

  27. Function Specification Metropolis Formal Methods: Synthesis/Refinement Metropolis Formal Methods: Analysis/Verification Metropolis Framework: tools Architecture Specification Design Constraints • Metropolis Infrastructure • Design methodology • Meta model of computation • Base tools • - Design imports • - Meta model compiler • - Simulation

  28. Formal Models for analysis and synthesis • Formal model: derived from the meta-model for applying formal methods • Mathematical formulations of the semantics of the meta model: • - each construct (‘if’, ‘for’, ‘await’, ...) • - sequence of statements • - composition of connected objects •  the semantics may be abstracted • Restrictions on the meta model • Formal methods (verification and synthesis) applicable on given models

  29. Example of formal model: Petri nets reader_unlock 2 pX.n() reader_lock 2 await(pX.n()>=2)[pX.reader] for(i=0; i<2; i++) x[i]=pX.read(); i=0; i<2? Restriction: condition inside await is conjunctive. x[i]=pX.read(); i++; • Formal Methods on Petri nets: • analyze the schedulability • analyze upper bounds of storage sizes • synthesize schedules end of await

  30. Example: quasi-static scheduling • Specify a network of processes • Translate to the computational model • Petri net • Find a “schedule” on the Petri net • Translate the schedule to a new set of processes

  31. Design automation tools Work in progress: • Quasi-static scheduling for multiple processors • Hardware synthesis from concurrent processes • Processor micro-architecture exploration • Communication architecture design (on-chip and off-chip) • Fault-tolerant design for safety-critical applications:functionality and architecture definition and mapping • Communication buffer memory sizing and allocation

  32. etropolis Summary Metropolis: • Interdisciplinary, intercontinental project (10 institutions in 5 countries) • Goal: • Design methodologies: abstraction levels, design problem formulations • Design automation tools: formal methods for automatic synthesis and verification, a modeling mechanism: heterogeneous semantics, concurrency • Primary thrusts: • Metropolis Meta Model: • Building blocks for modular descriptions of heterogeneous semantics • Modeling mechanism for function, architecture, and constraints • Design Methodology: • Multi-media digital systems • Wireless communication • Fault-tolerant automotive systems • Microprocessors • Formal Methods and design tools

  33. For more information… • Metropolis home page:http://www.gigascale.org/metropolis/ • Updated version of the slides:http://polimage.polito.it/~lavagno/metro_mpsoc_03.ppt • Additional (free ) advertising: open-source asynchronous implementation of DLX processor, ready for technology map, place and route:http://www.ics.forth.gr/carv/aspida

More Related