1. Modeling of Heterogeneous Systems in Metropolis
Alberto Ferrari
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
11/9/2018

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
11/9/2018

4. Technical Contents
11/9/2018

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
11/9/2018

6. Real-Time and Distributed
Information Systems
Mobile Communications
Navigation
Telematics
Fail Stop
Soft Real Time
MOST Firewire
Access to WWW
DAB
Fire Wall
Body Electronics
Theft warning
Air Conditioning
Body Functions
CAN Lin
Door Module
Light Module
Fail Safe
Gate Way
Real Time
System Electronics
ABS
CAN TTCAN
Shift by Wire
Engine Management
Driving and Vehicle Dynamic Functions
Gate Way
Fault Functional
Hard Real Time
Steer by Wire
Brake by Wire
FlexRay
11/9/2018

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
11/9/2018

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
11/9/2018

9. Platform based Design Application Space
Design-Space
Export
Mapping
Architectural Space
Application Space
Application Instance
Platform Instance
System
(HW and SW)
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.
How are we going to cope with all the previously mentioned dilemmas? SLD!
Within SLD we have PBD
Within PBD we have Metropolis.
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.
11/9/2018

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/9/2018

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
11/9/2018

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
11/9/2018

13. Software Tools Solution
Meta model
compiler
Verification tool
Synthesis tool
Front end
Meta model language
Simulator tool
...
Back end1
Abstract syntax trees
Back end2
Back endN
Back end3
Metropolis Meta Modeling (MMM) language4 and compiler are the core components.
Backend tools provide various operations for manipulating designs and performing analysis.
How are we going to cope with all the previously mentioned dilemmas? SLD!
Within SLD we have PBD
Within PBD we have Metropolis.
11/9/2018

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)
11/9/2018

15. Metropolis Framework Metropolis Infrastructure Synthesis/Refinement
Function
Specification
Design Constraints & Assertions
Architecture (Platform)
Specification
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
11/9/2018

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 process networks
discrete events
synchronous/ reactive
hybrid systems
continuous time
11/9/2018

17. Metropolis Objects (partial)
Metropolis elements adhere to a “separation of concerns” point of view.
Processes (Computation)
Proc1 P1 P2
Active Objects
Sequential Executing Thread
Media (Communication) I1 I2
Media1
Passive Objects
Implement Interface Services
More Metro
Talk about the fact that these are the core objects
11/9/2018

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
11/9/2018

19. Writer: Process P (Producer)
Writer.mmm: Port (interface) definition
package producers_consumer;
interface IntWriter extends Port{
update void writeInt(int i);
eval int nspace(); }
P.mmm: Process behavior definition
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
11/9/2018

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(); } }}
11/9/2018

21. Media M: Writer services
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;
11/9/2018

22. 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
Media M 
Proc P2
Proc C
Proc P3
11/9/2018

23. 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);
Media M 
Proc P2
Proc C
Proc P3
Proc P1
11/9/2018

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
11/9/2018

25.  Media M: await Communication definition Media M
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;
11/9/2018

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; }
11/9/2018

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
11/9/2018

28. Metropolis Objects: adding quantity managers
Metropolis elements adhere to a “separation of concerns” point of view.
Processes (Computation)
Proc1 P1 P2
Active Objects
Sequential Executing Thread
Media (Communication) I1 I2
Media1
Passive Objects
Implement Interface Services
More Metro
Talk about the fact that these are the core objects
Quantity Managers (Coordination)
QM1
Schedule access to resources and quantities
11/9/2018

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

30. Producer-Consumer Example: Declarative
(Given an event e, t.e is its tag)
beg(w)
beg(r) …
write(d); …
d = read( );
end(w)
end(r)
Media M 
Proc P
Proc C
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)
11/9/2018

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);
The Metropolis metamodel contains two types of constraints. There are temporal constraints that take the form of LTL logic. There are also quantitative constraints, which are expressable in the logic of constraints (LOC) and the extended logic of constraints (ELOC).  Constraints can either be used to restrict the set of legal behaviors, or as monitors to verify implementation. There is currently a checker fo LOC constraints, as well as an interface to the SPIN model checker.
11/9/2018

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
11/9/2018

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

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])
11/9/2018

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
11/9/2018

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
11/9/2018

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

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

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 Pi can 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
11/9/2018

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

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

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

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

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

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
11/9/2018

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

