1 / 32

Processes, interfaces and platforms. Embedded software modeling in Metropolis.

Processes, interfaces and platforms. Embedded software modeling in Metropolis. Luciano Lavagno Politecnico di Torino EMSOFT 2002, CASES 2002 Grenoble, France. etropolis. Metropolis Project: main participants. Cadence Berkeley Labs (USA): methodologies , modeling , formal methods

tammy
Download Presentation

Processes, interfaces and platforms. Embedded software modeling in Metropolis.

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. Processes, interfaces and platforms.Embedded software modeling in Metropolis. Luciano Lavagno Politecnico di Torino EMSOFT 2002, CASES 2002 Grenoble, France

  2. etropolis Metropolis Project: main 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 • Philips Research (Netherlands): methodologies (multi-media) • Nokia (USA, Finland): methodologies (wireless communication) • BWRC (USA): methodologies (wireless communication) • BMW (USA): methodologies (fault-tolerant automotive controls) • Intel (USA): methodologies (microprocessors) • STMicroelectronics (France, Italy): methodologies (wireless platforms)

  3. Application-specific methodologies Multi-media, wireless communication, mechanical controls, processors • Meta-model Library • Models of computation • Meta-model Library • Architecture platforms Tools … Simulator STARS PIG SPIN QSS Metropolis Framework • Infrastructure • Metropolis meta-model • - language • - modeling mechanisms • Meta-model compiler

  4. Control API RTOS driver MPEGdecode CPU INT UART Map demux PESparser ImageJuggler I$ D$ MPEGdecode HSRC VSRC BCU Functional & Non-func. Constraints HW assist Architecture Component Library System Architecture Model MEM Refine Optimize Implementation of System Function Component Library System Function Model MPEGdecode PESparser VSRC UART RTOS CPU I$ D$ Design Methodology Balance between reusability and optimality • orthogonalize design concerns as much as possible • optimize the final implementation as much as necessary

  5. Concurrent specification with a formal execution semantics: Key difference with respect to Ptolemy, UML, SystemC, …!!! Metropolis meta-model Concurrent specification with a formal execution semantics: • Computation : f : X  Z • Communication : state evaluation and manipulation • Coordination : constraints over concurrent actions - process : generates a sequence of events - medium : defines states and methods - quantity: annotation of each event (time, energy, memory, …) - logic : relates events and quantities, defines axioms on quantities - quantity-manager : algorithm to realize annotation subject to relational constraints

  6. MyFncNetlist P1 Y X M P2 Y X Env2 Env1 F A M I R Meta-model : function netlist 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; writer ; writer) n=1; space=0; storage=z; } word read(){ ... } }

  7. Meta-model: execution semantics • Processes take actions. • statements and some expressions, e.g. y = z+port.f(), port.f(), i < 10, … • 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()), null (no-op) N • the i-th component of a vector is an event of the i-th process • synchronous trace-based semantics • time and other quantities elapse and actions are executed in states • no assumption on atomicity whatsoever (unless explicitly modeled) • An execution is feasible if • it satisfies all coordination constraints, and • it is accepted by all action automata defining meta-model semantics

  8. 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(busRead)); GTime.request(B(memRead), BUSCLKCYCLE + GTime.annotation(B(busRead))); ]] } … F A scheduler BusArbiter extends Quantity implements BusArbiterService { update void request(event e){ … } update void resolve() { //schedule } } M I R Bus BusArbiter Meta-model: architecture components • An architecture component specifies services, i.e. • what it can do • how much it costs : interfaces : quantities, annotation, logic of constraints

  9. MyArchNetlist … … F A … M Bus Arbiter I Bus R CPU + OS Arbiter Mem Mem Cpu OsSched Master Slave Meta-model: architecture netlist Architecture netlist specifies configurations of architecture components. Each constructor - instantiates arch. components, - connects them, - takes as input mapping processes.

  10. F A thread(){ while(true){ await { (true; ; ;) readCpu(); (true; ; ;) mapf(); (true; ; ;) readWrite(); }}} M I R 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(2); Cpu.cpuRead(); } void mapf(){Cpu.exec(12*n); } … } process P{ port reader X; port writer Y; thread(){ while(true){ ... z = f(X.read()); Y.write(z); }} int f (int n) { int i; for (i = 0; i < n; i++) { … }}

  11. MyFncNetlist P1 P2 M Env2 Env1 MyArchNetlist … MyArchNetlist F A … M mP1 mP1 mP2 mP2 … Bus Arbiter Bus Arbiter I Bus Bus R 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);

  12. medium AbsM implements MyService{ int myService(int d) { … } } refine(AbsM, MyMapNetlist2) B(…) <=> B(…); E(…) <=> E(…); B(thisthread, AbsM.myService) <=> B(P1, M.read); E(thisthread, AbsM.myService) <=> E(P2, M.write); refine(AbsM, MyMapNetlist); refine(AbsM, MyMapNetlist1) B(…) <=> B(…); E(…) <=> E(…); MyMapNetlist2 MyMapNetlist1 F F A A 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); 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 I I P1 P2 P1 P2 MyFncNetlist MyArchNetlist MyFncNetlist MyArchNetlist M M R R MyMapNetlist1 M 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); P1 P2 MyFncNetlist MyArchNetlist M Meta-model: platforms A set of mapping netlists, together with constraints on event mappings, constitutes a platform (constrained set of possible implementations) with a given interface. interface MyService extends Port { int myService(int d); }

  13. 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 RTOSNetlist 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 RTOS

  14. Meta-model: summary • Concurrent specification with a formal execution semantics • Feasible executions of a netlist: sequences of event vectors • Quantities can be defined and annotated with events, e.g. • time, energy, memory, ... • Concurrent events can be coordinated in terms of quantities: • - logic can be used to define the coordination, • - algorithms can be used to implement the coordination. • The mechanism of event coordination wrt quantities plays a key role: • - architecture modeling as service with cost, • - mapping coordinates executions of functional and architecture netlists, • - refinement with event coordination provides a platform.

  15. Application-specific methodologies Multi-media, wireless communication, mechanical controls, processors • Meta-model Library • Models of computation • Meta-model Library • Architecture platforms Tools … Simulator STARS PIG SPIN QSS Metropolis Framework • Infrastructure • Metropolis meta-model • - language • - modeling mechanisms • Meta-model compiler

  16. Meta model language Languagen Language2 Language1 Abstract syntax trees Verification tool Simulator tool Verification tool Synthesis tool Metropolis infrastructure architecture Translator1 Translator2 ... Translatorn Meta model compiler Front end ... Back end3 Back endN Back end1 Back end2

  17. Meta model language UML Esterel/Lustre Simulink Abstract syntax trees Symbolic HW scheduler SystemC Simulator Spin Prometheus Metropolis infrastructure status Translator1 Translator2 ... Translatorn Meta model compiler Front end ... Back end3 Back endN Back end1 Back end2

  18. Deriving other formal models from the meta-model reader_unlock Example: Petri nets 2 X.n() reader_lock 2 await(X.n()>=2; X.reader; X.reader) for(i=0; i<2; i++) x[i]=X.read(); i=0; i<2? • Restrictions: • condition inside await is conjunctive • specific medium type (FIFO) is used x[i]=X.read(); i++; • Formal methods on Petri nets: • analyze the schedulability • analyze upper bounds of storage sizes • synthesize schedules end of await

  19. Example: quasi-static scheduling • Specify a network of processes • Translate to the Petri net model • Find a “schedule” on the Petri net • Translate the schedule to a set of tasks (processes)

  20. Metropolis Summary • Metropolis meta-model: • - concurrent specification for functions, architecture, and mappings • - libraries of models of computation, libraries of platforms • Metropolis design environment: • - meta-model compiler to provide an API to browse designs, • - backend tools to analyze designs and produce appropriate models, • - easy to incorporate simulation, verification, and synthesis tools

  21. Backup slides: Execution semantics • 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

  22. y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 B y=x+1 Action automata • y=x+1; N

  23. Action automata • y=x+1; y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 B y=x+1 N B x+1 N N

  24. 1 0 0 E x+1 Action automata • y=x+1; y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 B y=x+1 N B x+1 N N

  25. Action automata • y=x+1; y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 1 0 0 1 1 0 B y=x+1 N B x+1 N N E x+1 E y=x+1

  26. B y=x+1 Action automata • y=x+1; y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 N

  27. Action automata • y=x+1; y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 B y=x+1 N B x+1 N

  28. Action automata • y=x+1; y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 B y=x+1 N B x+1 N N

  29. 5 0 0 E x+1 Action automata • y=x+1; y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 B y=x+1 N B x+1 N N

  30. Action automata • y=x+1; y=x+1 x+1 Vx+1 y x B y=x+1 B x+1 E x+1 E y=x+1 c c y:=Vx+1 * * * * = write y B x+1 E x+1 E y=x+1 c c y:=any B x+1 E x+1 c Vx+1 :=x+1 writex E x+1 c Vx+1 :=any 0 0 0 5 0 0 5 5 0 B y=x+1 N B x+1 N N E x+1 E y=x+1

  31. Semantics of await await { (X.n()>0;X.writer; X.writer) comp: z = f(X.read()); (Y.space()>0;Y.reader;Y.reader) Y.write(z); }  startX.writer (true X.n()>0  active X.writer)/ B comp:... E comp:... E await... B await... c startY.reader c (true Y.space()>0  active Y.reader) / B Y.write(z) E Y.write(z)

  32. 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 LTL constraints refer

More Related