Modeling%20of%20Heterogeneous%20Systems%20in%20Metropolis

1
Modeling of Heterogeneous Systems in Metropolis

• Alberto Ferrari
• aferrari_at_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 ChainCar 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
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
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
Design Constraints Assertions
Function Specification
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

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
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 ProducerConsumer 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

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 lt 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 lt 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()gt0 this.Semaphore
this.Semaphore) _retval
storage.read() return
_retval
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
Proc P2
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 lt 3 i)
P p new P("Producer"i)
addcomponent(p, this, "Producer"i)
connect(p, port_wr, m) for (int i
0 i lt 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()gt0
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
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
Producer-Consumer Example Imperative await
write(d)
d read( )
await()
30
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) lt t.end(w) t.beg(r) lt
t.end(r) t.beg(w) lt t.beg(r) (in case of
simultaneous access) does not exist t such that
t.end(w) gt t gt t.beg(w) (write atomicity) does
not exist t such that t.end(r) gt t gt 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) lt B( P2, P2.run) B(P1, P1.s1) lt
E(P2, P2.run) B(P1, P1.s2) lt B( P2, P2.run)
B(P1, P1.s2) lt 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(en) where
• n?I index expression, e.g. 2, i3
• Index variable i, the only variable in a formula,
  e.g. Displayi-5 and Stimulii
• e event name, e.g. in, out, Stimuli or
  Display ? en instances of events, e.g.
  in2, Stimuli0, Display10
• a annotation, e.g. t(Display5)
• 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
Examples of LOC Constraints
Throughput at least 3 Display events will be
produced in any period of 30 time units. t
(Displayi3) t (Displayi) lt 30
34
Examples LOC Constraints (contd)
Performance constraints Rate, e.g. Displays
are produced every 10 time units, t(Displayi1)
- t(Displayi) 10 Latency, e.g. Display is
generated no more than 25 time units after
Stimuli, t(Displayi) - t(Stimulii) lt
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(Displayi) - (i1) 10 lt 4 Functional
Constraints Data consistency, e.g.
data(inputi) data(outputi)
35
Examples LOC Constraints (contd)
Latency, e.g. Display is generated no more than
25 time units after Stimuli, t(Displayi) -
t(Stimulii) lt 25 What if not every stimulus
is displayed? t(Displayi) - t(Stimulicause(Dis
playi)) lt 25
36
Some Remarks on LOC Formulas

• Time is only one of the possible annotations
• cause(Displayi), data(inputi), 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
Producer-Consumer Example Imperative with QM
Lw _at_ write(d) //request code
_at_
Lr _at_ d read() //request code
_at_
Scheduled Netlist
Quantity Manager (Scheduler)
Scheduling Netlist
38
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 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

40
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
Producer-Consumer Example Semantic (intuitive)
//Top level resolve function is //invoked void
resolve() qm.resolve( )
Scheduled Netlist
Quantity Manager (Scheduler)
Scheduling Netlist
42
Producer-Consumer Example Semantic (intuitive)
//QM resolve function void resolve() //pick
one event per process
Scheduled Netlist
Quantity Manager (Scheduler)
Scheduling Netlist
43
Producer-Consumer Example Semantic (intuitive)
//Top level postcond void postcond()
qm.postcond( )
Scheduled Netlist
Quantity Manager (Scheduler)
Scheduling Netlist
44
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
Producer-Consumer Example
write(d)
d read( )
await()
Metropolis supports Imperative
Coordination (await or QM request)
Metropolis supports Declarative Coordination
(Constraints on Quantities)
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
Global Time
P2
I1
Media1
I2
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

• 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 zport.f(), zport.f(), port.f(), i lt 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.

51
Action Automata

• yx1

yx1 x1
B yx1
B x1
E x1
E yx1
yVx1
write y



B x1
E x1
E yx1
yany
B x1
E x1
Vx1 x1
write x
E x1
Vx1 any
Vx1 y x
0 0 0
5 0 0
5 5 0
1 0 0
1 1 0
B yx1
B x1
E x1
N
N
N
E yx1
Return
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)

53
Metropolis Meta Model
The behavior of a concurrent system

• coordination
• constraints on concurrent actions
• algorithms to enforce the constraints

• communication
• state
• methods to
• - store data
• - retrieve data

medium
q-manager (scheduler)
process
process P1 port pX, pZ thread() // condition
to read X // an algorithm for f(X) //
condition to write Z
medium M int storage int space
void write(int z) ... int read() ...

P1
P2
M
pX
pZ
pX
pZ
M
M
S
P1.pZ.write() lt 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
60 processes with 200 channels
MPEG
56
Meta-model function netlist
MyFncNetlist
P1
Y
X
M
interface writer extends Port update void
write(int i) eval int space()
interface reader extends Port update int
read() eval int n()
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(spacegt0 this.writer this.writer)
n1 space0 storagez word
read() ...
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

CPU
RAMs
RAMd

• Cycle-accurate services and performance models

DMA
HW

DSP
MemF
MemS
HW

CPU

58
Media M Writer services
Media M 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 intnelement reading
writing n 0 public update void
writeInt(int w) await (space gt 0
this.Semaphore, this.Semaphore)
space -- n
storagewriting w if
(writing length) writing 0
59
Media M Writer services
Media M finite

• Communication definition

public update int readInt() int
_retval 0 await(ngt0 this.Semaphore
this.Semaphore) n--, space
_retval storagereading if
(reading length) reading 0
return _retval public eval int
nspace() await(true this.Semaphore
this.Semaphore) return space
public eval int num()
await(true this.Semaphore this.Semaphore)
return n
60
Binding Adjacent Levels of Abstraction

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

