Modeling of Heterogeneous Systems in Metropolis

1. Modeling of Heterogeneous Systems in Metropolis Alberto Ferrari aferrari@parades.rm.cnr.it ARTISTII – Summer School Nässlingen, Sweden – 29th September, 2005

2. Outline • Motivation and Industrial Landscape • The Metropolis Framework • Architecture • The Semantics of the Metropolis Metamodel • A Design Example • Architecture Modeling in Metropolis • Conclusions

3. Automotive Supply Chain:Car Manufacturers • Product Specification & Architecture Definition(e.g., determination of Protocols and Communication) • System Partitioning and Subsystem Specification • Critical Software Development • System Integration

4. Technical Contents

5. GM SAC Vehicular Electronics, Controls and Software Study • Software content in automobiles could increase by 100 X over the next 5-6 years. Challenges will include: • Software system architecture • Partitioning for modularity & system reliability • Reuse • Standardization of interfaces

6. Real-Time and Distributed InformationSystems Mobile Communications Navigation Telematics Fail Stop Soft Real Time Access to WWW MOSTFirewire DAB FireWall Body Electronics Theft warning AirConditioning BodyFunctions CANLin Door Module Light Module Fail Safe Real Time GateWay System Electronics ABS CANTTCAN Shift by Wire EngineManagement Driving and VehicleDynamic Functions GateWay Fault Functional Hard Real Time Steer by Wire Brake by Wire FlexRay

7. Putting it all together….CHALLENGE and Opportunity! • We need an integration platform • To deal with heterogeneity: • Where we can deal with Hardware and Software (verification and synthesis) • Where we can mix digital and analog • Where we can assemble internal and external IPs • Where we can work at different levels of abstraction • To handle the design chain • To support integration • e.g. tool integration • e.g. IP integration • The integration platform must subsume the traditional design flow, rather than displacing it

8. Metropolis: an Environment for System-Level Design • Motivation • Design complexity and the need for verification and time-to-market constraints are increasing • Semantic link between specification and implementation is necessary • Platform-Based Design • Meet-in-the-middle approach • Separation of concerns • Function vs. architecture • Capability vs. performance • Computation vs. communication • Metropolis Framework • Extensible framework providing simulation, verification, and synthesis capabilities • Easily extract relevant design information and interface to external tools • Released Sept. 15th, 2004

9. Application Space Application Instance Platform Mapping System Platform (HW and SW) Platform Design-Space Export Platform Instance Architectural Space Platform based Design • Platform Based Design1 is composed of three aspects: • Top Down Application Development • Platform Mapping • Bottom Up Design Space Exploration • Orthogolization of concerns2 • Functionality and Architecture • Behavior and Performance Indices • Computation, Communication, and Coordination. • A. Ferrari and A. Sangiovanni-Vincentelli. System design: traditional concepts and new paradigms. In Proceedings 1999 IEEE ICCD: VLSI in Computers and Processors, Los Alamitos, CA, USA, October 1999. • A. Sangiovanni-Vincentelli, Defining Platform-based Design, EE Design, March 5, 2002. • F. Balarin, et al, Metropolis: an Integrated Electronic System Design Environment, IEEE Computer, Vol. 36, No. 4, April, 2003.

10. Metropolis Project Big Picture: Target and Goals • Target: Embedded System Design • Set-top boxes, cellular phones, automotive controllers, … • Heterogeneity: • computation: Analog, ASICs, programmable logic, DSPs, ASIPs, processors • communication: Buses, cross-bars, cache, DMAs, SDRAM, … • coordination: Synchronous, Asynchronous (event driven, time driven) • Goals: • Design methodologies: • abstraction levels: design capture, mathematics for the semantics • design tasks: cache size, address map, SW code generation, RTL generation, … • Tool set: • synthesis: data transfer scheduling, memory sizing, interface logic, SW/HW generation, … • verification: property checking, static analysis of performance, equivalence checking, …

