System Design&Methodologies
Fö 5- 1
System Design&Methodologies
Fö 5- 2
Petri Nets
Petri Nets
☞ Systems are specified as a directed bipartite graph.
The two kinds of nodes in the graph:
1. Basic Petri Net Model
1. Places: they hold the distributed state of the system expressed by the presence/absence of tokens in the
places.
2. Properties and Analysis of Petri Nets
2. Transitions: denote the activity in the system
3. Extended Petri Net Models
☞ The state of the system: captured by the marking of the places
(number of tokens in each place)
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 3
System Design&Methodologies
Fö 5- 4
Petri Net Example
Petri Nets (cont’d)
A producer and a consumer process communicating through a buffer:
☞ The dynamic evolution of the system: determined by the firing
process of transitions.
• A transition may fire whenever all its predecessor places are
marked.
prod.
rec.
prod.
B
send
rec.
prod.
B
cons.
send
rec.
B
cons.
send
cons.
• If a transition fires it removes a token from each predecessor
place and adds a token to each successor place.
prod.
rec.
prod.
B
send
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
cons.
rec.
prod.
B
send
cons.
rec.
B
send
cons.
System Design&Methodologies
Fö 5- 5
System Design&Methodologies
Fö 5- 6
Petri Net Example (cont’d)
Petri Net Example (cont’d)
Continuation from previous slide:
Continuation from previous slide:
prod.
prod.
rec.
prod.
rec.
B
B
rec.
B
prod.
rec.
prod.
B
send
cons.
send
cons.
prod.
rec.
B
send
prod.
rec.
B
cons.
send
rec.
B
cons.
cons.
send
cons.
send
cons.
☞ Notice that the buffer is considered to be infinite (tokens can
accumulate in place B).
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 7
System Design&Methodologies
Petri Net Example (cont’d)
prod.
rec.
B
prod.
rec.
B
B’
cons.
prod.
rec.
• Intuitive.
Easy to express concurrency, synchronisation, nondeterminism.
Nondeterminism is an important difference between Petri nets and
dataflow!
B
B’
send
Fö 5- 8
Some Features and Applications of Petri Nets
Here we have the same model as on the previous slides, but with
limited buffer. The buffer size is three (number of initial tokens in B’)
cons.
B’
send
• As an uninterpreted model, Petri Nets can be used for several,
very different classes of problems.
cons.
• Nr. of tokens in B’: how many free slots are available in the buffer;
- Uninterpreted model: nothing has to be specified related to the
particular activities associated to the transitions.
• Nr. of tokens in B: how many messages (tokens) are in the buffer.
Total number of tokens in B and B’ is constant.
Petru Eles, IDA, LiTH
rec.
B
cons.
send
Petru Eles, IDA, LiTH
send
prod.
cons.
send
send
prod.
rec.
B
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 9
System Design&Methodologies
Fö 5- 10
Properties and Analysis of Petri Nets
Some Features and Applications of Petri Nets (cont’d)
• Petri Nets have been intensively used for modeling and analysis of
industrial production systems, information systems, but also
☞ Several properties of the system can be analysed using Petri nets:
- Computer architectures
• Boundedness: the number of tokens in a certain place does not
exceed a given limit.
If this limit is 1, the property is sometimes called safeness.
- Operating systems
- Concurrent programs
- You can check that available resources are not exceeded.
- Distributed systems
- Hardware systems
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 11
System Design&Methodologies
Properties and Analysis of Petri Nets (cont’d)
• Liveness:
- A transition t is called live if for every possible marking there exists a chance for that transition to become enabled.
The whole net is live, if all its transitions are live.
- liveness is important in order to check that a system is not
deadlocked.
• Reachability: given a current marking M of the net, and another
marking M’, does there exist a sequence of transitions by which M’
can be obtained?
- You can check that a certain desired state (marking) is reached.
- You can check that a certain undesired state is never reached.
Properties and Analysis of Petri Nets (cont’d)
Mathematical tools are available for analysis of Petri Nets.
The properties discussed above can be formally verified.
☞ Petri nets (like dataflow systems) are asynchronous concurrent.
• Events can happen at any time.
• There exists a partial order of events:
Petru Eles, IDA, LiTH
Fö 5- 12
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 13
System Design&Methodologies
Extended Petri Net Models (cont’d)
Extended Petri Net Models
value time-stamp
Basic Petri Net models have a limited expressive power.
(2, 0)
(5, 0)
☞ Timed Petri Nets
- Transitions have associated times (time intervals)
- Tokens are carrying time stamps.
x
[1, 5]
(2, 0)
x
y
2×x
[2, 7]
y+3
[1, 5]
x
y
2×x
[2, 7]
y+3
[1, 5]
(10,2)
• With timed Petri nets we can model the timing aspects
x y
y+x
☞ Coloured Petri Nets
- Tokens have associated values
- Transitions have associated functions
x
[1, 3]
• Coloured Petri Nets are similar to dataflow models (but also
capture nondeterminism!).
Petru Eles, IDA, LiTH
x>0
x-3
y
2 ×x
(10,2)
x y
[2, 2]
y+x
y
x
[2, 4]
y+2
[1, 3]
x>0
x-3
Fö 5- 15
(5, 4)
x y
[2, 2]
y+x
y
x
[2, 4]
y+2
[1, 3]
x>0
x-3
System Design&Methodologies
Extended Petri Net Models (cont’d)
x
y
[2, 4]
y+2
2 ×x
[2, 7]
y+3
[1, 5]
2×x
[2, 7]
y+3
x y
[2, 2]
y+x
Fö 5- 16
• Extended Petri Nets have a larger expressive power then classical
Petri Nets.
y
x y
[2, 2]
Analysis is more complex; the formal analysis of properties can take
unacceptably large amounts of time (memory).
(15,6)
x
x>0
x-3
y
x
[2, 4]
y+2
[1, 3]
x>0
x-3
y
[2, 4]
y+2
• Simulation of the Petri Net can be used in order to verify the
system and to estimate performance
(17,8)
Petru Eles, IDA, LiTH
[2, 2]
Extended Petri Net Models (cont’d)
x
y
y+x
[1, 3]
[2, 7]
y+3
Petru Eles, IDA, LiTH
System Design&Methodologies
[1, 5]
Fö 5- 14
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 17
System Design&Methodologies
Summary
Fö 5- 18
Summary (cont’d)
• Petri Nets are a mixture of dataflow and state-based model.
Places hold the distributed state of the system (represented by the
marking); transitions denote the activity of the system.
• Petri nets elegantly capture concurrency, synchronisation, and
nondeterminism.
• A large class of problems can be solved using Petri Net modelling;
system properties like boundedness, liveness, and reachability
can be formally analysed.
• Basic Petri Nets are limited in their expressive power
- in timed Petri Nets an explicit notion of time has been
introduced;
- in coloured Petri nets tokens have associated values.
• Formal reasoning about extended Petri Net models is very difficult
because of complexity issues.
Simulation of the models is often used for system validation.
• Petri nets, like dataflow, are asynchronous, concurrent models.
Events can happen at any time; there exists a partial order of
events.
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 19
System Design&Methodologies
Discrete Event Models
Fö 5- 20
Discrete Event Models
1. What Is a Discrete Event Model?
• The system is a collection of processes that respond to events.
2. Discrete Event Simulation
• Each event carries a time-stamp indicating the time at which the
event occurs.
• Time-stamps are totally ordered.
3. Efficiency of Discrete Event Simulation
4. Potential Ambiguities in Discrete Event Simulation
Petru Eles, IDA, LiTH
• A Discrete Event (DE) simulator maintains a global event queue
sorted by the time-stamps. The simulator also keeps a single
global time.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 21
System Design&Methodologies
Discrete Event Simulator
time1
ev_name
value
time2
ev_name
value
ev_name
value
Discrete Event Simulator (cont’d)
ev_name
value
Any events
left?
Yes
Global clock
ev_name
value
timei
. . . . .
wait on S1
. . . . .
S3 <= ...
ev_name
value
Process P2
This event will be
generated and placed
into the event queue
at time tglobal_clock + 2
S1
5
. . . . .
S1<=5 after 2s
. . . . .
wait on S3
Process P1
Petru Eles, IDA, LiTH
No
Advance global clock to tcurrent, the time-stamp
of the earliest event(s) in the event queue.
Simulation
done!
Update the values of all events having time-stamp = tcurrent.
Activate and run all processes which are sensible to
the updated events; each process will eventually reach
a wait for a certain event and enter a wait state.
The activated processes have generated new events;
place these events at their right place in the event queue.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 23
System Design&Methodologies
☞ Efficient way to simulate distributed systems.
In general, efficient for large systems with autonomous components,
with relatively large idle times. Systems with non-regular, possibly
long times between different activities.
Why is this the case?
Because DE simulation will only consider the particular times when a
change in the system (an event) occurs. This is opposed to, for
example, cycle-based models, where all clock-ticks are considered.
Fö 5- 24
Discrete Event Simulation (cont’d)
Discrete Event Simulation
☞ The discrete event model has been mainly used for system
simulation.
• Several languages have been developed for system modeling
based on the discrete event model. Most well known:
- VHDL, Verilog (both used for hardware modeling), SystemC
Petru Eles, IDA, LiTH
Fö 5- 22
☞ Efficiency related problems:
• Keeping the sorted event-queue is time-consuming.
• As the activity of the simulated system increases (a lot of
events at a very high number of time moments have to be
considered) the overhead becomes high  simulation is slow.
☞ Event driven models are primarily employed for simulation.
• Functional verification
• Performance evaluation
☞ Both synthesis and formal verification are very difficult (complex)
with DE models.
- The classical trade-off between expressive power and the
possibility of formal reasoning and efficient synthesis.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 25
System Design&Methodologies
A Problem with Discrete Event Simulation
Fö 5- 26
A Problem with Discrete Event Simulation (cont’d)
☞ Have a look at the diagram in slide 22: In the third step we have
“Activate and run all processes which are sensible to the updated
events.”
• If we have a set of several such processes ready to run, in which
order should they be activated?
The only acceptable answer: The order should not matter;
whatever the order, the simulation result has to be the same!
Otherwise, different simulators might provide different
simulation outputs for the same model!
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
Process A
wait on S1
. . . . . . .
S2<=18 after 10
. . . . . . .
S1
100
S2
0
Initial values
At time 10 Process A executes
15
S1
5
At time 15
Process B
. . . . . . .
wait on S1,S2
. . . . . . .
S1
5
S2
0
Processes B and C are ready to execute
Process C
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 27
System Design&Methodologies
A Problem with Discrete Event Simulation (cont’d)
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
Scenario 1
B first, then C
A Problem with Discrete Event Simulation (cont’d)
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
• B executes, S1=5, S2=0, t=15
Process A
wait on S1
. . . . . . .
S2<=18 after 10
. . . . . . .
Process B
. . . . . . .
wait on S1,S2
. . . . . . .
Process C
Petru Eles, IDA, LiTH
Process A
25
S2
18
• C executes, S1=5, S2=0, t=15
At time 25
S1
5
S2
18
• C executes, S1=5, S2=18, t=25
Fö 5- 28
wait on S1
. . . . . . .
S2<=18 after 10
. . . . . . .
Process B
. . . . . . .
wait on S1,S2
. . . . . . .
Process C
Petru Eles, IDA, LiTH
Scenario 2
C first, then B
• C executes, S1=5, S2=0, t=15
• B executes, S1=5, S2=0, t=15
25
S2
18
At time 25
S1
5
S2
18
• C executes, S1=5, S2=18, t=25
The two scenarios are identical!!! How fine!!!
System Design&Methodologies
Fö 5- 29
System Design&Methodologies
A Problem with Discrete Event Simulation (cont’d)
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
Process A
S1
100
We have changed
the example!
No after clause!
S2
0
A Problem with Discrete Event Simulation (cont’d)
Initial values
At time 10 Process A executes
wait on S1
. . . . . . .
S2<=18
. . . . . . .
At time 15
Process B
. . . . . . .
wait on S1,S2
. . . . . . .
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
Process A
wait on S1
. . . . . . .
S2<=18
. . . . . . .
S1
5
15
Scenario 1
B first, then C
• B executes, S1=5, S2=0, t=15
S1
5
15
S2
18
Process B
S1
5
S2
0
Processes B and C are ready to execute
Process C
. . . . . . .
wait on S1,S2
. . . . . . .
S1
5
S2
18
• C executes, S1=5, S2=18, t=15
Process C
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 31
System Design&Methodologies
A Problem with Discrete Event Simulation (cont’d)
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
Process A
wait on S1
. . . . . . .
S2<=18
. . . . . . .
Scenario 2
C first, then B
• C executes, S1=5, S2=0, t=15
• B executes, S1=5, S2=0, t=15
S1
5
15
S2
18
Process B
. . . . . . .
wait on S1,S2
. . . . . . .
Process C
Petru Eles, IDA, LiTH
Fö 5- 30
S1
5
Fö 5- 32
A Problem with Discrete Event Simulation (cont’d)
☞ We get into this problem due to the zero delay assignment to S2 in
Process B! The new event is queued at the current simulation time
(15), which leads to the potential ambiguity.
• Such an ambiguity creates problems. For example, different
simulators will produce different output for the same model with
identical inputs.
☞ A possible solution (used, for example, in VHDL and SystemC):
A zero delay event will be registered at a time which is
infinitesimally delayed relative to the current time.
S2
18
• C executes, S1=5, S2=18, t=15
The two scenarios are different!!! How bad!!!
A “delta delay” will be introduced on the event  the new event will
be consumed in the following simulation cycle and not the current
one.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 33
System Design&Methodologies
A Problem with Discrete Event Simulation (cont’d)
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
Process A
S1
100
S2
0
A Problem with Discrete Event Simulation (cont’d)
Initial values
At time 10 Process A executes
wait on S1
. . . . . . .
S2<=18
. . . . . . .
15
. . . . . . .
wait on S1,S2
. . . . . . .
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
At time 15
• B executes, S1=5, S2=0, t=15
Process B
S2
0
Processes B and C are ready to execute
Process C
Scenario 1
B first, then C
Process A
wait on S1
. . . . . . .
S2<=18
. . . . . . .
S1
5
Process B
S1
5
Fö 5- 34
. . . . . . .
wait on S1,S2
. . . . . . .
15(+δ)
S2
15
• C executes, S1=5, S2=0, t=15
At time 15(+δ)
S1
5
S2
18
• C executes, S1=5, S2=18, t=15(+δ)
Process C
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 5- 35
System Design&Methodologies
A Problem with Discrete Event Simulation (cont’d)
. . . . . . .
S1<= 5 after 5
. . . . . . .
wait ...
Process A
wait on S1
. . . . . . .
S2<=18
. . . . . . .
Scenario 2
C first, then B
• C executes, S1=5, S2=0, t=15
• B executes, S1=5, S2=0, t=15
15(+δ)
S2
18
Fö 5- 36
Summary
• Discrete Event is a very powerful modelling technique, in terms of
expressive power.
Models are concurrent and asynchronous.
The timing model is also very general. Delays on computation or
communication can be arbitrary.
• We pay for the large expressive power by the reduced potential of
formal reasoning and efficient synthesis.
Discrete event models are mainly used for simulation.
At time 15(+δ)
Process B
. . . . . . .
wait on S1,S2
. . . . . . .
Process C
Petru Eles, IDA, LiTH
S1
5
S2
18
• Simulation is based on maintaining a unique, sorted event queue.
This can create problems with simulation efficiency for large
system models.
• C executes, S1=5, S2=18, t=15(+δ)
The two scenarios are identical!!! How fine!!!
• In order to avoid problems with zero delay computations, “delta
delays” are used (e.g. in VHDL).
Petru Eles, IDA, LiTH