Processes interfaces and platforms Embedded software modeling in

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

Metropolis Project: main participants etropolis 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

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

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

Metropolis meta-model Concurrent specification with a formal execution semantics: • Computation : f : X Z - process : generates a sequence of events Key difference with respect to • Communication : state evaluation manipulation Ptolemy, UML, and. System. C, …!!! - medium : defines states and methods • Coordination : constraints over concurrent actions - 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

F Meta-model : function netlist M R I My. Fnc. Netlist X P 1 Y M P 2 X Y Env 2 Env 1 process P{ A interface reader extends Port{ interface writer extends Port{ port reader X; update int read(); update void write(int i); port writer Y; eval int n(); eval int space(); 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) n=1; space=0; storage=z; } word read(){. . . } }

Meta-model: execution semantics u Processes take actions. s statements and some expressions, e. g. y = z+port. f(), i < 10, … u An execution of a given netlist is a sequence of vectors of events. s 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 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) u An execution is feasible if s s it satisfies all coordination constraints, and it is accepted by all action automata defining meta-model semantics

F Meta-model: architecture components An architecture component specifies services, i. e. : interfaces • what it can do A M R I • how much it costs : quantities, annotation, logic of constraints interface Bus. Master. Service extends Port { interface Bus. Arbiter. Service extends Port { update void request(event e); update void resolve(); update void bus. Read(String dest, int size); update void bus. Write(String dest, int size); } medium Bus implements Bus. Master. Service …{ port Bus. Arbiter. Service Arb; port Mem. Service Mem; … update void bus. Read(String dest, int size) { if(dest== … ) Mem. mem. Read(size); [[Arb. request(B(bus. Read)); GTime. request(B(mem. Read), BUSCLKCYCLE + GTime. annotation(B(bus. Read))); ]] } … } scheduler Bus. Arbiter extends Quantity implements Bus. Arbiter. Service { update void request(event e){ … } update void resolve() { //schedule } } Bus. Arbiter

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

F Meta-model: mapping processes A M R I Mapping process Function process Map. P{ process P{ . . . port Cpu. Service Cpu; void read. Cpu(){ Cpu. exec(2); Cpu. cpu. Read(); } void mapf(){Cpu. exec(12*n); } … z = f(X. read()); thread(){ port reader X; port writer Y; thread(){ while(true){ Y. write(z); while(true){ }} await { int f (int n) { (true; ; ; ) read. Cpu(); int i; (true; ; ; ) mapf(); for (i = 0; i < n; i++) { (true; ; ; ) read. Write(); … } }} B(P, X. read) <=> B(Map. P, read. Cpu); E(P, X. read) <=> E(Map. P, read. Cpu); B(P, f) <=> B(Map. P, mapf); E(P, f) <=> E(Map. P, mapf); …

F Meta-model: mapping netlist A M R I My. Map. Netlist B(P 1, M. write) <=> B(m. P 1, m. P 1. write. Cpu); E(P 1, M. write) <=> E(m. P 1, m. P 1. write. Cpu); B(P 1, P 1. f) <=> B(m. P 1, m. P 1. mapf); E(P 1, P 1. f) <=> E(m. P 1, m. P 1. mapf); B(P 2, M. read) <=> B(P 2, m. P 2. read. Cpu); E(P 2, M. read) <=> E(m. P 2, m. P 2. read. Cpu); B(P 2, P 2. f) <=> B(m. P 2, m. P 2. mapf); E(P 2, P 2. f) <=> E(m. P 2, m. P 2. mapf); My. Fnc. Netlist My. Arch. Netlist P 1 Env 1 M P 2 Env 2 m. P 1 … … … m. P 2 Cpu Os. Sched Bus Arbiter Mem

F Meta-model: platforms A M R I A set of mapping netlists, together with constraints on event mappings, constitutes a platform (constrained set of possible implementations) with a given interface. F A M R interface My. Service extends Port { int my. Service(int d); } I medium Abs. M implements My. Service{ int my. Service(int d) { … } } refine(Abs. M, My. Map. Netlist 2) B(thisthread, Abs. M. my. Service) <=> B(P 1, B(…) <=>My. Map. Netlist 1) B(…); B(…) <=> M. read); B(…); refine(Abs. M, My. Map. Netlist); refine(Abs. M, E(thisthread, Abs. M. my. Service) <=> E(P 2, E(…) <=> E(…); E(…) <=> M. write); E(…); My. Map. Netlist 2 B(P 1, M. write) <=> B(m. P 1, m. P 1. write. Cpu); B(P 1, P 1. f) <=> B(m. P 1, m. P 1. mapf); E(P 1, P 1. f) <=> E(m. P 1, ) B(P 2, M. read) <=> B(P 2, m. P 2. read. Cpu); E(P 2, P 2. f) <=> E(m. P 2, m. P 2. mapf); My. Fnc. Netlist P 1 M M P 2 My. Arch. Netlist My. Map. Netlist 1 B(P 1, M. write) <=> B(m. P 1, m. P 1. write. Cpu); B(P 1, P 1. f) <=> B(m. P 1, m. P 1. mapf); E(P 1, P 1. f) <=> E(m. P 1, ) B(P 2, M. read) <=> B(P 2, m. P 2. read. Cpu); E(P 2, P 2. f) <=> E(m. P 2, m. P 2. mapf); My. Fnc. Netlist P 1 M P 2 My. Arch. Netlist

Meta-model: recursive platforms B(Q 2, S. cdx) <=> B(Q 2, m. Q 2. exc. Cpu); E(Q 2, M. cdx) <=> E(m. Q 2, m. Q 2. exc. Cpu); B(Q 2, Q 2. f) <=> B(m. Q 2, m. Q 2. mapf); E(Q 2, P 2. f) <=> E(m. Q 2, m. Q 2. mapf); S N N' RTOSNetlist B(P 1, M. write) <=> B(m. P 1, m. P 1. write. Cpu); B(P 1, P 1. f) <=> B(m. P 1, m. P 1. mapf); E(P 1, P 1. f) <=> E(m. P 1, ) B(P 2, M. read) <=> B(P 2, m. P 2. read. Cpu); E(P 2, P 2. f) <=> E(m. P 2, m. P 2. mapf); My. Fnc. Netlist P 1 M P 2 My. Arch. Netlist B(P 2, M. read) <=> B(P 2, m. P 2. read. Cpu); E(P 2, P 2. f) <=> E(m. P 2, m. P 2. mapf); My. Fnc. Ne My. Arch. Netl M tlist P 1 P 2 M ist

Meta-model: summary • Concurrent specification with a formal execution semantics • Feasible executions of a netlist: sequences of event vectors • Quantities can be defined 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 Application-specific methodologies Multi-media, wireless communication, mechanical controls, processors Meta-model Library Infrastructure • Models of computation • Architecture platforms • Metropolis meta-model - language - modeling mechanisms • Meta-model compiler Tools Simulator QSS PIG STARS SPIN …

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

Metropolis infrastructure status Simulink Esterel/Lustre Translator 1 Translator 2 UML . . . Translatorn Meta model language Meta model compiler Front end Abstract syntax trees Back end 1 System. C Simulator Back end 2 Prometheus Back end 3 Spin . . . Back end. N Symbolic HW scheduler

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

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

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

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

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

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

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

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

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

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

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

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

Semantics of await { (X. n()>0; X. writer) comp: z = f(X. read()); (Y. space()>0; Y. reader) Y. write(z); } (true X. n()>0 B await. . . active X. writer)/ start X. writer c (true Y. space()>0 E comp: . . . B comp: . . . start Y. reader active Y. reader) / B Y. write(z) c E Y. write(z) 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