Metropolis Metamodel

1. Metropolis Metamodel

2. Metropolis Objects Proc1 P1 P2 Media1 I1 I2 QM1 • Metropolis elements adhere to a “separation of concerns” point of view. • Processes (Computation) Active Objects Sequential Executing Thread • Media (Communication) Passive Objects Implement Interface Services • Quantity Managers (Coordination) Schedule access to resources and quantities

3. Metro. Netlists and Events QM1 Problem Statement Approach Contribution • Metropolis Architectures are created via two netlists: • Scheduled – generate events1 for services in the scheduled netlist. • Scheduling – allow these events access to the services and annotateevents with quantities. Related Work Scheduled Netlist Scheduling Netlist Event1 – represents a transition in the action automata of an object. Can be annotated with any number of quantities. This allows performance estimation. Proc1 Proc2 P1 P2 Global Time I1 Media1 I2 • E. Lee and A. Sangiovanni-Vincentelli, A Unified Framework for Comparing Models of Computation, IEEE Trans. on Computer Aided Design of Integrated Circuits and Systems, Vol. 17, N. 12, pg. 1217-1229, December 1998

4. Key Modeling Concepts • An event is the fundamental concept in the framework • Represents a transition in the action automataof an object • An event is owned by the object that exports it • During simulation, generated events are termed as event instances • Events can be annotated with any number of quantities • Events can partially expose the state around them, constraints can then reference or influence this state • A service corresponds to a set of sequences of events • All elements in the set have a common begin event and a common end event • A service may be parameterized with arguments • E. Lee and A. Sangiovanni-Vincentelli, A Unified Framework for Comparing Models of Computation, • IEEE Trans. on Computer Aided Design of Integrated Circuits and Systems, Vol. 17, N. 12, pg. 1217-1229, December 1998

5. Action Automata • Processes take actions. • statements and some expressions, e.g. y = z+port.f();, z+port.f(), port.f(), i < 10, … • only calls to media functions are observable actions • An execution of a given netlist is a sequence of vectors of events. • event : the beginning of an action, e.g. B(port.f()), the end of an action, e.g. E(port.f()), or null N • the i-th component of a vector is an event of the i-th process • An execution is legal if • it satisfies all coordination constraints, and • it is accepted by all action automata.

6. Execution semantics Action automaton: • one for each action of each process • defines the set of sequences of events that can happen in executing the action • a transition corresponds to an event: • it may update shared memory variables: • process and media member variables • values of actions-expressions • it may have guards that depend on states of other action automata and memory variables • each state has a self-loop transition with the null N event. • all the automata have their alphabets in common: • transitions must be taken together in different automata, if they correspond to the same event.

7. Action Automata • y=x+1; y=x+1 x+1 B y=x+1 B x+1 E x+1 E y=x+1 y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 y:=any B x+1 E x+1 Vx+1 :=x+1 writex E x+1 Vx+1 :=any Vx+1 y x 0 0 0 5 0 0 1 0 0 5 5 0 1 1 0 B y=x+1 N B x+1 N N E x+1 E y=x+1 Return

8. Semantics summary • Processes run sequential code concurrently, each at its own arbitrary pace. • Read-Write and Write-Write hazards may cause unpredictable results • atomicity has to be explicitly specified. • Progress may block at synchronization points • awaits • function calls and labels to which awaits or constraints refer. • The legal behavior of a netlist is given by a set of sequences of event vectors. • multiple sequences reflect the non-determinism of the semantics: concurrency, synchronization (awaits and constraints)

9. Metropolis Architecture Representation

10. Architecture components • An architecture component specifies services, i.e. • what it can do • how much it costs

11. Meta-Model : Functional Netlist MyFncNetlist P1 Y X M P2 Y X Env2 Env1 process P{ port reader X; port writer Y; thread(){ while(true){ ... z = f(X.read()); Y.write(z); }}} interface reader extends Port{ update int read(); eval int n(); } interface writer extends Port{ update void write(int i); eval int space(); } medium M implements reader, writer{ int storage; int n, space; void write(int z){ await(space>0; this.writer ; this.writer) n=1; space=0; storage=z; } word read(){ ... } }