47. 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 annotate events 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
Talk about puppet analogy
Introduce the scheduling and scheduled netlist and the concept of events
Explain the animation.
Media1
QM1 I2
11/9/2018

48. Key Modeling Concepts
An event is the fundamental concept in the framework
Represents a transition in the action automata of 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
Make action automata a link
Have a link to a backup slide
More terminology
Full Event explanation
How automata work
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 , December 1998
11/9/2018

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.
Show the formal semantics of the action automata
Note that they may be gone in Metro II
11/9/2018

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.
11/9/2018

51. 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
write x
E x+1
Vx+1 :=any
Vx+1 y x 5 1 5 1
B y=x+1 N
B x+1 N N
E x+1
E y=x+1
Return
11/9/2018

52. 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)
11/9/2018

53. q-manager (scheduler) P1.pZ.write() < P2.pX.read()
Metropolis Meta Model
The behavior of a concurrent system:
computation
f: X Z
firing rule
communication
state
methods to
- store data
- retrieve data
coordination
constraints on concurrent actions
algorithms to enforce the constraints
process
medium
q-manager (scheduler)
process P1{
port pX, pZ;
thread(){
// condition to read X
// an algorithm for f(X)
// condition to write Z } P1
medium M{
int[] storage;
int space;
void write(int[] z){ ... }
int[] read(){ ... } } P2 M pX pZ pX pZ
The Metropolis meta model represents a system function as a set of concurrently communicating sequential processes. Communication is modeled explicitly using objects that we call media. A medium is defined with a set of variables and functions. Values of the variables constitute states of the medium. The variables can be referenced only by the functions defined in the medium, and communication among processes is established by calling these functions to change or evaluate the states of media. This mechanism allows communication semantics to be modeled solely by specifying media, independent from process specifications. In this view, a process is an active object in the sense that it specifies what it computes and what it wants to communicate by interacting with media, while a medium is passive as it only provides a means for processes to communicate. While the user may specify media for desired communication semantics, we provide a library of some well-known semantics, each of which has been modeled in this way, so that one can simply choose one to make a specification.
The functions of a medium are grouped into a set of interfaces. As with object-oriented languages, an interface simply declares functions, while a medium implements them. An object declares ports for particular interfaces, and only the functions of the interfaces can be called in the object for communication. Any medium can be connected to a given port as long as it implements the corresponding interface. This is convenient for refining communication, since a medium that models semantics at a high level of abstraction can be replaced with one for the more detailed semantics, without changing the code of the processes. The connections between media and ports are statically specified, so that the entire system function is represented as a network of processes and media. This modeling concept is also employed in Spec C
Associated also with a medium is a formal specification of properties that have to hold for the medium throughout the execution of the system. Some properties are static, e.g. the maximum number of objects to which the medium is connected, while others are dynamic, e.g. a set of valid orders of executions of the functions defined in the medium. We use logic similar to path expressions, with the state variables and functions of the medium being the operands. This will be used by formal verification tools.
It is often necessary to specify how to coordinate execution of concurrent processes, i.e. scheduling. The meta model uses a special type of processes for this purpose. The network may contain an arbitrary number of processes of this type, each of which is statically connected to processes to be scheduled, observes states of those processes, and controls the execution. Currently, a scheduling policy is specified using a sequential program, while we also plan to allow the user to specify logic expressions to define valid execution orders, without committing to a specific scheduling algorithm. Quantity managers serve to annotate, track, and synchronize different blocks based on their state or quantity. Global Time (or gTime) is a built-in quantity for the metamodel. Other potential quantities include: power, area, and local time. M’ M’ S
P1.pZ.write() < P2.pX.read()

54. Metropolis Meta Model
Do not commit to the semantics of a particular Model of Computation (MoC)
Define a set of “building blocks”:
specifications with many useful MoCs can be described using the building blocks.
unambiguous semantics for each building block.
syntax for each building block a language of the meta model.
Represent behavior at all design phases; mapped or unmapped
Question: What is a good set of building blocks?

55. Metropolis Driver: Picture-in-Picture Design Exercise
Evaluate the methodology with formal techniques applied.
Function
Input: a transport stream for multi-channel video images
Output: a PiP video stream
- the inner window size and frame color dynamically changeable
USRCONTROL
PIP
MPEG
RESIZE
DEMUX
PARSER
JUGGLER
MPEG
60 processes with 200 channels
11/9/2018

56. Meta-model : function netlist
MyFncNetlist P2 X Y X P1 Y M
Env1
Env2
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(){ ... }
11/9/2018

57. Multi-Media System: Abstraction Levels
Network of processes with sequential program for each
Unbounded FIFOs with multi-rate read and write
Communication refined to bounded FIFOs and shared memories with finer primitives (called TTL API):
allocate/release space, move data, probe space/data
Mapped to resources with coarse service APIs
Services annotated with performance models
Interfaces to match the TTL API HW
DSP HW
CPU
Cycle-accurate services and performance models $
RAMs
RAMd
DMA HW
MemS $
MemF
DSP HW
11/9/2018 $
CPU $

58. Media M: Writer services
finite
Communication definition
package producers_consumer;
medium IntM implements IntReader, IntWriter, Semaphore {
int[] storage;
int reading, writing, space, n, length;
public IntM(String name, int nelement) {
space = length = nelement;
storage = new int[nelement];
reading = writing = n = 0; }
public update void writeInt(int w) {
await{ (space > 0; this.Semaphore, this.Semaphore) {
space --; n++;
storage[writing++] = w;
if (writing == length) writing = 0; }}
11/9/2018

59. Media M: Writer services
finite
Communication definition
public update int readInt() {
int _retval = 0;
await(n>0; this.Semaphore; this.Semaphore){
n--, space++;
_retval = storage[reading++];
if (reading == length) reading = 0; }
return _retval;
public eval int nspace() {
await(true; this.Semaphore; this.Semaphore){
return space; }}
public eval int num() {
return n;
11/9/2018

60. Binding Adjacent Levels of Abstraction
Writer process
Reader process
write(), read()
Example: a unbounded FIFO v.s. a bounded FIFO with the finer service.
Unbounded FIFO Level
Bounded FIFO API, e.g. release space, move data
FIFO width and length parameterized
Bounded FIFO Level
: refinement relation
Y2T
write()
Th,Wk
T2Y
read()
Implement the upper level services using the current services
Metropolis represent both levels of abstraction explicitly, rather than replacing the upper level.
- essential for specifying the refinement relation.
Refinement relation is associated with properties to preserve through the refinement.
- the properties can be formally specified, and verified either formally or through simulation.
11/9/2018

61. Task Transaction Level (TTL) Refinement
ttlrefyapi
readth()
readth()
rdwrth
writeth()
writeth()
readth()
readth()
writeth()
writeth()
Producer
yapiprocess
Consumer
yapiprocess
Yapi2TTL
TTL2Yapi
write(data,10)
read(data,10)
claim_space()
release_data(chunk)
release_space(chunk)
claim_data()
ttlmedium
Source-destination Handshaking
Yapi2TTL and TTL2yapi are two media that brake up yapi write/read actions into a sequence of actions.
The ttlmedium is a finite storage element implementing four services. Before writing (release_data), a producer has to reserve its space using claim_space. A consumer will first read the data using claim_data and then will make the space available using release_space.
The threshold medium contains the number of tokens that have not been written yet and the number of tokens that have not been read yet.
(don’t go into the details of the protocol, it was proposed by Philips in the context of the COSY project).
claim_space()
claim_data()
release_data(chunk)
release_space(chunk)
11/9/2018

62. TTL Netlist Refinement
Objects are create and connected
package metamodel.plt.TTL;
import metamodel.plt.yapi.*;
public netlist TTLmediumnetlist {
boundedfifo bf;
rdwrthreshold rwtr;
yapichannel channel;
yapi2TTLchannel y2bf;
TTL2yapichannel bf2y;
public TTLmediumnetlist(String n,yapichannel ch,
int ts,int nt,int it,stfunc f) {
super(n);
channel = ch;
y2bf = new yapi2TTLchannel(n+"y2bf",ts,nt,f);
bf2y = new TTL2yapichannel(n+"bf2y",ts,nt,f);
rwtr = new rdwrthreshold(n+"rdwrth");
bf = new boundedfifo(n+"bf",ts,nt,it, 1); // default width
//addcomponent and connect statements follow …}
Y2T
write()
Th,Wk
T2Y
read()
Yapi channel to be refined
Netlist that refines a unbounded yapi channel.
The netlist constructor takes the yapi channel as parameter. It first instantiates all components and connects them then….
11/9/2018

63. TTL Netlist Refinement
package metamodel.plt.TTL;
import metamodel.plt.yapi.*;
public netlist TTLmediumnetlist { …
public TTLmediumnetlist(String n,yapichannel ch,
int ts,int nt,int it,stfunc f) {
refine(ch,this);
refineconnect(this,
getnthconnectionsrc(ch,yapioutinterface,0),
getnthconnectionport(ch,yapioutinterface,0),
y2bf);
getnthconnectionsrc(ch,yapiininterface,0),
getnthconnectionport(ch,yapiininterface,0),
bf2y); …} 1 2 2 1 3
Y2T
write()
Th,Wk
T2Y
read()
….refines the channel using “this” netlist. Finally, it has to change the connections. In order to do that, the refineconnect statement is used.
Getnthconnectionsrc gets the process
Getnthconnectionport gets the port
Y2bf is the name of the object that is indicated as Y2T in the figure to the right.
Done! 3
11/9/2018

64. Refinement Verification
Y2T
write()
Th,Wk
T2Y
read()
Writer
process
Reader
Two properties checked for the refinement:
1. Deadlock
2. Data consistency:
Always: forall i: Writer.data[i] = Reader.data[i];
Both were verified for the refined protocol:
1. Automatically applied SPIN in Metropolis:
Translate the protocol description to SPIN
Found a deadlock in the original algorithm provided by Philips
2. Automatically applied LoC Monitor in Metropolis
Translate the property formula to executable code (simulation monitor)
Simulate the monitor together with the original processes and refined protocol
Found two bugs in the protocol description (a piece of the writer's data was conditionally ignored in the reader's side).
11/9/2018

65. Architecture Exploration
Configure the resources, e.g. the size of an internal memory, width of a bus.
Bind the processes to the resources.
Compose the resource services, e.g. schedules of data transfers, compilation of basic blocks.
DSP
CPU HW
Once done, performance analysis and simulation can be carried out, using the performance models associated with the resource services.
But, to do so, we need models for the resources: services and performance.
11/9/2018

66. Resource Modeling
What to model/abstract depends on what you are concerned about.
Example:
Where should my data be located?
When should my data be transferred?
How often do my peripherals generate interrupts?
These all influence my decisions on sizes of internal memories, bus configuration, data transfer schedules.
DSP
CPU HW
Resource models based on these concerns:
Memory: internal (single-access, dual-access), external
DSP: bus read/write(), check/serve_Interrupt(), execute()
performance: latency per byte transfer
DMA control, CPU: similar
peripheral: non-deterministic interrupt generator
could be restricted wrt supported behavior (under development)
11/9/2018

67. Architecture Exploration
Configure the resources, e.g. the size of an internal memory, width of a bus.
Bind the processes to the resources.
Compose the resource services, e.g. schedules of data transfers, compilation of basic blocks.
DSP
CPU HW
Performance analysis and simulation can be carried out, using the performance models associated with the resource services.
Effective scheduling of process operations mapped to a CPU is a key issue:
reduce the context-switching between tasks for efficient execution
increase data coherency among processes for efficient memory usage
11/9/2018

68. Architecture components
An architecture component specifies services, i.e.
what it can do
how much it costs
: interfaces, implementation
: quantities, annotation, logic of constraints
11/9/2018

69. A Simple Architecture Model
Scheduled Netlist
Scheduling Netlist
Task1
Task2
Global
Time P1 P2
RtosIf
RtosIf
Cpu1
Cpu2
RTOS1
BusPort
BusPort
RTOS2
MasterIf
Bus1
MasterIf
Arbiter
SlavePort
11/9/2018

70. Meta-model: architecture components
An architecture component specifies services, i.e.
what it can do:
how much it costs:
interfaces, methods, coordination (awaits, constraints), netlists
quantities, annotated with events, related over a set of events
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); } …
11/9/2018

71. 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))); }}
11/9/2018

72. 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
Sw2 Hw 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...
11/9/2018

73. CPU Media Cpu CPU port interface CPUServices extends Port {
update void cpuExec(int ClockClycles);
update void cpuWrite(int target, int addr, int[] data);
update void cpuRead(int target, int addr, int[] data); }
CPU port
Cpu
BusMaster port
medium CPU implements CPUServices {
port BusMaster Master;
update void cpuExec(int ClockCycles) {
// exclusive usage and backannotation of ClockCycles delay }
update void cpuRead(…) { … Master.Read(); … }
update void cpuWrite(…) { … Master.Write(); … }
11/9/2018

74. CPU Media Cpu CPU port interface CPUServices extends Port {
update void cpuExec(int ClockClycles);
update void cpuWrite(int target, int addr, int[] data);
update void cpuRead(int target, int addr, int[] data); }
CPU port
Cpu
Scheduler port
BusMaster port
medium CPU implements CPUServices {
port BusMaster Master;
port Scheduler S;
update void cpuExec(int ClockCycles) {
{$ // request exclusive access to CPU for ClockCycles delay
beg{ S.request(B(thisthread, this.cpuExec)); }
end{ S.request(B(thisthread, this.cpuExec), ClockCycles, Release );} $} }
update void cpuRead(…) { … Master.Read(); … }
update void cpuWrite(…) { … Master.Write(); … }
11/9/2018

75. CPU Media Cpu CPU port interface CPUServices extends Port {
update void cpuExec(int ClockClycles);
update void cpuWrite(int target, int addr, int[] data);
update void cpuRead(int target, int addr, int[] data); }
Cpu
Scheduler port
BusMaster port
medium CPU implements CPUServices {
port BusMaster Master;
port Scheduler S;
update void cpuExec(int ClockCycles) { {$ … $} }
update void cpuRead(…) {
block(R1) { // request exclusive access to CPU for RWCycles delay
beg{ S.request(B(thisthread, this.cpuExec)); }
end{ S.request(B(thisthread, this.cpuExec), RCycles); }
Master.readSlave(…);
block(R2) {end{ S.request(B(thisthread, this.cpuExec), Release );}
update void cpuWrite(…) { … Master.writeSlave(); … }
11/9/2018

76. Bus Model Bus 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(); }
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 } }
BusArbiter
Bus
11/9/2018

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

78. Meta-model: mapping processes
process MapP{
port CpuService Cpu;
void readCpu(){
Cpu.exec(); Cpu.cpuRead(); }
void mapf(){ …} … … … …
thread(){
while(true){
await {
(true; ; ;) readCpu();
(true; ; ;) mapf();
(true; ; ;) readWrite();
}}}
11/9/2018

79. PiP Architecture CPU RTOS Bus Mem Scheduled Netlist Scheduling Netlist
GlobalTime
Task1
TaskN
CPU RTOS
CpuScheduler
Bus
BusScheduler
Mem
MemScheduler
11/9/2018

80. Meta-model: mapping processes
Function process
Mapping process
process P{
port reader X;
port writer Y;
thread(){
while(true){
...
z = f(X.read());
Y.write(z);
}}}
process MapP{
port CpuService Cpu;
void readCpu(){
Cpu.exec(); Cpu.cpuRead(); }
void mapf(){ …} …
thread(){
while(true){
await {
(true; ; ;) readCpu();
(true; ; ;) mapf();
(true; ; ;) readWrite();
}}}
MyFncNetlist M P C
Env1
Env2
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); …
11/9/2018

81. 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);
MyFncNetlist M P1 P2
Env1
Env2
Bus
Arbiter
Mem
Cpu
OsSched
MyArchNetlist …
Bus
Arbiter
Mem
Cpu
OsSched
MyArchNetlist
mP1
mP2
mP1
mP2
11/9/2018

82. Meta-model: platforms
interface MyService extends Port { int myService(int d); }
MyArchNetlist
MyFncNetlist 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
B(…) <=> B(…);
E(…) <=> E(…);
refine(AbsM, MyMapNetlist2)
B(thisthread, AbsM.myService) <=> B(P1, M.read);
E(thisthread, AbsM.myService) <=> E(P2, M.write);
refine(AbsM, MyMapNetlist);
MyArchNetlist
MyFncNetlist 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)
medium AbsM implements MyService{
int myService(int d) { … } }
MyArchNetlist
MyFncNetlist 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
11/9/2018

83. Meta-model: platforms
A set of mapping netlists, together with constraints on event relations to a given interface implementation, constitutes a platform of the interface.
interface MyService extends Port { int myService(int d); }
MyArchNetlist
MyFncNetlist 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
B(…) <=> B(…);
E(…) <=> E(…);
refine(AbsM, MyMapNetlist2)
B(thisthread, AbsM.myService) <=> B(P1, M.read);
E(thisthread, AbsM.myService) <=> E(P2, M.write);
refine(AbsM, MyMapNetlist);
MyArchNetlist
MyFncNetlist 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)
medium AbsM implements MyService{
int myService(int d) { … } }
MyArchNetlist
MyFncNetlist 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
11/9/2018

84. Meta-model: recursive paradigm of platforms
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); S N N'
MyArchNetlist
MyFncNetlist 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
MyArchNetlist
MyFncNetlist M P1 P2
B(P2, M.read) <=> B(P2, mP2.readCpu);
E(P2, P2.f) <=> E(mP2, mP2.mapf);
11/9/2018

85. A Simple Architecture Model
B(P1, M.write) <=> B(mP1, mP1.writeCpu); E(P1, M.write) <=> E(mP1, mP1.writeCpu);
Task1 P1
Cpu1
RTOS1
Scheduled Netlist
Scheduling Netlist
Global
Time
RtosIf
BusPort
Task2 P2
Bus1
SlavePort
Cpu2
MasterIf
RTOS2
Arbiter
Proc P2
Proc C
Media M 
Proc P3
Proc P1
Metropolis supports
Hardware/Software
modeling
Metropolis supports Hierarchical
Composition of Services
(Platforms)
11/9/2018

86. Hybrid Modeling in Metropolis
blackbox(SystemCSim)%%
setnewinputsample(f,t,e);
newsample = integrate();
rt = newsample[1];
re = newsample[0]; %%
Analog
Injection
Locking Pll
f: desired frequency
t: final integration time
e: error threshold
rt: current analog block time
re: error
Digital (FSM)
Ctrl
Global
Time
Annotates time
11/9/2018

87. Injection Locking PLL Control Example
TRYLOCKING
LOCKING
analog
MAYBE
LOCKED
11/9/2018

88. Simulation Results 11/9/2018 TRY TO LOCK 0 LOCKING 5.34303e-08
TRY TO LOCK e-08
LOCKING e-07
LOCKING e-07
TRY TO LOCK e-07
LOCKING e-07
LOCKING e-07
TRY TO LOCK e-07
LOCKING e-07
MAYBE LOCKED e-07
TRY TO LOCK e-07
LOCKING e-07
MAYBE LOCKED e-07
LOCKED! Go Bears! e-06
11/9/2018

89. Metropolis design environment
Architecture
Communication Spec
Constraints
Functional Spec
Meta model language
Metropolis interactive Shell
Load designs
Browse designs
Relate designs
refine, map etc
Invoke tools
Analyze results
Meta model
compiler
Front end
Abstract syntax trees
Back end1
Back end2
Back end3
...
Back endN
Simulator tool
Synthesis tool
Verification tool
Verification tool
11/9/2018

90. Backend Point Tools Synthesis/refinement: Verification/analysis:
Quasi-static scheduling
Scheduler synthesis from constraint formulas
Interface synthesis
Refinement (mapping) synthesis
Architecture-specific synthesis from concurrent processes for:
Hardware (with known architecture)
Dynamically reconfigurable logic
Verification/analysis:
Static timing analysis for reactive processes
Invariant analysis of sequential programs
Refinement verification
Formal verification for software
Simulation
Metropolis SystemC Simulator - Synthesis
Communication Synthesis - Interface Synthesis - Quasi-Static Scheduling - Analysis and Verification
LOC-Checker/Monitor SPIN Interface Refinement Verification Prometheus Timing Verification
11/9/2018

91. Metropolis 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, power, global indices, composite quantities.
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,
a mapping coordinates executions of function and architecture netlists,
a refinement through event coordination provides a platform.
Metropolis design environment:
meta-model compiler to provide an API to browse designs,
backend tools to analyze designs and produce appropriate models.
11/9/2018

92. Acknowledgments PARADES EEIG:
Prof. A.S.Vincentelli
L.Mangeruca, M.Baleani
UCB: Alessandro Pinto and the Metropolis Team
11/9/2018