61
Task Transaction Level (TTL) Refinement
ttlrefyapi
rdwrth
writeth()
writeth()
readth()
readth()
writeth()
writeth()
Producer
Consumer
yapiprocess
yapiprocess
Yapi2TTL
TTL2Yapi
ttlmedium
claim_space()
claim_data()
release_data(chunk)
release_space(chunk)
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
Yapi channel to be refined
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) refineconnect(this,
getnthconnectionsrc(ch,yapiininterface,0),
getnthconnectionport(ch
,yapiininterface,0),
bf2y)
1
2
2
1
3
3
64
Refinement Verification

• Two properties checked for the refinement
• 1. Deadlock
• 2. Data consistency
• Always forall i Writer.datai
  Reader.datai
• 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).

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.

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

• 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)

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.

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

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
69
A Simple Architecture Model
Scheduled Netlist
Scheduling Netlist
Task1
Task2
Global Time
P1
P2
RtosIf
RtosIf
Cpu2
Cpu1
BusPort
BusPort
RTOS2
MasterIf
Bus1
Arbiter
MasterIf
SlavePort
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)
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, lt, ,
• 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) -gt equal(A(e1,
i), A(e2, j)) GXI.A(e1, i) lt
GXI.A(e2, j) -gt (less(A(e1, i), A(e2, j))
equal(A(e1, i), A(e2. j)))
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
ASIC2
ASIC1
Sw1
Hw
Sw2
Hw
C-Ctl
C-Ctl
Sw I/F
Channel I/F
Channel Ctl
B-I/F
Wrappers
Bus I/F
CPU-IOs
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...
73
CPU Media
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
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()

74
CPU Media
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) //
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()
75
CPU Media
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)
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()
76
Bus Model
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(thisthread, this.busRead))
GTime.request(B(thisthread,
this.memRead), BUSCLKCYCLE GTime.A(B(thisthrea
d,
this.busRead)))
scheduler BusArbiter extends Quantity
implements BusArbiterService update void
request(event e) update void resolve()
//schedule
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.
78
Meta-model mapping processes
Mapping process
process MapP port CpuService Cpu void
readCpu() Cpu.exec() Cpu.cpuRead()
void mapf()



thread() while(true) await
(true ) readCpu() (true ) mapf()
(true ) readWrite()
79
PiP Architecture
Scheduled Netlist
Scheduling Netlist
GlobalTime
TaskN
Task1
CPU RTOS
CpuScheduler
BusScheduler
Bus
MemScheduler
80
Meta-model mapping processes
Mapping process
Function process
process MapP port CpuService Cpu void
readCpu() Cpu.exec() Cpu.cpuRead()
void mapf()
process P port reader X port writer Y
thread() while(true) ... z
f(X.read()) Y.write(z)
thread() while(true) await
(true ) readCpu() (true ) mapf()
(true ) readWrite()
B(P, X.read) ltgt B(MapP, readCpu) E(P, X.read)
ltgt E(MapP, readCpu) B(P, f) ltgt B(MapP, mapf)
E(P, f) ltgt E(MapP, mapf)
81
Meta-model mapping netlist
MyMapNetlist
B(P1, M.write) ltgt B(mP1, mP1.writeCpu) E(P1,
M.write) ltgt E(mP1, mP1.writeCpu) B(P1, P1.f)
ltgt B(mP1, mP1.mapf) E(P1, P1.f) ltgt E(mP1,
mP1.mapf) B(P2, M.read) ltgt B(P2, mP2.readCpu)
E(P2, M.read) ltgt E(mP2, mP2.readCpu) B(P2,
P2.f) ltgt B(mP2, mP2.mapf) E(P2, P2.f) ltgt
E(mP2, mP2.mapf)
82
Meta-model platforms
interface MyService extends Port int
myService(int d)
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)
84
Meta-model recursive paradigm of platforms
85
A Simple Architecture Model
B(P1, M.write) ltgt B(mP1, mP1.writeCpu) E(P1,
M.write) ltgt E(mP1, mP1.writeCpu)
Metropolis supports Hierarchical Composition of
Services (Platforms)
Metropolis supports Hardware/Software modeling
86
Hybrid Modeling in Metropolis
blackbox(SystemCSim) setnewinputsample(f,t,e
) newsample integrate() rt
newsample1 re newsample0
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
87
Injection Locking PLL Control Example
TRYLOCKING
LOCKING
analog
MAYBE
LOCKED
88
Simulation Results
TRY TO LOCK 0 LOCKING 5.34303e-08 TRY TO LOCK
5.54873e-08 LOCKING 1.08918e-07 LOCKING
1.61311e-07 TRY TO LOCK 1.61317e-07 LOCKING
2.14747e-07 LOCKING 2.67354e-07 TRY TO LOCK
2.6736e-07 LOCKING 3.2079e-07 MAYBE LOCKED
3.47505e-07 TRY TO LOCK 3.73173e-07 LOCKING
4.26603e-07 MAYBE LOCKED 4.53318e-07 LOCKED! Go
Bears! 4.72774e-06
89
Metropolis design environment
Meta model compiler
Front end
...
Back end1
Back endN
Back end3
Back end2
90
Backend Point Tools

• Synthesis/refinement
• 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

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.

92
Acknowledgments

• PARADES EEIG
• Prof. A.S.Vincentelli
• L.Mangeruca, M.Baleani
• UCB Alessandro Pinto and the Metropolis Team
• http//www.gigascale.org/metropolis/index.html