12. Meta-Model: Architecture Components interface BusArbiterService extends Port { update void request(event e); update void resolve(); } interface BusMasterService extends Port { update void busRead(String dest, int size); update void busWrite(String dest, int size); } medium Bus implements BusMasterService…{ port BusArbiterService Arb; port MemService Mem; … update void busRead(String dest, int size) { if(dest== … ) Mem.memRead(size); [[Arb.request(B(thisthread, this.busRead)); GTime.request(B(thisthread, this.memRead), BUSCLKCYCLE + GTime.A(B(thisthread, this.busRead))); ]] } … scheduler BusArbiter extends Quantity implements BusArbiterService { update void request(event e){ … } update void resolve() { //schedule } } Bus BusArbiter • An architecture component specifies services, i.e. • what it can do • how much it costs : interfaces : quantities, annotation, logic of constraints

13. Meta-model: quantities • The domain D of the quantity, e.g. real for the global time, • The operations and relations on D, e.g. subtraction, <, =, • The function from an event instance to an element of D, • Axioms on the quantity, e.g. • the global time is non-decreasing in a sequence of vectors of any • feasible execution. class GTime extends Quantity { double t; double sub(double t2, double t1){...} double add(double t1, double t2){…} boolean equal(double t1, double t2){ ... } boolean less(double t1, double t2){ ... } double A(event e, int i){ ... } constraints{ forall(event e1, event e2, int i, int j): GXI.A(e1, i) == GXI.A(e2, j) -> equal(A(e1, i), A(e2, j)) && GXI.A(e1, i) < GXI.A(e2, j) -> (less(A(e1, i), A(e2, j)) || equal(A(e1, i), A(e2. j))); }}

14. Meta-model: architecture components • This modeling mechanism is generic, independent of services and cost specified. • Which levels of abstraction, what kind of quantities, what kind of cost constraints should be used to capture architecture components? • depends on applications: on-going research Transaction: Services: - fuzzy instruction set for SW, execute() for HW - bounded FIFO (point-to-point) Quantities: - #reads, #writes, token size, context switches CPU ASIC1 ASIC2 Sw1 Hw Sw2 Hw C-Ctl C-Ctl Sw I/F Channel Ctl Channel I/F B-I/F CPU-IOs Bus I/F Wrappers Virtual BUS: Services: - data decomposition/composition - address (internal v.s. external) Quantities: same as above, different weights Physical: Services: full characterization Quantities: time RTOS e.g. PIBus 32b e.g. OtherBus 64b...

15. Quantity resolution The 2-step approach to resolve quantities at each state of a netlist being executed: 1. quantity requests for each process Pi, for each event e that Pican take, find all the quantity constraints on e. In the meta-model, this is done by explicitly requesting quantity annotations at the relevant events, i.e. Quantity.request(event, requested quantities). 2. quantity resolution find a vector made of the candidate events and a set of quantities annotated with each of the events, such that the annotated quantities satisfy: • all the quantity requests, and • all the axioms of the Quantity types. In the meta-model, this is done by letting each Quantity type implement a resolve() method, and the methods of relevant Quantity types are iteratively called. • theory of fixed-point computation

16. Quantity resolution • The 2-step approach is same as how schedulers work, e.g. OS schedulers, BUS schedulers, BUS bridge controllers. • Semantically, a scheduler can be considered as one that resolves a quantity called execution index. • Two ways to model schedulers: 1. As processes: • explicitly model the scheduling protocols using the meta-model building blocks • a good reflection of actual implementations 2. As quantities: • use the built-in request/resolve approach for modeling the scheduling protocols • more focus on resolution (scheduling) algorithms, than protocols: suitable for higher level abstraction models

17. Quantity Request – Service • Task.Read(){ • CpuRtos.cpuRead(); • } • CS.Resolve(){ • //Task scheduling algorithm; • } Ti setMustDo(e) CpuRtos.cpuRead() CS.Resolve() CpuScheduler GTime CpuRtos CS.Request(beg(Ti, this.cpuRead),csr) Bus.busRead() • CpuRtos.Read(){ • CS.Request(beg(Ti, this.cpuRead), csr); • Bus.busRead(); • CS.Request(end(Ti, this.cpuRead), csr); • } SchedulingNetlist ScheduledNetlist

18. Meta-Model: Mapping Netlist MyFncNetlist P1 P2 M Env2 Env1 MyArchNetlist … MyArchNetlist … mP1 mP1 mP2 mP2 … Bus Arbiter Bus Arbiter Bus Bus Mem Mem Cpu Cpu OsSched OsSched 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);

19. Architecture Modeling Related Work • David C. Luckham and James Vera, An Event-Based Architecture Definition Language , IEEE Transactions on Software Engineering, Vol. 21, No 9, pg. 717-734, Sep. 1995. • Ingo Sander and Axel Jantsch, System Modeling and Transformational Design Refinement in ForSyDe, IEEE Transactions on CAD, Vol. 23, No 1, pg. 17-32, Jan. 2004. • Paul Lieverse, Pieter van der Wolf, Ed Deprettere, and Kees Vissers, A Methodology for Architecture Exploration of Heterogeneous Signal Processing Systems, IEEE Workshop in Signal Processing Systems, Taipei, Taiwan, 1999. Return

20. Naïve Approach System Level Design does not guarantee accuracy or efficiency!! Estimated Performance Data Abstract Modular SLD Manual “C” Model Disconnected Inaccurate! Lengthy Feedback Inefficient Miss Time to Market! Manual RTL “Golden Model” Implementation Implementation Gap!

21. Improved Approach Functional level blocks of programmable components Technique 1: Modeling style and characterization for programmable platforms Estimated Performance Data Real Performance Data Abstract Modular SLD From characterization flow Narrow the Gap Actual Programmable Platform Description New approach has improved accuracy and efficiency by relating programmable devices and their tool flow with SLD (Metropolis). Retains modularity and abstraction.

22. Programmable Focus P. Schaumont, et al, A Quick Safari Through the Reconfigurable Jungle, DAC, June 2001. K. Bondalapati, V. Prasanna, Reconfigurable Computing Systems, USC

23. Programmable Arch. Modeling • Computation Services • Communication Services • Other Services PPC405 MicroBlaze SynthMaster SynthSlave Computation Services Read (addr, offset, cnt, size), Write(addr, offset, cnt, size), Execute (operation, complexity) Processor Local Bus (PLB) On-Chip Peripheral Bus (OPB) Communication Services addrTransfer(target, master) addrReq(base, offset, transType, device) addrAck(device) dataTransfer(device, readSeq, writeSeq) dataAck(device) BRAM Mapping Process OPB/PLB Bridge Task Before Mapping Read (addr, offset, cnt, size) Task After Mapping Read (0x34, 8, 10, 4)

24. Programmable Arch. Modeling • Coordination Services PPC Sched MicroBlaze Sched PLB Sched OPB Sched BRAM Sched General Sched • PostCond() • Augment event with information • (annotation). This is typically the • interaction with the quantity manager • Request (event e) • Adds event to pending • queue of requested events • Resolve() • Uses algorithm to select an • event from the pending queue GTime

25. Programmable Arch. Modeling Structure Extractor • Compose scheduling and scheduled netlists in top level netlist. • Extract structure for programmable platform tool flow. Top Level Netlist public netlist XilinxCCArch { XilinxCCArchSched schedNetlist; XilinxCCArchScheduling schedulingNetlist; SchedToQuantity[] _stateMedia; } Mapping Process File for Programmable Platform Tool Flow MicroBlaze Sched MicroBlaze OPB OPB Sched • Type • Parameters • Etc Connections Scheduled Netlist Scheduling Netlist Topology ModularModeling Style Accurate & Efficient

26. Prog. Platform Characterization Need to tie the model to actual implementation data! 1. Create template system description. 2. Generate many permutations of the architecture using this template and run them through programmable platform tool flow. 3. Extract the desired performance information from the tool reports for database population.

27. Prog. Platform Characterization Create database ONCE prior to simulation and populate with independent (modular) information. 1. Data detailing performance based on physical implementation. 2. Data detailing the composition of communication transactions. 3. Data detailing the processing elements computation. From Char Flow Shown From Metro Model Design From ISS for PPC Work with Xilinx Research Labs • Douglas Densmore, Adam Donlin, A.Sangiovanni-Vincentelli, FPGA Architecture Characterization in System Level Design, Submitted to CODES 2005. • Adam Donlin and Douglas Densmore,Method and Apparatus for Precharacterizing Systems for Use in System Level Design of Integrated Circuits, Patent Pending.

28. Architecture Extensions for Mapping • Programmable platforms allow for both SW and HW implementations of a function. • Need to express which architecture components can provide which services and with what affinity. Dedicated HW DCT General Purpose uProc Mapping Process Mapping Process Potential Mapping Strategies Greedy Best Average Task Specific

29. Architecture Extensions for Preemption • Some Services are naturally preempted • CPU context switch, Bus transactions • Notion of Atomic Transactions • Prior to dispatching events to a quantity manager via the request() method, decompose events in the scheduled netlist into non-preemptable chunks. • Maintain status with an FSM object (counter) and controller. Event Size 3 Decoder 1 1 1 Initial State S1 S2 S3

30. Modeling & Char. Review Scheduling Netlist Task1 Task2 Task3 Task4 DEDICATED HW DedHW Sched PPC PPC Sched Global Time PLB PLB Sched BRAM Sched BRAM Scheduled Netlist Characterizer Media (scheduled) Process Enabled Event Quantity Quantity Manager Disabled Event

31. Arch. Refinement Verification Architectures often involve hierarchy and multiple abstraction levels. These techniques are limited if it is not possible to check if elements in hierarchy or less abstract components are implementations of their counterparts. Asks “Can I substitute M1 for M2?” Representing the internal structure of a component. Recasting an architectural description in a new style. Applying tools developed for one style to another style. D. Garlan, Style-Based Refinement for Software Architectures, SIGSOFT 96, San Francisco, CA, pg. 72-75.

32. Metropolis Refinement • Internal Refinement • Depth Refinement1 • Interface Based • Focus on introducing new behaviors (Reason 1) • Structural Refinement • Vertical Refinement1 • Horizontal Refinement1 • Event Based • Refinement Properties • Focus on abstraction & synthesis (Reasons 2 & 3) • Douglas Densmore, Metropolis Architecture Refinement Styles and Methodology, University of California, Berkeley, UCB/ERL M04/36, 14 September 2004.

33. Depth Refinement This Observable Behavior can be captured for Metropolis processes in the model via the creation of a control flow graph (CFG)1. Trace containment check for single threaded processes Work with Cypress Semiconductor • Douglas Densmore, Sanjay Rekhi, A. Sangiovanni-Vincentelli, MicroArchitecture Development via Successive Platform Refinement, Design Automation and Test Europe (DATE), Paris France, 2004.

34. Vertical Refinement Mapping Process Rtos PPC405 Cache PLB BRAM Rtos Sched Mapping Process • Definition: A manipulation to the scheduled netlist structure to introduce/remove the number or origin of events as seen by the scheduling netlist. Cache Sched Sequential New origins and amounts of events scheduled and annotated PPC Sched PLB Sched Concurrent BRAM Sched Scheduling Netlist Scheduled Netlist

35. Horizontal Refinement Mapping Process Control Thread Rtos PPC405 Arb Cache PLB BRAM Rtos Sched Mapping Process PPC Sched • Definition: A manipulation of both the scheduled and scheduling netlist which changes the possible ordering of events as seen by the scheduling netlist. PPC405 Cache Sched Ordering of event requests changed PPC Sched PLB Sched BRAM Sched Scheduling Netlist Scheduled Netlist *Contains all possible orderings if abstract enough

36. Refinement Properties Properties expressed as event sequences as seen by the scheduling netlist. E1 (CPUExe) E2 (CPUExe) E3 (CPUExe) E4(CPURead) Resource Utilization Latency

37. Example Design JPEG Encoder Function Model (Block Level) Structure Extractor Preprocessing DCT Mapping Process Quantization Huffman Mapping Process Mapping Process Mapping Process MicroBlaze SynthMaster On-Chip Peripheral Bus (OPB) SynthSlave BRAM BRAM 3. Assemble an architecture from library services or create your own services. • Select an application and understand its behavior. Top Level Netlist 5. Extract a structural file from the top level netlist of the architecture created. 2. Create a Metropolis functional model which models this behavior. 4. Map the functionality to the architecture. File for Xilinx EDK Tool Flow IP Library

38. Example Design Cont. Permutation 1 Permutation 2 Permutation N Platform Characterization Tool (Xilinx EDK/ISE Tools) Manual Software Routines int DCT (data){ Begin calculate … … } Hardware Routines DCT1 = 10 Cycles DCT2 =5 Cycles FFT = 5 Cycles Automatic Manual 32 Bit Read = Ack, Addr, Data, Trans, Ack Problem Statement Approach Contribution 1. Feed the captured structural file to the permutation generator. File for Xilinx EDK Tool Flow 2. Feed the permutations to the Xilinx tools and extract the data. 3. Capture execution info for software and hardware services. 4. Provide transaction info for communication services. Permutation Generator ISS Info Char Data Transaction Info Characterizer Database

39. Example Design Cont. JPEG Encoder Function Model (Block Level) Execution time 100ms Bus Cycles 4000 Ave Memory Occupancy 500KB Preprocessing DCT Mapping Process Quantization Huffman Mapping Process Mapping Process Mapping Process MicroBlaze On-Chip Peripheral Bus (OPB) BRAM Concurrent Vertical Refinement 4. Re-simulate to see if your goals are met. Verification Tool Execution time 200ms Bus Cycles 1000 Ave Memory Occupancy 100KB BRAM BRAM Yes? No? • Backend Tool Process: • Abstract Syntax Tree (AST) retrieves • structure. • 2. Control Data Flow Graph - Depth • FORTE – Intel Tool • Reactive Models – UC Berkeley • 3. Event Traces – Refinement • Properties. • Vertical Refinement • Horizontal Refinement 1. Simulate the design and observe the performance. SynthMaster 2. Refine design to meet performance requirements. New Algorithm SynthSlave • 3. Use Refinement Verification to check validity of design changes. • Depth, Vertical, or Horizontal • Refinement properties Depth ISS Info Char Data Transaction Info

40. Goals for Metro II Import heterogeneous IP Different languages Different models of computation Key Platform-based Design Activities Behavior-Performance Separation Quickly change performance characteristics of models Design Space Exploration Relate functionality and architecture Verify relationships between different abstraction levels Coordination Framework 3-Phase Execution Event-oriented Framework 40

41. Components, Ports, and Connections required port Component provided port Wrapper view port IP • Ports • Coordination: provided, required • View ports • Connections • Each method in interface for provided-required connection associated with begin and end events • IP is wrapped to expose framework-compatible interface • Components encapsulate wrapped IP

42. Mappers • Mappers are objects that help specify the mapping • Bridge syntactic gaps only • E.g. Missing method parameters • Mapping occurs at the component level • Between components with compatible interfaces • Possibly many functional components mapped to a single architectural component Func. Comp Arch. Comp Mapper

43. Adaptor Events ? Events Component1 (MOC1) Component2 (MOC2) Adaptor How to communicate with different MoC? • Adaptor transforms the tags of the events to make different MoCs compatible • Values are not changed • Will not produce/discard events 43 Bridge different models of computation (MoCs)

44. Implementation of Adaptor 44 Adaptor contains internal channels for storing the information of events, and a process to transforms the tags of events Adaptor will be executed during the base model execution phase (phase 1) Test case with an adaptor between dataflow and FSM semantics Will be further tested in the cruise control and heating and cooling project

45. Metro II System Architecture Status m2_manager Mapper Adaptor Annotator Scheduler m2_port m2_interface m2_component m2_method Constraints m2_event Metro II Core sc_module sc_event Implementation Platform: SystemC 2.2 Implementation started 45

46. Behavior-Performance Separation in Metropolis 3. Granting of requests Phase 1 Phase 2 Global Time P2 P1 Resource Scheduler 2. Quantity Resolution R 1. Explicit quantity requests • Processes make explicit requests for annotation • Annotation/scheduling are intertwined • Iteration between multiple quantity managers • Challenges in GM case study • Vehicle stability application on distributed CAN architecture • Interactions between global time QM and resource QM difficult to debug

47. Execution Semantics in Metro II Not Blocked Blocked • Metro II components (imperative code) are run by processes (sequential thread of execution). start Propose Event or Wait Event Enabled or Notified Metro II Process States 47

48. Execution Semantics in Metro II start Phase 3 Phase 1 Phase 2 Logical Time P2 P1 Physical Time 3. Sched. Resolution Annotated Inactive Proposed R Resource Scheduler 1. Block processes at interfaces Event proposed by Process Event enabled by CS then processcontinues execution Event Disabled by CS must be reannotated 4. Enable some processes Event Annotated 2. Annotations Event Disabled by CS, but keep the same annotations 48

49. Phases and Events • Each phase is allowed to interact with events in a limited way • Keep responsibilities separate

50. Assumptions • “Blocking” • Both the architectural and functional models should be allowed to block • Scheduling • Functional model execution is valid (i.e. doesn’t deadlock) • Mapping • The enabling of events in one model, correspond directly to the enabling of other events 50