Processes, interfaces and platforms. Embedded software modeling in Metropolis. Luciano Lavagno Politecnico di Torino EMSOFT 2002, CASES 2002 Grenoble, France

Metropolis Project: main participants u Cadence Berkeley Labs (USA): methodologies, modeling, formal methods u UC Berkeley (USA): methodologies, modeling, formal methods u Politecnico di Torino (Italy): modeling, formal methods u Universitat Politecnica de Catalunya (Spain): modeling, formal methods u Philips Research (Netherlands): methodologies (multi-media) u Nokia (USA, Finland): methodologies (wireless communication) u BWRC (USA): methodologies (wireless communication) u BMW (USA): methodologies (fault-tolerant automotive controls) u Intel (USA): methodologies (microprocessors) u STMicroelectronics (France, Italy): methodologies (wireless platforms) etropolis

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

Design Methodology Balance between reusability and optimality s orthogonalize design concerns as much as possible s optimize the final implementation as much as necessary Refine Optimize Implementation of System Functional & Non-func. Constraints Function Component Library MPEG decode PES parser VSRC I$D$ CPU UART RTOS Architecture Component Library demux PES parser MPEG decode HSRCVSRC Image Juggler MPEG decode Control System Function Model System Architecture Model BCU HW assist MEM I$D$ CPU UARTINT RTOS API driver Map

Metropolis meta-model 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 Concurrent specification with a formal execution semantics: Key difference with respect to Ptolemy, UML, SystemC, …!!! Concurrent specification with a formal execution semantics:

Meta-model : function netlist process P{ port reader X; port writer Y; thread(){ while(true){... z = f(X.read()); Y.write(z); }}} 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(){... } } interface reader extends Port{ update int read(); eval int n(); } interface writer extends Port{ update void write(int i); eval int space(); } M P1 X Y P2 X Y Env1 Env2 MyFncNetlist R I FA M

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

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 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))); ]] } … scheduler BusArbiter extends Quantity implements BusArbiterService { update void request(event e){ … } update void resolve() { //schedule } } interface BusMasterService extends Port { update void busRead(String dest, int size); update void busWrite(String dest, int size); } interface BusArbiterService extends Port { update void request(event e); update void resolve(); } BusArbiter Bus R I FA M

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

Meta-model: mapping processes 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++) { … }} process MapP{ port CpuService Cpu; void readCpu(){ Cpu.exec(2); Cpu.cpuRead(); } void mapf(){Cpu.exec(12*n); } … } 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); … Function process Mapping process R I FA M

Meta-model: mapping netlist Bus Arbiter Bus Mem Cpu OsSched MyArchNetlist mP1 mP2 mP1 mP2 MyFncNetlist M P1 P2 Env1 Env2 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); MyMapNetlist Bus Arbiter Bus Mem Cpu OsSched MyArchNetlist … … … R I FA M

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

Meta-model: recursive platforms S N N' 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); MyArchNetlistMyFncNetlist M P1 P2 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); RTOSNetlist MyArchNetl ist MyFncNe tlist M P1 P2 B(P2, M.read) B(P2, mP2.readCpu); E(P2, P2.f) E(mP2, mP2.mapf); M RTOS

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.

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

Metropolis infrastructure architecture Meta model compiler Verification tool Front end Meta model language Simulator tool... Back end 1 Abstract syntax trees Back end 2 Back end N Back end 3 Synthesis tool Language 1 Language 2 Language n Translator 1 Translator 2 Translator n...

Metropolis infrastructure status Meta model compiler Spin Prometheus Front end Meta model language SystemC Simulator... Back end 1 Abstract syntax trees Back end 2 Back end N Back end 3 Symbolic HW scheduler SimulinkEsterel/LustreUML Translator 1 Translator 2 Translator n...

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

Example: quasi-static scheduling 1 Specify a network of processes 2 Translate to the Petri net model 3 Find a “schedule” on the Petri net 4 Translate the schedule to a set of tasks (processes)

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

Backup slides: Execution semantics u A sequence of vectors of events is a legal behavior if it s satisfies all constraints s is accepted by all action automata t one for each action of each process

B y=x+1 Action automata u y=x+1; B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x y=x+1 x+1 V x+1 y x N

Action automata u y=x+1; y=x+1 x+1 V x+1 y x B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x B y=x+1B x+1NNN

E x Action automata u y=x+1; y=x+1 x+1 V x+1 y x B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x B y=x+1B x+1NNN

Action automata u y=x+1; y=x+1 x+1 V x+1 y x B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x B y=x+1B x+1E x+1NNNE y=x

B y=x+1 Action automata u y=x+1; y=x+1 x+1 V x+1 y x B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x N

Action automata u y=x+1; y=x+1 x+1 V x+1 y x B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x B y=x+1B x+1NN

Action automata u y=x+1; y=x+1 x+1 V x+1 y x B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x B y=x+1B x+1NNN

E x Action automata u y=x+1; y=x+1 x+1 V x+1 y x B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x B y=x+1B x+1NNN

Action automata u y=x+1; y=x+1 x+1 V x+1 y x B y=x+1B x+1E x+1E y=x+1 y:=V x+1 B x+1E x+1E y=x+1 y:=any c c c c * = write y*** B x+1E x+1 V x+1 :=x+1 E x+1 V x+1 :=any c c write x B y=x+1B x+1E x+1NNNE y=x

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

Semantics summary u Processes run sequential code concurrently, each at its own arbitrary pace u Read-Write and Write-Write hazards may cause unpredictable results s atomicity has to be explicitly specified u Progress may block at synchronization points s awaits s function calls and labels to which awaits or LTL constraints refer