11. Embedded System Design Problem • Heterogeneity and Concurrency (both at function and architecture platform level) • Design Exploration at early stages using models • Synthesis (correct by construction, push-button system deployment) • Multiple levels of abstraction to go from concept to implementation

12. Focusing on the Principles • Models of computation with formal semantics • Unambiguously capture specification • Enable verification and synthesis • Unified frameworks for composition of models • Orthogonalization of concerns • Function/Architecture • Computation/Communication • Formal methods for abstraction and refinement • Help in defining levels of abstractions • Link design steps (successive refinement) • Verification • Formal definition of mapping to cross levels of abstractions • Synthesis and compilation

13. Meta model language Meta model compiler Front end Abstract syntax trees ... Back end3 Back endN Back end1 Back end2 Synthesis tool Simulator tool Verification tool Verification tool Software Tools Solution • Metropolis Meta Modeling (MMM) language4 and compiler are the core components. • Backend tools provide various operations for manipulating designs and performing analysis.

14. Metropolis Project Participants: • UC Berkeley (USA): methodologies, modeling, formal methods • CMU (USA): formal methods • Politecnico di Torino (Italy): modeling, formal methods • Universita Politecnica de Catalunya (Spain): modeling, formal methods • Cadence Berkeley Labs (USA): methodologies, modeling, formal methods • PARADES (Italy): methodologies, modeling, formal methods • ST (France-Italy):methodologies, modeling • Philips (Netherlands): methodologies (multi-media) • Nokia (USA, Finland): methodologies (wireless communication) • BWRC (USA): methodologies (wireless communication) • Magneti-Marelli (Italy): methodologies (power train control) • BMW (USA): methodologies (fault-tolerant automotive controls) • Intel (USA): methodologies (microprocessors) • Cypress (USA): methodologies (network processors, USB platforms) • Honeywell (USA): methodologies (FADEC)

15. Metropolis Framework Function Specification Architecture (Platform) Specification Design Constraints & Assertions • Metropolis Infrastructure • Design methodology • Meta model of computation • Base tools • - Design imports • - Meta model compiler • - Simulation • Synthesis/Refinement • Compile-time scheduling of concurrency • Communication-driven hardware synthesis • Protocol interface generation • Analysis/Verification • Static timing analysis of reactive systems • Invariant analysis of sequential programs • Refinement verification • Formal verification of embedded software

16. Meta Frameworks: Metropolis Tagged Signal Semantics Process Networks Semantics Firing Semantics dataflow Metropolis provides a process networks abstract semantics and emphasizes formal description of constraints, communication refinement, and joint modeling of applications and architectures. Stateful Firing Semantics Kahn processnetworks discreteevents synchronous/reactive hybrid systems continuoustime

17. Proc1 P1 P2 Media1 I1 I2 Metropolis Objects (partial) • 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

18. A Producer–Consumer Example • A process P producing integers • A process C consuming integers • A media M implementing the communication services Media M  Proc P Proc C

19. Writer: Process P (Producer) • Writer.mmm: Port (interface) definition • P.mmm: Process behavior definition package producers_consumer; interface IntWriter extends Port{ update void writeInt(int i); eval int nspace(); } package producers_consumer; process P { port IntWriter port_wr; public P(String name) {} void thread() { int w = 0; while (w < 30) { port_wr.writeInt(w); w = w + 1; } }} Proc P

20. Reader: Process C (Consumer) • Reader.mmm: Port (Interface) definition • C.mmm: Process behavior definition package producers_consumer; interface IntReader extends Port{ update int readInt(); eval int num(); } Proc C package producers_consumer; process C { port IntReader port_rd; public C(String name) { }; void thread() { int r = 0; while (r < 30) { port_rd.readInt(); } }}

21. Media M: Writer services Media M  • Communication definition package producers_consumer; medium IntM implements IntReader, IntWriter, Semaphore { int_infinite_queue storage; public IntM(String name) { } public update void writeInt(int w) { await( true; this.Semaphore; this.Semaphore) { storage.write(w); } } public update int readInt() { int _retval = 0; await( storage.getN()>0; this.Semaphore; this.Semaphore){ _retval = storage.read(); } return _retval; } }

22. Media M  Proc C Proc P3 Example: producers-consumers • A set of processes “Writer” write data to a FIFO • A set of processes “Reader” read data from a FIFO • An unbounded FIFO is used to store written data and to retrieve read data Proc P1 Proc P2

23. Proc P1 Media M  Proc P2 Proc C Proc P3 Top level netlist package producers_consumer; public netlist IwIr { IntM m; public IwIr(String name) { m = new IntM("InstIntM"); addcomponent(m, this, "MEDIUM"); for (int i = 0; i < 3; i++) { P p = new P("Producer"+i); addcomponent(p, this, "Producer"+i); connect(p, port_wr, m); } for (int i = 0; i < 1; i++) { C c = new C("Consumer"+i); addcomponent(c, this, "Consumer"+i); connect(c, port_rd, m); } } }

24. Protecting against concurrency • If more than one process is calling the services, the services can be executed concurrently, hence the state of the media must be protected by concurrent access • The protection is guaranteed by the await statement Metropolis supports Concurrency and Coordination

25. Media M: await Media M  • Communication definition public update void writeInt(int w) { await { (true; this.Semaphore; this.Semaphore){ storage.write(w); } } public update int readInt() { int _retval = 0; await( storage.getN()>0; this.Semaphore; this.Semaphore){ _retval = storage.read(); } return _retval; } }

26. AWAIT • The await statement is used to describe a situation that a process object waits for a given condition to become true, and once the condition holds, it continues its execution with the guarantee that the condition still holds await { ( guard, testlist, setlist) statements; }

27. AWAIT • guard is an expression to be evaluated as true or false • testlist is a list of elements, where each element is an interface. Represents the sections to test • setlist is a list of elements, where each element is an interface. Represents the section to set The await is enabled if its guard is true and no actions in testlist are currently being executed. During the execution no action in setlist can start

28. Proc1 P1 P2 Media1 I1 I2 QM1 Metropolis Objects: adding quantity managers • 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

29. Media M  Proc C Proc P Producer-Consumer Example: Imperative await … write(d); … … d = read( ); … … await(…;…;…){ …}; …

30. Media M  Proc C Proc P Producer-Consumer Example: Declarative (Given an event e, t.e is its tag) beg(w) beg(r) … write(d); … … d = read( ); … end(r) end(w) Constraints: t.beg(w) < t.end(w) t.beg(r) < t.end(r) t.beg(w) < t.beg(r) (in case of simultaneous access) does not exist t such that t.end(w) > t > t.beg(w) (write atomicity) does not exist t such that t.end(r) > t > t.beg(r) (read atomicity)

31. 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 scheduling 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 real-time constraints, e.g. “any successive actions of starting a statement s1 by process P must take place with at most 10ms interval.” B(P1, P1.s1) < B( P2, P2.run); B(P1, P1.s1) <E(P2, P2.run); B(P1, P1.s2) < B( P2, P2.run); B(P1, P1.s2) <E(P2, P2.run);

32. Logic of Constraints • A transaction-level quantitative constraint language (e.g. latency, throughput) • LOC formulas: Boolean expressions over atomic formulas, i.e. combination of terms using relational operators • LOC terms: • Constants • Integer variable i (the ONLY index variable) • Expressions of the form a(e[n]) where • n∈I: index expression, e.g. [2], [i+3] • Index variable i, the only variable in a formula, e.g. “Display[i-5]” and “Stimuli[i]” • e: event name, e.g. “in”, “out”, “Stimuli” or “Display”  e[n]: instances of events, e.g. “in[2]”, “Stimuli[0]”, “Display[10]” • a: annotation, e.g. “t(Display[5])” • Combination of the terms above using arithmetic operators • Boolean operators: (not), (or), (and) and (imply) • Interpreted over a sequence of events in an execution trace • Violated if it evaluates to FALSE for some value of i

33. Stimuli : 0 at time 9Display : 0 at time 13Stimuli : 1 at time 19Display : -6 at time 23Stimuli : 2 at time 29Display : -16 at time 33Stimuli : 3 at time 39Display : -13 at time 43 Stimuli : 4 at time 49Display : 6 at time 53 FIR FSM Stimuli Display Datapath ( SystemC2.0 Distribution ) FIR Trace Examples of LOC Constraints Throughput: “at least 3 Display events will be produced in any period of 30 time units”. t (Display[i+3]) – t (Display[i]) <= 30

34. Examples LOC Constraints (cont’d) Performance constraints: Rate, e.g. “Display’s are produced every 10 time units”, t(Display[i+1]) - t(Display[i]) == 10 Latency, e.g. “Display is generated no more than 25 time units after Stimuli”, t(Display[i]) - t(Stimuli[i]) <= 25 Jitter, e.g. “every Display is no more than 4 time units away from the corresponding tick of the real-time clock with period 10”, | t(Display[i]) - (i+1) * 10 | <= 4 Functional Constraints: Data consistency, e.g. data(input[i]) = data(output[i])

35. Examples LOC Constraints (cont’d) Latency, e.g. “Display is generated no more than 25 time units after Stimuli”, t(Display[i]) - t(Stimuli[i]) <= 25 What if not every stimulus is displayed? t(Display[i]) - t(Stimuli[cause(Display[i])) <= 25

36. Some Remarks on LOC Formulas • Time is only one of the possible annotations • cause(Display[i]), data(input[i]), power(…), area(…), etc. • Annotations must be provided by the designer, the program, the simulator, the underlying platform • Annotations need not be defined • e.g. performance requirements are specified early in the design process but can be evaluated much later • A third logic value undef is introduced to deal with undefined annotations • Indexes of instance of the same event denote their strict order in the execution trace • Instances of different events have no implied relationship

37. Media M  Proc C Proc P QM Producer-Consumer Example: Imperative with QM … Lw: {@ write(d) {$ //request code $} @} … Lr: {@ d = read() {$ //request code $} @} Scheduled Netlist Quantity Manager (Scheduler) Scheduling Netlist

38. Media M  Proc C Proc P QM Producer-Consumer Example: Semantic (intuitive) //Statemedium request function void request(e,rc) { to_qm.request(e,rc); } Scheduled Netlist request(e,rc) Quantity Manager (Scheduler) Scheduling Netlist

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

40. Media M  Proc C Proc P QM Producer-Consumer Example: Semantic (intuitive) //QM request function void request(e,rc) { pending.add(new r(e,rc)); } Scheduled Netlist request(e,rc) Quantity Manager (Scheduler) Scheduling Netlist

41. Media M  Proc C Proc P QM Producer-Consumer Example: Semantic (intuitive) //Top level resolve function is //invoked void resolve() { qm.resolve( ); } Scheduled Netlist Quantity Manager (Scheduler) Scheduling Netlist

42. Media M  Proc C Proc P QM Producer-Consumer Example: Semantic (intuitive) //QM resolve function void resolve() { //pick one event per process } Scheduled Netlist Quantity Manager (Scheduler) Scheduling Netlist

43. Media M  Proc C Proc P QM Producer-Consumer Example: Semantic (intuitive) //Top level postcond void postcond() { qm.postcond( ); } Scheduled Netlist Quantity Manager (Scheduler) Scheduling Netlist

44. Media M  Proc C Proc P QM Producer-Consumer Example: Semantic (intuitive) //QM postcond void postcond() { //enable/disable events on processes } Scheduled Netlist setMustDo(e) Quantity Manager (Scheduler) Scheduling Netlist

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

46. Media M  Proc C Proc P Producer-Consumer Example … write(d); … … d = read( ); … … await(…;…;…){ …}; … Metropolis supports Imperative Coordination (await or QM request) Metropolis supports Declarative Coordination (Constraints on Quantities)

47. QM1 Metropolis Netlists and Events • 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

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

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

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