Verifica di Strutture a Bus con Modular Time Petri Nets

UNIVERSITA DEGLI STUDI DI FIRENZE
Facolta di Ingegneria - Dipartimento di Sistemi e informatica
Tesi di laurea in Ingegneria Elettronica
Verifica di Strutture a Bus con
Modular Time Petri Nets
Candidato
Marco Lusini
Relatori
Prof. Giacomo Bucci
Prof. Alberto Del Bimbo
Correlatore
Ing. Enrico Vicario
Anno Accademico 1996{1997
A mio nonno Oris.
Firenze, 14 luglio 1995
Indice
1 Introduzione
2 Modular Time Petri Net
2.1 Time Petri Net . . . . . . . . . .
2.1.1 Descrizione formale . . . .
2.1.2 Un esempio . . . . . . . .
2.2 Communicating Time Petri Net .
2.2.1 Descrizione formale . . . .
2.2.2 Required Interface . . . .
2.2.3 Provided Interface . . . .
2.2.4 Un esempio . . . . . . . .
2.3 Modular Time Petri Net . . . . .
2.3.1 Descrizione formale . . . .
2.3.2 Un esempio . . . . . . . .
3 Analisi di MTPN
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.1 Classi di stati e Domini di esecuzione . . . . . . . .
3.2 Costruzione del grafo degli stati . . . . . . . . . . .
3.2.1 Dominio ristretto . . . . . . . . . . . . . . .
3.2.2 Algoritmo di costruzione . . . . . . . . . . .
3.3 Integrazione dei gra . . . . . . . . . . . . . . . . .
3.3.1 Calcolo dello stato successore . . . . . . . .
3.3.2 Calcolo del dominio di esecuzione . . . . . .
3.3.3 Errori di integrazione . . . . . . . . . . . .
3.3.4 Veri ca delle interfacce attese . . . . . . . .
3.4 Analisi temporale . . . . . . . . . . . . . . . . . . .
3.4.1 Traccia di esecuzione . . . . . . . . . . . . .
3.4.2 Algoritmo di stima a stato singolo . . . . .
3.4.3 Algoritmo di stima a stato globale . . . . .
3.5 Costruzione di interfacce oerte . . . . . . . . . . .
3.5.1 Enumerazione automatica di tracce . . . . .
3.5.2 Algoritmo per il calcolo di interfacce oerte
3.6 Esempi . . . . . . . . . . . . . . . . . . . . . . . . .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4
4
5
7
8
9
11
13
15
18
19
22
24
24
25
25
25
26
26
27
27
28
28
29
29
30
31
32
33
34
4 Modellazione di Bus con MTPN
4.1 I Bus nei sistemi a microprocessore . . . . . . . . . . . . .
4.1.1 Speci ca del protocollo di un bus . . . . . . . . . .
4.2 Modellazione dei componenti di un bus . . . . . . . . . . .
4.2.1 Segnali di controllo per il trasferimento dati . . . .
4.2.2 Segnali di controllo per l' accesso al bus . . . . . .
4.2.3 Segnali di interruzione . . . . . . . . . . . . . . . .
4.2.4 Segnali ausiliari . . . . . . . . . . . . . . . . . . . .
4.3 Un' esempio: il bus VME . . . . . . . . . . . . . . . . . .
4.3.1 Descrizione dei segnali del bus VME . . . . . . . .
4.3.2 Funzionamento del bus VME . . . . . . . . . . . .
4.3.3 Il protocollo per il trasferimento dati nel bus VME
4.3.4 Il protocollo per l' arbitraggio nel bus VME . . . .
5 Sistema software
5.1 Le classi implementate . . . . . . .
5.1.1 Classi base . . . . . . . . .
5.1.2 Classi dei gra degli stati .
5.1.3 Classi di analisi . . . . . . .
5.2 Documentazione delle Classi . . . .
5.3 Un esempio d' uso . . . . . . . . .
5.3.1 Listato di testpgSTRS.cpp
5.3.2 Listato di testigBUS.cpp .
Conclusioni
Bibliography
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
43
45
45
49
54
54
58
58
60
61
65
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 70
. 70
. 71
. 72
. 72
. 103
. 103
. 108
70
117
118
iii
Elenco delle gure
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Il modello TPN di un protocollo stop and wait . . . . .
Rappresentazione modulare del protocollo di Stenning .
Il modulo source del protocollo di Stenning . . . . . . .
Il modulo TX del protocollo di Stenning . . . . . . . . .
Il modulo RX del protocollo di Stenning . . . . . . . . .
Il modulo sink del protocollo di Stenning . . . . . . . . .
Modello di due processi in competizione per una risorsa
Modello del monitor della risorsa . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
15
15
16
17
18
22
22
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
Algoritmo di generazione del grafo degli stati . . . . . . . . . .
Algoritmo di stima a stato singolo . . . . . . . . . . . . . . . .
Algoritmo di stima a stato globale . . . . . . . . . . . . . . . .
Algoritmo di enumerazione automatica delle tracce . . . . . . .
Algoritmo di calcolo delle interfacce oerte . . . . . . . . . . .
Grafo del modello del protocollo stop and wait . . . . . . . . .
Grafo del modello della sorgente nel protocollo di Stenning . .
Grafo del modello della destinazione nel protocollo di Stenning
Grafo del modello del trasmettitore nel protocollo di Stenning .
Grafo del modello del ricevitore nel protocollo di Stenning . . .
Grafo dell' integrazione tra source e TX . . . . . . . . . . . . .
Grafo dell' integrazione tra RX e sink . . . . . . . . . . . . . .
Grafo del modello del protocollo di Stenning . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
26
30
32
33
34
35
36
36
37
38
39
40
41
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
Trasferimento di dati sincrono . . . . . . . . . . . . . . . . . . .
Modello di un trasferimento di dati sincrono . . . . . . . . . . .
Trasferimento di dati asincrono . . . . . . . . . . . . . . . . . .
Modello di un trasferimento di dati asincrono non-interlocking .
Modello di un trasferimento di dati asincrono half-interlocking .
Modello di un trasferimento di dati asincrono fully-interlocking
Trasferimento di dati semisincrono . . . . . . . . . . . . . . . .
Modello di un trasferimento di dati semisincrono . . . . . . . .
Arbitraggio seriale del bus con due linee . . . . . . . . . . . . .
Modello di accesso al bus seriale a due linee . . . . . . . . . . .
Arbitraggio seriale del bus con tre linee . . . . . . . . . . . . .
Modello di accesso al bus seriale a tre linee . . . . . . . . . . .
Arbitraggio del bus tramite richieste indipendenti . . . . . . . .
Modello di accesso al bus tramite richieste indipendenti . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
47
47
48
48
49
50
50
52
53
53
54
55
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
Interruzioni tramite richieste indipendenti . . . . . . . . . . . . .
Modello di interruzioni tramite richieste indipendenti . . . . . . .
Interruzioni vettorizzate . . . . . . . . . . . . . . . . . . . . . . .
Modello di interruzioni vettorizzate . . . . . . . . . . . . . . . . .
Modello di lettura di un byte nel bus VME . . . . . . . . . . . .
Modello del modulo di controllo del trasferimento dati su bus VME
Modello del modulo master nel trasferimento dati su bus VME .
Modello del modulo slave nel trasferimento dati su bus VME . .
Modello dell' arbitraggio del bus VME . . . . . . . . . . . . . . .
Modello del modulo di controllo dell' arbitraggio del bus VME .
Modello del modulo master nell' arbitraggio del bus VME . . . .
Modello parziale del modulo arbitro del bus VME . . . . . . . .
56
56
56
57
61
62
63
64
65
66
67
68
5.1 Grafo delle classi . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
v
Capitolo 1
Introduzione
Un sistema su bus si compone di un insieme di moduli che scambiano informazione su una struttura di comunicazione condivisa18]. E' tipicamente un
sistema complesso tramite cui avvengono trasferimenti di dati, sincronizzazioni, interruzioni, e contese per il controllo della struttura. Non esistendo una
sequenza pre ssata di eventi, ne una pre-ordinata sequenzializzazione delle azioni compiute nei singoli moduli, la composizione di tutte queste attivita risulta
in un comportamento sequenziale di cui non e possibile avere una percezione
esaustiva al momento della progettazione, e di cui e dicile eseguire una analisi
nella fase di validazione del progetto.
La simulazione e il modo comune con cui viene arontato il problema. Per
simulazione e possibile compiere una fase di testing nella quale il comportamento del sistema e osservato in corrispondenza di appropriate sequenze di ingressi.
Tuttavia, per eetto della molteplicita di cammini dovuti alle inerenti caratteristiche di parallelismo e concorrenza, questo approccio risulta estremamente
oneroso, e, in ogni caso, non permette l' accertamento esaustivo della correttezza ma solo l' identi cazione di errori che occorrono sui cammini di esecuzione
piu comuni1].
Nell' intento di permettere una veri ca di tipo esaustivo e stato proposto l'
impiego di tecniche di analisi formale prese a prestito dall' area dell' ingegneria
del software.
Una area in cui tali tecniche sono state applicate con successo e quella dei
cosiddetti sistemi speed-independent, ovvero quei sistemi nei quali il corretto
funzionamento deve essere garantito in maniera indipendente dalle temporizzazioni dei singoli componenti. Questa assunzione si applica a tutti quei sistemi
dove le sincronizzazioni tra i moduli passano sempre attraverso un handshaking
esplicito, senza mai fare assunzioni sul tempo impiegato dai moduli per trasmettere e ricevere dati. Un esempio classico in questo senso sono le self-timed queues
proposte per la realizzazione di architetture parallele dataow40].
In un sistema speed-independent, per la validazione del progetto e suciente
analizzare gli ordinamenti qualitativi che esistono nell' insieme delle possibili
esecuzioni del sistema, analizzando le possibili sequenzializzazioni tra eventi
senza considerare quantitativamente il tempo che intercorre tra essi. Tra le
varie tecniche proposte per questo tipo di analisi, un ruolo di prima rilevanza e
1
CAPITOLO 1. INTRODUZIONE
quello delle cosiddette tecniche di model checking, sia per la maturita acquisita
che per la applicabilita a casi di complessita realistica. Brevemente, l' approccio
puo essere descritto in tre passi:
il sistema sottoposto a veri ca viene rappresentato nella forma di un
modello a stati16]23]
i requisiti di correttezza sono espressi nella forma di predicati di Logica Temporale combinando espressioni logiche Booleane classiche con
operatori di sequenzializzazione temporale8]
un algoritmo, detto di model checking, veri ca in maniera automatica
se le asserzioni di Logica Temporale sono soddisfatte dal Diagramma di
Transizione15].
Nell' ultimo decennio, questo approccio ha raggiunto una sostanziale maturita
attraverso lo sviluppo di: (a) notazioni e tecniche di analisi di raggiungibilita
in grado di rappresentare un sistema attraverso un modello a stati (b) Logiche
Temporali adatte ai diversi contesti di applicazione e (c) algoritmi di modelchecking in grado di analizzare in modo eciente sistemi no all' ordine dei 107
stati e oltre21].
Purtroppo, un tale approccio non risulta applicabile all' analisi dei cosiddetti sistemi tempo-dipendenti, nei quali la correttezza del funzionamento dipende
in modo esplicito dalle temporizzazioni dei suoi componenti. Questo e il caso di
una vasta maggioranza dei sistemi a bus. In tali sistemi, assunzioni sulle temporizzazioni dei moduli sono comunemente considerate con il ne di sempli care
l' handshaking tra i componenti e ottimizzare la prestazione del sistema18].
Per l' analisi di sistemi tempo-dipendenti e stata proposta l' opportunita
di de nire tecniche di model checking in grado di tenere conto non solo della sequenzializzazione qualitativa che interviene tra le azioni del sistema, ma
anche del tempo quantitativo che intercorre tra esse. In questo intento, sono
state proposte in letteratura diverse Logiche Temporali real-time con vincoli
quantitativi sul tempo tra gli eventi20], notazioni capaci di esprimere modelli
a stati con vincoli temporali quantitativi20]6], e tecniche di analisi di raggiungibilita in grado di generare lo spazio degli stati temporizzati di un sistema. In
questo ambito, due tecniche di maggiore rilevanza sono state proposte per l'
enumerazione dello spazio degli stati di modelli espressi come macchine a stati
temporizzate6]4] o come Time Petri Nets32]31].
In particolare, usando modelli Time Petri Nets, la sincronizzazione fra le
azioni e espressa in funzione di un insieme di pre e post-condizioni che sono
associate separatamente con le singole azioni del sistema, e i vincoli di temporizzazione sono espressi nella forma di tempi minimi e massimi che intercorrono tra l' istante in cui una azione e abilitata e quello in cui l' azione viene
eseguita. Questo facilita la progettazione del modello permettendone una rappresentazione compatta che modella direttamente le condizioni di concorrenza
e parallelismo senza richiedere l' enumerazione esplicita degli stati globali del
sistema.
2
CAPITOLO 1. INTRODUZIONE
Per l' analisi di raggiungibilita di modelli Time Petri Net e stata proposta
una tecnica esaustiva che enumera classi di stati, ciascuna delle quali colleziona
una in nita densa di stati con diverse temporizzazioni9]. Tale tecnica e stata
estesa in senso composizionale in 45]13] per permettere l' analisi di sistemi
modulari complessi.
Il modello modulare proposto in 13] considera la modellazione di sistemi software dove la comunicazione si basa su meccanismi di message passing.
Questo non basta per la modellazione di sistemi hardware dove la comunicazione segue una semantica diversa: un modulo genera un segnale e gli altri lo
condividono in lettura.
Abbiamo quindi esteso la semantica del modello in modo da aderire ai requisiti espressivi incontrati nella modellazione di architetture a bus, fornendo al
modello la possibilita di comunicare tramite segnali accessibili da piu moduli,
ed allo stesso tempo mantenendo inalterate le possibilita di analisi esaustiva
esposte in 13].
Abbiamo implementato le tecniche di analisi del modello esteso in un sistema
software, realizzando cos un nucleo di analisi che permette la generazione composizionale dello spazio degli stati e la valutazione di pro li di temporizzazione
per le possibili sequenze di esecuzione del modello.
A veri ca dell' espressivita del modello esteso abbiamo provato la sua capacita espressiva nella modellazione dei meccanismi basilari incontrati nella
progettazione di bus per microcomputer e come caso concreto di applicazione
e stato modellato ed analizzato il bus VME di Motorola.
Organizzazione del lavoro
Nel capitolo 2 vengono introdotte le Modular Time Petri Net come evoluzione delle Time Petri Net e delle Communicating Time Petri Net. Per
ciascuna di tali classi di reti viene fornita una descrizione formale e viene
discusso un semplice esempio.
Nel capitolo 3 le tecniche proposte in 9] e 13] sono estese in modo da
permettere l' analisi di modelli Modular Time Petri Net. Per ciascuna
tecnica viene fornito un algoritmo di implementazione. La descrizione e
esempli cata attraverso l' analisi delle reti del capitolo 2.
Nel capitolo 4 le Modular Time Petri Net sono applicate alla modellazione
di tutti i meccanismi di comunicazione e sincronizzazione che concorrono
al funzionamento di una generica architettura a bus per microcomputer.
Questo permette di veri care l' adeguatezza della espressivita del modello
proposto. Come caso di studio concreto viene considerato il bus VME di
Motorola. Di questo viene fornita una descrizione generale ed un modello
Modular Time Petri Net dei meccanismi di arbitraggio e di trasferimento
dati.
Nel capitolo 5 vengono illustrati i principi di organizzazione del sistema
software che implementa le tecniche di analisi descritte, e viene fornita
una documentazione estensiva delle classi che lo compongono.
3
Capitolo 2
Modular Time Petri Net
2.1 Time Petri Net
Le reti di Petri3]33]36] permettono di modellare attivita concorrenti e parallele, rappresentandole sotto forma di un insieme di regole di pre e post condizioni.
Una rete di Petri (Petri Net) e un grafo orientato composto da due tipi di nodi:
le piazze (place) e le transizioni (transition). Transizioni e piazze sono collegate
da archi che possono essere di due tipi:
Arco di pre-condizione: collega una piazza ad una transizione. La piazza
e detta di ingresso per la transizione.
Arco di post-condizione: collega una transizione ad una piazza. La piazza
e detta di uscita per la transizione.
Una piazza e un accumulatore di gettoni (token), gettoni che servono ad abilitare l' esecuzione delle transizioni e che sono spostati proprio da tali esecuzioni.
Una transizione e abilitata (enabled) se tutte le sue piazze di ingresso contengono almeno un gettone e nessuna delle sue piazze di inibizione contiene dei
gettoni. Una transizione abilitata puo eseguire (re) e nell' esecuzione rimuove
un gettone da ogni piazza di ingresso e ne aggiunge uno ad ogni piazza di uscita.
Dopo una esecuzione, le transizioni abilitate possono essere persistenti (persistent) o appena abilitate (newly enabled), a seconda che siano rimaste sempre
abilitate durante le fasi di rimozione ed aggiunta di gettoni, oppure siano state
abilitate durante una di queste fasi1 .
Per permettere di esprimere relazioni di priorita tra le transizioni del modello, si estende il modello originale con l' aggiunta di un terzo tipo di arco33]:
Arco di inibizione: collega una piazza ad una transizione. La piazza e
detta di inibizione per la transizione.
Una rete di Petri consente di modellare molto bene processi con vincoli di
sincronizzazione e mutua esclusione, ma non considera in alcun modo il tempo.
Tutto quello che il modello dice di una transizione in un certo stato e che prima
1
Una transizione che dopo la propria esecuzione e ancora abilitata viene considerate appena
abilitata.
4
CAPITOLO 2. MODULAR TIME PETRI NET
o poi esegue oppure che non esegue mai, senza dare indicazioni precise sull'
eettivo tempo all' esecuzione (time to re) della transizione.
Per aggiungere espressivita al modello e renderlo capace di catturare vincoli sui tempi massimi e minimi di esecuzione, sono state introdotte le Time
Petri Net (TPN). Queste aggiungono al modello base dei vincoli sul tempo di
esecuzione delle transizioni una volta che queste sono innescate, imponendo che
una transizione non possa eseguire prima che sia passato un tempo minimo eft
(earliest ring time) da quando e stata abilitata e che non possa rimanere abilitata per piu di un tempo massimo lft (latest ring time) senza eseguire. Alla
coppia di tempi eft,lft] viene dato il nome di intervallo di esecuzione (ring
interval). Per tenere in conto questi vincoli, lo stato di una TPN associa ad ogni
transizione una coppia di variabili di stato, l' intervallo di esecuzione dinamico,
ed una coppia di costanti, l' intervallo di esecuzione statico. L' intervallo di esecuzione dinamico viene resettato al valore dell' intervallo statico ogni volta che
la transizione viene abilitata e viene poi ridotto al passare del tempo. In ogni
istante l' intervallo di esecuzione dinamico rappresenta il minimo ed il massimo
del tempo all' esecuzione della transizione.
2.1.1 Descrizione formale
Sintassi
Una Time Petri Net e una 4-tupla
TPN =< P T A FI s >
dove:
P e l' insieme delle piazze della rete.
T e l' insieme delle transizioni della rete.
A e l' insieme degli archi di pre-condizione, post-condizione ed inibitori:
A (P T ) (T P )
FI s e la relazione che associa ad ogni transizione il suo intervallo di
esecuzione statico EFT s ,LFT s]:
FI s : T ! R+ (R+ f1g)
Semantica
Il comportamento dinamico di una TPN e rispecchiato nei cambiamenti che
avvengono nello stato della rete al passare del tempo ed all' esecuzione delle
transizioni.
Lo stato della rete e una una coppia
S =< M FI d >
dove:
5
CAPITOLO 2. MODULAR TIME PETRI NET
M e la funzione marcamento (marking) che associa ad ogni piazza il
numero (non negativo )di gettoni che contiene:
M : P ! N+
FI d e la relazione che associa ad ogni transizione il suo intervallo di
esecuzione dinamico EFT d ,LFT d ]:
FI s : T ! R+ (R+ f1g)
La rete si evolve nel tempo in accordo con le seguenti regole che stabiliscono
quali sono le transizioni eseguibili e quali sono i cambiamenti che l' esecuzione
di una transizione comporta nello stato S :
Eseguibilita: una transizione t0 e abilitata se tutte le sue piazze di ingresso
contengono almeno un gettone e nessuna delle sue piazze di inibizione
contiene dei gettoni. Una transizione t0 abilitata e eseguibile se il suo
EFT d e minore del LFT d di ogni altra transizione nello stato S .
Progresso: qualunque transizione t0 eseguibile nello stato S puo eseguire
con un tempo di esecuzione (t0 ) che deve essere maggiore dell' EFT d di
t0 stessa e deve essere minore del LFT d di qualunque altra transizione
abilitata.
Esecuzione: quando la transizione t0 esegue, si deve calcolare il nuovo stato della rete, il che comporta calcolare il nuovo marcamento delle piazze
ed aggiornare gli intervalli dinamici di esecuzione. Quest' ultima operazione avviene in maniera diversa per le transizioni persistenti e per quelle
appena abilitate:
1. si rimuove un gettone da tutte le piazze di ingresso per t0 .
2. si aggiunge un gettone a tutte le piazze di uscita per t0 .
3. per ogni transizione appena abilitata si resetta l' intervallo di esecuzione dinamico al suo valore statico:
EFT d := EFT s
LFT d := LFT s
0
0
4. per ogni transizione persistente si trasla a sinistra l' intervallo di
esecuzione del valore del tempo all' esecuzione (t0 ) con cui esegue
t0 :
EFT d := maxf0 EFT d ; (t0 )g
LFT d := maxf0 LFT d ; (t0 )g
0
0
Tutti i passi sopra elencati sono eseguiti in maniera atomica.
6
CAPITOLO 2. MODULAR TIME PETRI NET
t6 2 4]
t0
2 4]
P0 t1
16 16]
P1
t2
0 0]
t7
P2
t3 2 4] P4
P3
t5 2 4] P5
t4 2 4]
0 0]
P6
P7
t8
1 2]
Figura 2.1. Il modello TPN di un protocollo stop and wait
2.1.2 Un esempio
Come esempio supponiamo di voler modellare un semplice protocollo di comunicazione stop and wait, in cui un trasmettitore ed un ricevitore comunicano
attraverso due canali monodirezionali non adabili: il trasmettitore manda un
pacchetto ed aspetta l' acknowledgement dal ricevitore, usando un timeout per
evitare le situazioni di blocco.
Il modello realizzato con le TPN si puo vedere in gura 2.1, in cui si distinguono i 4 elementi modellati: il trasmettitore sulla sinistra ed il ricevitore sulla
destra, uniti dai 2 canali.
Inizialmente il trasmettitore ha un gettone nella piazza P0 . Dopo un periodo
compreso tra 2 e 4 unita di tempo, il trasmettitore manda un pacchetto sul
canale (l' esecuzione della transizione t0 mette un gettone nella piazza P2 ) e
si mette in attesa della risposta (t0 mette un gettone anche nella piazza P1 ).
Quando arriva la risposta (un gettone nella piazza P3 ), il trasmettitore preleva
il pacchetto di risposta e ritorna nella condizione iniziale, pronto ad iniziare una
nuova trasmissione (l' esecuzione di t2 consuma i gettoni in P3 ed in P1 ). Se la
risposta non arriva entro 16 unita di tempo, scatta il timeout ed il trasmettitore
ritorna comunque alla condizione iniziale (la transizione t1 scatta esattamente
dopo 16 unita di tempo dall' esecuzione di t0 ).
I due canali di trasmissione sono modellati allo stesso modo, con due piazze
e due transizioni. L' arrivo di un gettone in P2 (P5 ), rappresenta la richiesta
di trasmettere un pacchetto, pacchetto che puo essere correttamente trasmesso
nella piazza P4 (P3 ) con l' esecuzione di t3 (t5 ) oppure perduto attraverso t6
(t4 ).
Il ricevitore inizialmente attende un pacchetto (ovvero un gettone nella piazza P4 ) ed il suo arrivo fa scattare la transizione t7 che preleva il pacchetto e lo
mette a disposizione del ricevitore (il gettone e ora nella piazza P7 ) che, dopo
un tempo di elaborazione compreso tra 1 e 2 unita di tempo, trasmette l' acknowledgement e ritorna nella condizione iniziale di attesa di un pacchetto (l'
esecuzione di t8 mette un gettone nelle piazze P5 e P6 ).
7
CAPITOLO 2. MODULAR TIME PETRI NET
2.2 Communicating Time Petri Net
Il principale limite all' uso delle Time Petri Net nella modellazione e veri ca
di sistemi sta nella necessita di modellare tutto il sistema con un unica rete,
senza cioe poter ricorrere a meccanismi di strutturazione che permettano di
scomporre il problema in modelli piu piccoli da veri care singolarmente per
poi comporre il risultato di tali veri che. Ad esempio, nel caso del protocollo
stop and wait di gura 2.1, si distinguono chiaramente almeno due sottosistemi
indipendenti: il trasmettitore sulla sinistra ed il ricevitore sulla destra. Le
TPN obbligano ad unire queste due entita concettualmente distinte in un unico
modello quando invece il poter analizzare indipendentemente il trasmettitore
dal ricevitore faciliterebbe il lavoro di analisi e veri ca, riducendo l' ampiezza
del sistema da studiare.
Oltre alla dicolta di modellare grossi sistemi con un' unica rete, le TPN
obbligano ad eettuare l' analisi in un unico passo, richiedendo cos anche notevoli capacita di calcolo, dato che la complessita dell' analisi da fare cresce
con la complessita delle reti da analizzare. Inoltre l' impossibilita di modellare
separatamente i singoli moduli di un sistema obbliga a ripetere l' intera fase di
validazione di tutto il modello ogni volta che si modi ca una sua parte.
Le Communicating Time Petri Net (CmTPN)13] si propongono di superare
tale limitazione sia ampliando il modello delle Time Petri Net con meccanismi
per il supporto di comunicazioni tra diverse reti, sia fornendo i necessari strumenti per l' analisi separata e la successiva composizione. Le CmTPN aggiungono alle normali TPN un meccanismo di comunicazione tramite scambio di
messaggi (message passing) tra porte di lettura e scrittura (reading e writing
port). Tali porte sono associate a piazze e transizioni, che assumono il nome di
piazze di lettura (reading place) e transizioni di scrittura (writing transition),
tramite dei legami di comunicazione (communication link). Le porte di reti
diverse possono essere unite da canali (channel) per modellare sistemi composti
da piu CmTPN collegati insieme. Nel sistema composto, i canali ed i legami
stabiliscono un collegamento tra transizioni di scrittura e piazze di lettura di
reti diverse, cos che quando scatta una transizione di scrittura, essa aggiunge
un gettone a tutte le piazze di lettura a cui e connessa, come se transizione
e piazza fossero normalmente collegate da un arco di post-condizione in una
normale rete.
Ai ni pratici, una CmTPN che usa un porta di lettura puo essere pensata
come una normale TPN cui sia stata \prestata" una transizione da parte di un
altro modulo, ovvero che tale modulo acconsenta ad esportare una sua transizione per permetterle di depositare gettoni in piazze che non sono interne al
modulo stesso. Si parlera cosi di transizioni master riferendosi alle transizioni
vere che sono esportate da un modulo, e di transizioni slave per le transizioni
di lettura che ad esse sono collegate con un canale.
Le CmTPN forniscono uno strumento molto potente per modellare sistemi di
tipo event-driven, o che a tale forma possano essere ricondotti, come ad esempio
sistemi software ad elevato parallelismo che interagiscano tra di loro tramite
meccanismi di inter process communcation, reti di comunicazione, canali di
trasmissione, ecc. Su questi modelli, le CmTPN possono veri care la presenza
8
CAPITOLO 2. MODULAR TIME PETRI NET
di deadlock, la violazione di temporizzazioni ed altre condizioni legate allo stato
del sistema in tempi ben precisi.
2.2.1 Descrizione formale
Sintassi
Una Communicating Time Petri Net e una 6-tupla
CmTPN =< P T A FI s Port Link >
dove:
P e l' insieme delle piazze della rete.
T e l' insieme delle transizioni della rete.
A e l' insieme degli archi di pre-condizione, post-condizione ed inibitori:
A (P T ) (T P )
FI s e la relazione che associa ad ogni transizione il suo intervallo di
esecuzione statico EFT s ,LFT s]:
FI s : T ! R+ (R+ f1g)
Port e l' insieme delle porte di comunicazione, ulteriormente diviso in
porte di lettura e scrittura:
Port = Portin Portout
Portin \ Portout =
Link e la relazione che associa le piazze di lettura e le transizioni di
scrittura con le relative porte di comunicazione:
Link (P Portin) (T Portout )
Le porte di lettura e scrittura di moduli diversi possono essere connesse attraverso canali singoli per formare una CmTPN composta. Se nella composizione
sono rimaste libere delle porte, queste costituiscono le porte di comunicazione
del sistema composto, che possono essere usate per continuare l' integrazione
a livelli successivi, includendo la rete composta in una nuova composizione di
modelli.
Semantica
Il comportamento dinamico delle CmTPN e praticamente quello delle Time
Petri Net, con le dovute modi che necessarie a speci care il comportamento in
modelli composti.
Lo stato di una singola CmTPN e una una coppia
s =< M FI d >
dove:
9
CAPITOLO 2. MODULAR TIME PETRI NET
M e la funzione marcamento (marking) che associa ad ogni piazza il
numero (non negativo )di gettoni che contiene:
M : P ! N+
FI d e la relazione che associa ad ogni transizione il suo intervallo di
esecuzione dinamico EFT d ,LFT d ]:
FI d : T ! R+ (R+ f1g)
Lo stato globale S della rete composta e il prodotto degli stati individuali delle
singole CmTPN che compongono la rete.
La rete globale si evolve nel tempo in accordo con le seguenti regole che
stabiliscono quali sono le transizioni eseguibili e quali sono i cambiamenti che
l' esecuzione di una transizione comporta nello stato S :
Eseguibilita: una transizione t0 appartenente ad un qualsiasi modulo N0 e
abilitata se tutte le sue piazze di ingresso contengono almeno un gettone e
nessuna delle sue piazze di inibizione contiene dei gettoni. Una transizione
t0 abilitata e eseguibile se il suo EFT d e minore del LFT d di ogni altra
transizione nello stato globale S .
Progresso: qualunque transizione t0 eseguibile nello stato S puo eseguire
con un tempo di esecuzione (t0 ) che deve essere maggiore dell' EFT d di
t0 stessa e deve essere minore del LFT d di qualunque altra transizione
abilitata in tutti i moduli del sistema.
Esecuzione: quando la transizione t0 del modulo N0 esegue, si calcola il
nuovo stato della rete con i seguenti passi (atomici):
1. si rimuove un gettone da tutte le piazze di ingresso per t0 .
2. si aggiunge un gettone a tutte le piazze di uscita per t0 .
3. si aggiunge un gettone a tutte le piazze di uscita per t0 .
4. per ogni porta di scrittura out legata a t0 e collegata attraverso un
canale ad una porta di lettura in di un modulo Nin nel sistema, si
aggiunge un gettone a tutte le piazze di Nin legate a in.
5. per ogni transizione appena abilitata si resetta l' intervallo di esecuzione dinamico al suo valore statico:
EFT d := EFT s
LFT d := LFT s
0
0
6. per ogni transizione persistente si trasla a sinistra l' intervallo di
esecuzione del valore del tempo all' esecuzione (t0 ) con cui esegue
t0 :
EFT d := maxf0 EFT d ; (t0 )g
LFT d := maxf0 LFT d ; (t0 )g
0
0
10
CAPITOLO 2. MODULAR TIME PETRI NET
2.2.2 Required Interface
Una porta di lettura di un modulo collegata ad una transizione di scrittura
di un altro modulo tramite un canale, puo essere vista come una transizione
asservita alla transizione di scrittura. Il comportamento di queste transizioni
slave e perfettamente de nito durante l' esecuzione del sistema composto, in
cui ogni transizione slave si comporta esattamente come la transizione master
cui e collegata, mentre cio non e vero durante l' analisi del singolo modulo.
Un primo approccio per analizzare un modulo singolarmente, consiste nell'
analizzarlo mentre e inserito nell' intero sistema composto, che e il suo ambiente
naturale, ma questo metodo risulta molto pesante e inoltre impedisce di usare
tecniche di validazione incrementale e di riusabilita delle analisi svolte.
Per consentire una maggiore essibilita e riusabilita dell' analisi, ed allo
stesso tempo permettere di eseguire l' analisi dei singoli moduli in maniera
completamente indipendente l' uno dall' altro, si puo dare una speci ca incompleta dell' ambiente in cui il modulo si trova, codi cando in una interfaccia
attesa (Required Interface) la risposta dell' ambiente (in termini di esecuzione
delle transizioni slave2 ) all' evoluzione del modulo.
Si puo infatti pensare che l' esecuzione di alcune transizioni (tipicamente
quelle esportate, ma non solo) provochi, dopo un certo intervallo di tempo,
delle reazioni nell' ambiente esterno, reazioni che si manifestano con l' arrivo
di un gettone da un canale di comunicazione, ovvero con l' esecuzione di una
transizione slave. La speci ca di una interfaccia attesa quindi consiste nell'
aumentare la CmTPN con delle transizioni slave e de nire come cambiano i
loro intervalli di esecuzione all' eseguire di altre transizioni della rete stessa.
Conviene sottolineare come una interfaccia attesa non de nisca i vincoli
rispettati dal modulo, ma piuttosto i vincoli che il modulo si aspetta siano
soddisfatti dall' ambiente esterno.
In questa modo si possono applicare in maniera semplice le tecniche di analisi
sviluppate per le Time Petri Net9] anche alle CmTPN, con alcune semplici
modi che alla sintassi ed alla semantica de nite nella sezione 2.1.1.
Sintassi
Una interfaccia attesa e una tripla:
Required Interface =< T in Ain FIris >
dove:
T in e l' insieme di transizioni di lettura associate alle porte di lettura del
modulo.
Ain e l' insieme di archi di post-condizione che collegano ogni transizione
di lettura tin alla piazza di lettura collegata alla porta in.
2
Il termine slave e qui usato impropriamente, poiche si puo parlare di transizioni slave solo
quando queste siano eettivamente asservite ad una transizione master tramite un canale.
11
CAPITOLO 2. MODULAR TIME PETRI NET
Fris associa ogni transizione di lettura tin con un insieme di intervalli di
esecuzione statici attesi, ognuno associato ad un' altra transizione (reale
od aggiunta) del modulo o con l' evento init che corrisponde all' inizio di
una esecuzione:
Bri T in (T T in)
FIris : Bri finitg ! (R+ f1g) (R+ f1g)
Si noti come l' EFTs di una transizione di lettura possa essere 1. Questo,
di fatto, impedisce alla transizione di eseguire, poiche prima della sua esecuzione deve passare un tempo in nito. Conviene allora, per sempli care
la lettura dei risultati dell' analisi, considerare tali transizioni disabilitate
a tutti gli eetti.
Semantica
Il comportamento dinamico di una interfaccia attesa e de nito solo in unione
al modulo cui fornisce un ambiente di evoluzione. Lo stato del sistema chiuso
formato dal modulo e da una sua interfaccia attesa e una tripla
S =< M FI d FIrid >
dove
M e la funzione marcamento (marking) che associa ad ogni piazza il
numero (non negativo) di gettoni che contiene:
M : P ! N+
FI d associa ad ogni transizione il suo intervallo di esecuzione dinamico
EFT d ,LFT d ]:
FI d : T ! R+ (R+ f1g)
FIrid associa ad ogni transizione di lettura un intervallo di esecuzione
dinamico atteso EFTrid ,LFTrid ]:
FIrid : T in ! (R+ f1g) (R+ f1g)
L' evoluzione della composizione del modulo con una interfaccia attesa avviene
fondamentalmente con le stesse regole di esecuzione date per una TPN nella
sezione 2.1.1, aumentando l' insieme delle transizioni da T a T T in . L' unica
dierenza consiste nell' aggiunta di alcune regole per assegnare alle transizioni
di lettura il giusto intervallo di esecuzione:
Inizializzazione: gli intervalli dinamici di tutte le transizioni di lettura tin
sono inizialmente assegnati al valore statico FIris (tin init).
Esecuzione: si aggiunge il seguente passo:
12
CAPITOLO 2. MODULAR TIME PETRI NET
6. per ogni transizione di lettura tin, se < tin t0 >2 Bri , tin si considera
appena abilitata e si resetta il suo intervallo di esecuzione dinamico
al valore de nito nell' interfaccia attesa:
EFTrid := EFTris (tin t0 )
LFTrid := LFTris (tin t0 )
0
0
altrimenti tin e persistente ed il suo intervallo di esecuzione viene
traslato normalmente di (t0 ):
EFTrid := maxf0 EFTrid ; (t0 )g
LFTrid := maxf0 LFTrid ; (t0 )g
0
0
Come per le transizioni normali, l' intervallo dinamico di esecuzione di una
transizione di lettura tin de nisce il minimo ed il massimo tempo che ci si
aspetta che trascorra prima della prossima esecuzione di tin . Poiche tale tempo
viene ride nito all' esecuzione di certe transizioni, gli intervalli statici delle
interfaccia attesa esprimono dei vincoli sul tempo che trascorre dall' esecuzione
di queste transizioni all arrivo di un gettone dall' ambiente. Questo tipo di
vincoli permette di esprimere le interfacce attese in termini di vincoli temporali
stimolo/risposta, adattandosi bene al tipo di speci che dei sistemi tempo-reali.
2.2.3 Provided Interface
Se le CmTPN unite alle interfacce attese forniscono un buon metodo per validare sistemi complessi in maniera modulare ed incrementale, esse non prevedono
alcun meccanismo per nascondere la complessita dei moduli analizzati e ridurre
quindi le risorse impiegate nell' analisi del sistema composto.
Per ridurre l' eccesso di informazioni prodotte nell' analisi di un modulo
completo di tutti i suoi dettagli interni, si puo cercare di nascondere le transizioni locali al modulo, fornendo del modulo stesso un modello sempli cato in
cui compaiano solo le transizioni osservabili, ovvero quelle transizioni che servono all' integrazione del modulo nel sistema composto. Di queste transizioni
si fornisce l' intervallo di tempo che passa dall' esecuzione di una qualsiasi altra
transizione osservabile alla sua esecuzione. Il modello ridotto deve essere compatibile con il modulo originale, nel senso che deve permettere tutte le esecuzioni
permesse dal modulo originale.
A questo modello ridotto si da il nome di interfaccia oerta (provided interface), poiche ore dei vincoli temporali che il modulo assicura di rispettare.
Sintassi
Una interfaccia oerta e una coppia:
Provided Interface =< T obs FIpis >
dove:
13
CAPITOLO 2. MODULAR TIME PETRI NET
T obs e l' insieme delle transizioni osservabili, composto sia da transizioni
normali che di lettura, con l' aggiunta dell' evento init che corrisponde
all' inizio dell' esecuzione:
T obs T T in finitg
Fpis associa ogni coppia di transizioni osservabili con un intervallo di
esecuzione statico oerto:
Bpi = T obs (T obs ; finitg)
FIpis : Bpi ! (R+ f1g) (R+ f1g)
Semantica
Lo stato di una interfaccia oerta e:
S =< FIpid >
in cui FIpid associa ogni elemento di T obs ad un intervallo di esecuzione dinamico:
FIpid : T obs ! (R+ f1g) (R+ f1g)
Nell' esecuzione di una interfaccia oerta, le transizioni sono sempre appena
abilitate salvo il caso in cui l' intervallo dinamico sia posto a 1 1], nel qual
caso la transizione si considera disabilitata.
L' esecuzione di una interfaccia oerta avviene tramite regole molto semplicate rispetto alle TPN, non dovendo piu considerare le piazze:
Inizializzazione: gli intervalli dinamici di tutte le transizioni osservabili to
sono inizialmente assegnati al valore statico FIpis (to init).
Eseguibilita: una transizione osservabile to e abilitata se il suo EFTpid e
minore di 1. Una transizione to abilitata e eseguibile se il suo EFTpid e
minore del LFTpid di ogni altra transizione nello stato S .
Progresso: qualunque transizione to eseguibile nello stato S puo eseguire
con un tempo di esecuzione (to ) che deve essere maggiore dell' EFTpid di
to stessa e deve essere minore del LFTpid di qualunque altra transizione
abilitata.
Esecuzione: quando la transizione osservabile tf esegue, si resettano gli
intervalli di esecuzione dinamici di ogni altra transizione osservabile to :
EFTpid := EFTpis (to tf )
LFTpid := LFTpis (to tf )
0
0
14
CAPITOLO 2. MODULAR TIME PETRI NET
ready source
data
ready
- data
ack ready ack
TX
- pkt
pkt
RX
data
ready
sink
- data
Figura 2.2. Rappresentazione modulare del protocollo di Stenning
2.2.4 Un esempio
Come esempio consideriamo ancora un protocollo di comunicazione, il cosiddetto protocollo di Stenning38], che viene spesso usato come esempio per nuovi
metodi di speci ca e validazione.
Questo protocollo considera un sistema modulare, rappresentato in gura
2.2, composto da una sorgente (source) ed una destinazione (sink) che realizzano
un canale adabile attraverso un trasmettitore (TX) ed un ricevitore (RX)
collegati da un mezzo inadabile.
Per ogni singolo modulo dovremo dare sia la descrizione interna come rete di
Petri, sia la descrizione dell' ambiente che tale modulo si aspetta per funzionare
correttamente attraverso una interfaccia attesa.
Il modulo source
P0
t0
P1
2 4]
P2
t1
0 1]
i20
Figura 2.3. Il modulo source del protocollo di Stenning
Facendo riferimento alla rete di gura 2.3, il modulo sorgente trasmette i dati
attraverso la transizione t1 , ed attende che il trasmettitore sia libero attraverso
la transizione importata i20 .
La presenza di un gettone in P0 signi ca che il modulo sta producendo un
dato da trasmettere. L' esecuzione di t0 modella la produzione del dato, dopo
di che il modulo attende che il trasmettitore sia pronto (ovvero che l' esecuzione
di i20 metta un gettone in P2 ) e trasmette il dato con l' esecuzione di t1 .
L' interfaccia attesa di tabella 2.1 dichiara che il modulo sorgente si aspetta
che un messaggio ready (i20 ) debba sempre arrivare dopo la trasmissione di data
(t1 ) e che non possano arrivare due ready di la senza un data in mezzo.
15
CAPITOLO 2. MODULAR TIME PETRI NET
init
i20
1 1 1 1
i20
t1
0 1
Tabella 2.1. L' interfaccia attesa del modulo source
Il modulo TX
t7
t8
3 6]
P8
3 6]
P3
1 2]
t3
i31
P6
P6
t4
P4
t5
1 2]
t6
P7
0 1]
16 16]
i30
Figura 2.4. Il modulo TX del protocollo di Stenning
In gura 2.4 vediamo il modulo trasmettitore, il piu complicato dei moduli
del sistema, che trasmette i pacchetti attraverso t7 , segnala la disponibilita a
trasmettere con t6 , riceve i dati da i31 e gli acknowledgement da i30 .
Un gettone in P6 signi ca che il modulo aspetta dei dati da trasmettere
in tale condizione l' arrivo di un gettone in P3 permette l' esecuzione di t3 ,
che pone un gettone in P8 e in P4 . Il gettone in P8 modella la presenza di un
pacchetto in transito nel mezzo inadabile che il modulo usa per comunicare:
il suo arrivo a destinazione e modellato dall' esecuzione di t7 , mentre la perdita
dall' esecuzione di t8 (in entrambi i casi la comunicazione dura un intervallo di
tempo compreso in 3 6]). Il gettone in P4 modella una condizione di attesa
che e terminata o dall' arrivo dell' acknowledgement (l' esecuzione di i30 che
mette un gettone in P7 ) o dallo scadere di un timeout dopo 16 unita di tempo
(l' esecuzione di t5 ). Si noti come lo scadere del timeout rilancia la trasmissione
del dato attraverso l' esecuzione di t4 e come il timeout stesso sia inibito dall'
arrivo dell' acknowledgement.
L' interfaccia attesa per il modulo di trasmissione, mostrata in tabella 2.2,
speci ca che un messaggio data (i31 ) deve sempre arrivare dopo un messaggio
ready (t6 ), che non possono arrivare due data di la senza un ready in mezzo,
che un messaggio ack (i30 ) puo venire solo dopo la trasmissione di un pkt (t7 ) e
mai immediatamente dopo un ack (i30 ) od un timeout (t5 ).
16
CAPITOLO 2. MODULAR TIME PETRI NET
i30
i31
init
i30
t5
1 1 1 1 1 1
0 1
|
|
t7
0 1
|
i31
t6
|
1 1
|
0 1
Tabella 2.2. L' interfaccia attesa del modulo TX
Il modulo RX
t9
i40
P10
0 0]
P9
t10 P11
1 3]
3 6] t11
i41
t12
3 6]
Figura 2.5. Il modulo RX del protocollo di Stenning
Il modulo ricevitore e illustrato in gura 2.5. I dati sono trasmessi tramite
t10 , t12 trasmette gli acknowledgement, mentre le transizioni importate i41 e i40
ricevono rispettivamente i pacchetti e la disponibilita del modulo destinazione
a ricevere dati.
Quando arriva un pacchetto dal mezzo inadabile (l' esecuzione di i41 deposita un gettone in P9 ), la destinazione puo essere occupata o meno: nel primo
caso la transizione t9 scarta il pacchetto arrivato, nel secondo un gettone in P10
blocca t9 e permette a t10 di trasmettere il dato. L' esecuzione di t10 trasmette
anche il pacchetto di acknowledgement al modulo trasmettitore, trasmissione
che viene come al solito modellata con la piazza P11 e le due transizioni t12 e
t11 per l' arrivo e la perdita del pacchetto stesso.
L' interfaccia attesa del modulo ricevitore e mostrata in tabella 2.3 ed aerma che un messaggio ready (i40 ) puo venire solo dopo la trasmissione di un data
(t10 ) e che non si possono avere due ready di la senza un data in mezzo inoltre
un messaggio pkt puo arrivare in qualunque momento dopo la trasmissione di
un ack (i12 ), ma tra due pkt di la devono passare almeno 10 unita di tempo.
i40
i41
init
i40
1 1 1 1
0 1
|
t10
i41
t12
0 1 |
|
| 10 1 0 1
Tabella 2.3. L' interfaccia attesa del modulo RX
17
CAPITOLO 2. MODULAR TIME PETRI NET
Il modulo sink
P13
t14
0 0]
P14
P12
t13
0 1]
i50
Figura 2.6. Il modulo sink del protocollo di Stenning
Il modello di gura 2.6 e il modulo destinazione, simile al modulo sorgente salvo
per le condizioni iniziali delle piazze. Il modulo riceve i dati da i50 e trasmette
la propria disponibilita con t14 .
Il modulo destinazione aspetta l' arrivo di un dato dalla transizione i50 ,
lo consuma tramite la transizione t13 in un intervallo di tempo 0 1], segnala
la disponibilita a ricevere nuovi pacchetti tramite t14 e torna nella condizione
iniziale.
L' interfaccia attesa del modulo destinazione, mostrata in tabella 2.4, e
analoga all' attesa degli altri moduli che scambiano data e ready: un messaggio
data (i50 ) puo arrivare solo dopo un ready (t14 ) e non possono arrivare due data
di la senza un ready in mezzo.
init
i50 0 1
i50
1 1
t14
0 1
Tabella 2.4. L' interfaccia attesa del modulo sink
2.3 Modular Time Petri Net
Le CmTPN sono strumenti molto potenti nell' analisi di sistemi in cui gli scambi tra i sottosistemi componenti avvengono con comunicazioni di tipo messagepassing. La possibilita delle CmTPN di veri care vincoli di temporizzazione
rende molto appetibile il loro uso anche nella veri ca di sistemi digitali, in cui
il rispetto delle temporizzazioni e spesso cruciale, ma tale uso e complicato dal
dover arontare un problema in cui le comunicazioni sono tipicamente basate
sulla lettura di segnali da parte dei vari sottosistemi con una metodologia fondamentalmente message passing. Sebbene la lettura di segnali presenti in un
modulo possa essere modellata con una serie di porte, piazze e transizioni opportune, il loro uso sistematico risulta troppo pesante per poter essere applicato
nella pratica.
Per risolvere tali problemi, viene proposta ora una variante originale delle CmTPN, chiamata Modular Time Petri Net, in cui si estende l' idea delle
transizioni esportate anche alle piazze, fornendo gli opportuni meccanismi per
18
CAPITOLO 2. MODULAR TIME PETRI NET
garantire la sincronizzazione tra le piazze slave e quelle master. Le aggiunte
alla struttura delle CmTPN devono essere il meno intrusive possibile, per poter
usare le tecniche di analisi sviluppate per esse senza modi che troppo pesanti.
L' idea alla base delle MTPN e che una rete che modella un sottosistema possa importare dalle altre reti del sistema tanto delle piazze che delle transizioni,
piazze e transizioni che, nel sistema composto, si comportano esattamente come le corrispettive piazze e transizioni esportate. Ovviamente per le transizioni
importate valgono le stesse considerazioni che hanno portato all' introduzione
delle interfacce attese per riprodurre il comportamento delle transizioni esportate anche in assenza del modulo cui appartengono. Per le piazze si ripete il
problema di come assicurare un comportamento \plausibile" alle piazze importate senza dover considerare nell' analisi del modulo anche le reti cui esso si
interfaccia. Inoltre, poiche le piazze importate non appartengono veramente al
modulo in esame, ma gli sono prestate, esse dovranno essere a sola lettura, cioe
non si potra consentire alle transizioni di un modulo di togliere o aggiungere
gettoni alle piazze che importa.
Il problema della sincronizzazione tra piazze master e piazze slave puo essere risolto creando tra esse un canale di comunicazione tramite cui la piazza
master comunica alla piazza slave di aggiungere o togliere un gettone quando
necessario. Un' ulteriore analisi del meccanismo con cui le due piazze restano
sincronizzate, mostra che la piazza slave deve togliere un gettone ogni volta che
nella rete di origine esegue una transizione che e di uscita per la piazza master, mentre deve aggiungerlo ogni volta che esegue una transizione di ingresso
per la piazza master. Questo suggerisce di aggiungere, nel modulo in esame,
due transizioni, una di incremento (up transition) ed una di decremento (down
transition), collegate alla piazza slave tramite archi di post e pre condizione, ed
alla rete di origine tramite collegamenti molti a uno con tutte le transizioni di
uscita ed ingresso della piazza master.
Poiche il nostro scopo e usare le MTPN per l' analisi di sistemi digitali,
sarebbe utile prevedere un meccanismo per poter esprimere facilmente relazioni
logiche tra segnali (ovvero tra piazze) senza dover simulare le porte logiche con
piazze e transizioni. Un metodo per estendere le reti di Petri in tale direzione
e quello di dotare le transizioni di funzioni di abilitazione, che riprendono e
potenziano il meccanismo degli archi inibitori. Le funzioni di abilitazione sono
delle funzioni che, associate ad una transizione, la abilitano o meno a seconda
dello stato attuale della rete.
2.3.1 Descrizione formale
Sintassi
Una Modular Time Petri Net e una 6-tupla
MTPN =< P^ T^ A AF FI s >
dove:
P^ e l' insieme delle piazze della rete, divise tra piazze originali ed impor19
CAPITOLO 2. MODULAR TIME PETRI NET
tate:
P^ = P P i
T^ e l' insieme delle transizioni della rete, divise tra transizioni originali,
importate, di incremento e di decremento:
T^ = T T i T up T down
Per comodita si de nisce anche l' insieme T" delle transizioni di interfaccia:
T" = T i T up T down
A e l' insieme degli archi di pre-condizione, post-condizione ed inibitori:
A (P^ T^) (T^ P^ )
AF associa alle transizioni la propria funzione di abilitazione
AF : T^ ! F
dove F e l' insieme delle funzioni di abilitazione af :
af : M ! ftrue falseg
con M funzione marcamento (vedi oltre)
FI s e la relazione che associa ad ogni transizione il suo intervallo di
esecuzione statico EFT s ,LFT s]:
FI s : T ! R+ (R+ f1g)
Semantica
Il comportamento dinamico di una MTPN e de nito solo se la rete evolve in un
ambiente chiuso, cioe se e inserita nel sistema completo o se e corredata dalle
necessarie interfacce attesa < T" FIris >.
Lo stato della rete e una una coppia
S =< M FI d >
dove:
M e la funzione marcamento (marking) che associa ad ogni piazza il
numero (non negativo) di gettoni che contiene:
M : P^ ! N+
FI d e la relazione che associa ad ogni transizione il suo intervallo di
esecuzione dinamico EFT d ,LFT d ]:
FI s : T^ ! (R+ f1g) (R+ f1g)
20
CAPITOLO 2. MODULAR TIME PETRI NET
Al solito le regole che determinano il comportamento della rete tengono conto
sia della rete che del comportamento delle interfacce attese:
Inizializzazione: gli intervalli dinamici di tutte le transizioni di interfaccia
ti in T" sono inizialmente assegnati al valore statico FIris (ti init).
Eseguibilita: una transizione t0 e abilitata se tutte le sue piazze di ingresso
contengono almeno un gettone, nessuna delle sue piazze di inibizione contiene dei gettoni, il suo EFT d e minore di 1 e la sua eventuale funzione
di abilitazione ritorna true. Una transizione t0 abilitata e eseguibile se il
suo EFT d e minore del LFT d di ogni altra transizione nello stato S .
Progresso: qualunque transizione t0 eseguibile nello stato S puo eseguire
con un tempo di esecuzione (t0 ) che deve essere maggiore dell' EFT d di
t0 stessa e deve essere minore del LFT d di qualunque altra transizione
abilitata.
Esecuzione: quando la transizione t0 esegue, si deve calcolare il nuovo
stato della rete, il che comporta calcolare il nuovo marcamento delle piazze
ed aggiornare gli intervalli dinamici di esecuzione:
1. si rimuove un gettone da tutte le piazze di ingresso per t0 contenute
in P .
2. se t0 2 T down , si toglie un gettone dalla sua piazza di interfaccia.
3. si aggiunge un gettone a tutte le piazze di uscita per t0 contenute in
P.
4. se t0 2 T up, si aggiunge un gettone alla sua piazza di interfaccia.
5. per ogni transizione di interfaccia ti 2 T" tale che < ti t0 > appartiene
al dominio di FIris , si resetta il suo intervallo di esecuzione dinamico
al valore de nito nell' interfaccia attesa:
EFT d := EFTris (ti t0 )
LFT d := LFTris (ti t0 )
0
0
6. per ogni transizione appena abilitata in T si resetta l' intervallo di
esecuzione dinamico al suo valore statico:
EFT d := EFT s
LFT d := LFT s
0
0
7. per ogni transizione persistente in T^ si trasla a sinistra l' intervallo di
esecuzione del valore del tempo all' esecuzione (t0 ) con cui esegue
t0 :
EFT d := maxf0 EFT d ; (t0 )g
LFT d := maxf0 LFT d ; (t0 )g
0
0
21
CAPITOLO 2. MODULAR TIME PETRI NET
2.3.2 Un esempio
Come semplice esempio di una MTPN consideriamo il caso di un sistema software in cui due processi concorrenti competano per l' accesso ad una risorsa
e supponiamo di dover segnalare quando questa risorsa viene acquisita da uno
dei due processi (ad esempio per fare un log degli accessi o per fare il debugging
del sistema).
t2
t3
1 2]
1 3]
P1
P2
P0
t0
t1
1 3]
2 4]
Figura 2.7. Modello di due processi in competizione per una risorsa
La rete di gura 2.7 modella il sistema composto dai due processi e dalla risorsa:
un gettone nella piazza P0 signi ca che la risorsa e libera, ed uno dei due processi
(modellati rispettivamente da t0 , P1 , t2 e da t1 , P2 , t3 ) puo acquisirla. Dopo
che un processo ha acquisito la risorsa (ad esempio con l' esecuzione di t0 ), il
processo eettua l' elaborazione che ha richiesto la risorsa ed in ne, dopo un
intervallo di tempo variabile, la libera (la transizione t2 modella l' attesa per l'
elaborazione, che puo durare tra 1 e 2 unita di tempo).
d0
P0
u0
t4
0 0]
P3
P4
t5
6 6]
Figura 2.8. Modello del monitor della risorsa
Per segnalare l' acquisizione della risorsa, si usa la rete di gura 2.8, in cui
si fa uso di una piazza importata (P0 ) e delle sue transizioni di incremento e
decremento (u0 e d0 ). All' inizio la presenza di un gettone in P0 impedisce a t4
di scattare. Appena uno dei due processi acquisisce la risorsa svuotando P0 , t4
inizia il ciclo di segnalazione dell' uso della risorsa, ciclo la cui durata e stabilita
dall' intervallo di esecuzione di t5 .
22
CAPITOLO 2. MODULAR TIME PETRI NET
La tabella 2.5 mostra che il modulo si attende che la risorsa subisca solo
decrementi seguiti, prima o poi, da decrementi, cioe che non ci possano mai
essere due gettoni nella piazza importata.
u0
d0
init
u0
d0
1 1 1 1 0 1
0 1 0 1 1 1
Tabella 2.5. L' interfaccia attesa del monitor
Si noti inoltre che, nel collegamento dei due moduli, le transizioni master
per d0 sono t0 e t1 , mentre le transizioni master per u0 sono t2 e t3 .
23
Capitolo 3
Analisi di MTPN
Lo scopo delle analisi che intendiamo fare sulle MTPN e la costruzione del
cosiddetto grafo di raggiungibilita, in cui si raccolgono tutti gli stati possibili
per il sistema e si speci cano le modalita del passaggio da uno stato all' altro.
Il problema principale di questo tipo di analisi e che in una MTPN lo stato
dipende anche dagli intervalli dinamici di esecuzione, che possono assumere in niti valori in un intervallo denso, generando quindi una in nita di stati. Poiche
le MTPN sono un' estensione delle TPN, il problema si puo risolvere usando
tecniche di enumerazione degli stati di raggiungibilita gia sviluppate9]13], che
permettono di raccogliere un numero possibilmente in nito di stati in una classi
di stati e di costruire il grafo di tali classi.
3.1 Classi di stati e Domini di esecuzione
Lo stato di una MTPN e costituito dal marcamento delle piazze e dagli intervalli
dinamici di esecuzione (cfr. sezione 2.3.1).
Una classe di stati S per la rete e una coppia < M D >, dove M e il marcamento delle piazze della rete e D e un dominio di esecuzione (ring domain),
ovvero un sistema di disequazioni lineari che esprime i vincoli sui tempi all'
esecuzione delle transizioni abilitate nello stato. Tale sistema e espresso nella
forma normale46]
(
D = aai
ij
(ti )
(ti ) ; (tj )
bi
bij
8ti tj 2 T (M )
ti =
6 tj
dove
T (M ) e l' insieme delle transizioni t abilitate dal marcamento M .
ai e bi sono il minimo ed il massimo valore di (ti ) per cui esistono soluzioni
del sistema D.
aij e bij sono il minimo ed il massimo valore della dierenza (ti ) ; (tj )
per cui esistono soluzioni del sistema D.
24
CAPITOLO 3. ANALISI DI MTPN
Esistono metodi46] che permettono di ridurre i vincoli di un qualsiasi dominio
di esecuzione in forma canonica, forma che si dimostra esistere sempre ed essere
unica.
Uno stato s di una rete e raccolto nella classe di stati S se s e S hanno lo
stesso marcamento M e qualunque insieme di tempi all' esecuzione compatibile
con gli intervalli dinamici di esecuzione di s soddisfa il dominio di esecuzione
di S . Naturalmente possono esistere soluzioni a D che non sono compatibili
con gli intervalli dinamici di un particolare stato della classe, poiche il dominio
di esecuzione rappresenta il vincolo piu forte soddisfatto da tutti gli stati della
classe.
3.2 Costruzione del grafo degli stati
La costruzione del grafo di raggiungibilita degli stati avviene con un algoritmo
di scansione a ventaglio (breadth rst), con cui si costruiscono tutti i possibili
stati successivi allo stato iniziale, eliminando i duplicati e collegandoli tramite
archi marcati dalla transizione che ha portato da uno stato all' altro.
3.2.1 Dominio ristretto
Il meccanismo fondamentale della costruzione del grafo e il calcolo della classe
di stati Sc cui si arriva da una classe Sp attraverso l' esecuzione di una transizione t0 . Naturalmente t0 dovra essere abilitata in Sp, ma questo non basta a
garantire che t0 sia anche eseguibile in Sp, poiche potrebbe esistere una transizione abilitata t1 il cui LFT d sia minore dell' EFT d di t0 , impedendo cos
a t0 di eseguire nche non abbia eseguito t1 . Se t0 e anche eseguibile, si puo
aggiungere al dominio Dp di Sp il vincolo che t0 esegua prima di tutte le altre
transizioni abilitate, ottenendo quello che si chiama un dominio di esecuzione
ristretto
(
p
t0
Dp = D
0 (t ) ; (t ) 8t 2 T (M )
0
i
i
p
Tale dominio ristretto si usa poi per costruire i vincoli sulle transizioni che sono
persistenti in Sc e che quindi dipendono dalla storia del sistema. I vincoli sulle
transizioni appena abilitate si costruiscono invece a partire dagli intervalli statici
delle transizioni, poiche a tale valore vengono resettati gli intervalli dinamici di
queste transizioni.
Alla nuova classe Sc manca ora solo il marcamento, che puo essere facilmente
ricavato dal marcamento i Sp con le regole di esecuzione di una MTPN.
3.2.2 Algoritmo di costruzione
In 13] sono forniti in dettaglio i metodi per decidere l' eseguibilita di una
transizione abilitata e calcolare il successore direttamente in forma normale,
insieme con la dimostrazione della loro correttezza. Usando questi metodi, si
ottiene l' algoritmo di generazione del grafo riportato in gura 3.1.
25
CAPITOLO 3. ANALISI DI MTPN
1. riduci il dominio di esecuzione della classe radice Sroot in forma normale
2. sia Sroot l' unico elemento del' insieme delle classi da analizzare
3. nche non e vuoto
3.1. sia Sp il primo elemento di 3.2. per ogni transizione t0 abilitata in Sp
3.2.1. se t0 e eseguibile in Sp
3.2.1.1. costruisci Sc da Sp attraverso t0
3.2.1.2. se esiste nel grafo un nodo Sc eguale a Sc
3.2.1.2.1. collega Sc a Sp attraverso t0
3.2.1.3. altrimenti
3.2.1.3.1. collega Sc a Sp attraverso t0
3.2.1.3.2. aggiungi Sc a 3.3. togli Sp da 0
0
Figura 3.1. Algoritmo di generazione del grafo degli stati
3.3 Integrazione dei gra
Una volta completata l' analisi dei singoli moduli di un sistema composto, e
necessario comporre i gra semplici per avere delle informazioni sull' intero
sistema, ottenendo un nuovo grafo che descrive lo stato del sistema complesso
in funzione dello stato dei suoi moduli.
Abbiamo visto nella sezione 2.2.1 che lo stato di un sistema composto si
puo esprimere con l' insieme degli stati dei singoli moduli. In maniera analoga
si puo de nire una classe di stati S per il grafo risultante dall' integrazione di
N moduli come una coppia < S D > dove S e il vettore delle classi di stati Si
dei singoli moduli e D e il dominio di esecuzione per le transizioni dell' intero
sistema. Si noti che in D non compaiono le transizioni slave, cioe quelle transizioni che nel sistema composto sono collegate tramite un canale ad un master.
Infatti le transizioni slave scompaiono nel sistema integrato, dove eseguono in
sincrono con i rispettivi master, poiche non devono piu svolgere il loro compito
di chiudere la rappresentazione del sistema. Le informazioni presenti nei singoli
gra relative alle transizioni slave vengono usate nella costruzione del grafo integrato solo per veri care la coerenza dei vincoli espressi dalle interfacce attese
con l' ambiente in cui il modulo viene inserito.
L' algoritmo di costruzione per il grafo integrato e lo stesso usato nella
costruzione dei gra dei singoli moduli, con l' unica importante dierenza che
cambia il modo di costruire i singoli nodi. Serve cioe un metodo per costruire
il successore Sc della classe Sp dovuto all' esecuzione della transizione t0 .
3.3.1 Calcolo dello stato successore
Per costruire il nuovo vettore degli stati Sc si indica con Spi lo stato di Sp del
modulo cui appartiene t0 e con Spj lo stato del modulo cui appartiene ts . Si
devono distinguere due casi diversi a seconda che t0 sia o meno collegata ad
una transizione slave ts :
26
CAPITOLO 3. ANALISI DI MTPN
t0 non master: in questo caso l' esecuzione di t0 inuenza solo il modulo
cui appartiene t0 , e quindi Sc e identico a Sp salvo che al posto di Spi si
pone Sci , successore di Spi attraverso t0 .
t0 master di ts: adesso l' esecuzione di t0 inuenza sia il modulo cui
appartiene t0 che quello cui appartiene ts, dato che le due transizioni
eseguono contemporaneamente. Il nuovo stato Sc e uguale a Sp salvo che
al posto di Spi si pone Sci , successore di Spi attraverso t0 , ed al posto di Spj
si pone Scj , successore di Spj attraverso ts .
3.3.2 Calcolo del dominio di esecuzione
Il calcolo del dominio di esecuzione dello stato Sc si eettua, in maniera analoga a quanto fatto per i singoli moduli, in maniera diversa per le transizioni
persistenti rispetto a quelle appena abilitate, tenendo conto che sono persistenti
tutte le transizioni appartenenti a stati persistenti, cioe a stati di Sp che non
sono cambiati nel passare a Sc , e che sono appena abilitate solo le transizioni
che sono appena abilitate negli stati che sono cambiati nel passaggio da Sp a Sc
(ovvero sono appena abilitate le transizioni che sono appena abilitate in Sci ed
eventualmente Scj e sono persistenti tutte le altre). Per le transizioni persistenti,
i vincoli si calcolano a partire dal dominio ristretto Dpt0 ottenuto imponendo a
Dp l' esecuzione di t0 prima di tutte le altre transizioni, mentre i vincoli sulle
transizioni appena abilitate si copiano dai corrispondenti vincoli nei gra dei
singoli moduli.
3.3.3 Errori di integrazione
Nel calcolo del nuovo stato si possono veri care due errori di integrazione,
entrambi fatali, dovuti a degli errori nella speci ca delle interfacce attese:
late arrival: si ha un arrivo in ritardo se nel grafo cui appartiene t0 essa
non e un arco di uscita per Spi , cioe se non esiste alcun Sci . Questo errore
si veri ca quando una transizione slave ts consuma il suo LFT d prima
dell' esecuzione della sua transizione master.
unexpected arrival: si ha un arrivo inatteso se nel grafo cui appartiene ts
essa non e un arco di uscita per Spj , cioe se non esiste alcun Scj . Questo
errore si veri ca quando una transizione master esegue prima che la sua
transizione slave abbia consumato il suo EFT d .
Poiche il processo di costruzione dei gra puo essere abbastanza pesante, quando
si incontrano tali errori, di per se fatali, conviene comunque cercare di proseguire
l' integrazione del sistema per andare a cercare altri eventuali errori, tenendo
presente che il grafo risultante non e totalmente corretto e quindi puo non
rappresentare correttamente il sistema completo. Una strada per continuare l'
integrazione e quella di introdurre degli opportuni stati di errore al posto degli
stati che non si sono potuti calcolare e proseguire la costruzione normalmente.
Naturalmente tali stati di errore dovranno essere stati terminali, cioe senza
successori. Se non si veri cano errori fatali, si dimostra13] che il grafo ottenuto
27
CAPITOLO 3. ANALISI DI MTPN
e corretto, ovvero che e lo stesso grafo che si otterrebbe integrando i gra dei
singoli moduli ottenuti senza i limiti imposti dalle interfacce attese.
3.3.4 Verica delle interfacce attese
Anche se l' algoritmo di integrazione giunge a termine senza errori e quindi
produce un grafo corretto, non e detto che i singoli moduli soddis no completamente le interfacce attese. Infatti l' assenza di violazioni delle interfacce oerte
e una condizione suciente ma non necessaria per la corretta conclusione del
processo di integrazione.
La violazione (non fatale) delle interfacce attese puo essere scoperta durante
l' integrazione dei gra dei moduli, prendendo in considerazione anche i vincoli sulle transizioni slave e controllando se tali vincoli cambiano il dominio di
esecuzione globale calcolato in loro assenza44].
Come accennato, per rilevare violazioni alle interfacce attese e necessario
conservare nei domini di esecuzione dei nodi del grafo integrato anche i vincoli che coinvolgono transizioni slave ed aggiungere un passo all' algoritmo di
costruzione del successore. Infatti in un primo tempo e necessario calcolare
il dominio ristretto Dpt0 considerando solo le transizioni non slave durante la
restrizione e la successiva normalizzazione. In seguito si restringe solo i vincoli
relativi a transizioni slave, si aggiunge le condizioni che transizioni master e rispettivi slave eseguano contemporaneamente e si rinormalizza il dominio senza
pero modi care i coecienti delle transizioni non slave. Se il dominio risultante
non e in forma normale, si e veri cata una violazione delle interfacce attese: l'
integrazione produce comunque un risultato corretto, ma i singoli moduli sono
stati analizzati con ipotesi (ovvero le interfacce attese) non coerenti tra loro.
Questo metodo basa il suo funzionamento sul fatto che nel processo di normalizzazione di un dominio, i vincoli piu stringenti si propagano anche ai vincoli
correlati e quindi se il dominio risultante non e piu normale, alcuni vincoli sulle
transizioni slave, propagati ai vincoli sui master, li renderebbero piu stringenti, segnalando una possibile violazione delle interfacce attese delle transizioni
implicate.
3.4 Analisi temporale
Una volta ottenuto il grafo di raggiungibilita per un sistema (si esso un semplice
modulo o l' integrazione di piu moduli), si possono da esso ricavare numerose
informazioni: con una semplice ispezione si possono rilevare gli eventuali stati terminali (corrispondenti ai deadlock del sistema) e ricavare alcune semplici
proprieta di temporizzazione (timeliness). Il grafo permette anche di ricavare informazioni sulla durata massima e minima di una traccia di esecuzione,
permettendo di veri care tutte le temporizzazioni del sistema. Per ricavare
la durata di una traccia esistono due approcci diversi dal punto di vista della
complessita e della qualita dei risultati43]. Il primo, detto algoritmo di stima
a stato singolo, calcola i limiti all' esecuzione della traccia considerando separatamente i domini di esecuzione visitati lungo la traccia stessa questa stima
28
CAPITOLO 3. ANALISI DI MTPN
si calcola con complessita lineare rispetto al numero di transizioni della traccia, ma non assicura vincoli minimi. L' altro algoritmo, detto di stima a stato
globale, considera in un unico sistema di disequazioni tutti i vincoli incontrati
nell' esecuzione della traccia, garantendo limiti ottimi a prezzo di una maggiore
complessita computazionale.
3.4.1 Traccia di esecuzione
Prima di descrivere in dettaglio i due algoritmi conviene introdurre la notazione
usata per descrivere una traccia T :
N e il numero di transizioni eseguite nella traccia.
S n e l' n-esimo stato incontrato nell' esecuzione della traccia. Con questa
notazione S 0 e lo stato di partenza della traccia e S N lo stato nale o di
arrivo.
F (n) associa all' indice n il nome della transizione che esegue in tale
posizione.
tF (n) e la transizione che esegue nello stato S n e porta nello stato S n+1 .
L' insieme ftF (0) : : : tF (N 1) g indica tutte le transizioni della traccia.
(tF (n) ) e il tempo che il sistema passa nello stato S n, ovvero il tempo
che passa da quando il sistema entra nello stato S n a quando esegue la
transizione tF (n) .
ani e bni sono i coecienti che vincolano il tempo all' esecuzione della
transizione ti nello stato S n (cioe nel dominio di esecuzione di S n compare
il vincolo ani (ti ) bni ). Si suppone inoltre che tutti i domini di
esecuzione siano espressi in forma normale e tutte le transizioni del primo
stato S 0 sono considerate appena abilitate.
LPS (t0 ) associa ad una transizione t0 la posizione nella traccia dell' ultimo
stato in cui tale transizione e persistente. Una transizione, dopo essere
stata abilitata, resta persistente no a che non esegue o viene disabilitata
dall' esecuzione di un' altra transizione.
;
3.4.2 Algoritmo di stima a stato singolo
Per ottenere una prima stima del tempo di esecuzione della traccia T , osserviamo che anche la transizione tF (n) esegua nello stato S n , il suo tempo all'
esecuzione deve essere minore di tutti i LFT d delle altre transizioni abilitate
in S n inoltre valgono i vincoli imposti dal dominio di esecuzione, quindi deve
valere il vincolo
anF (n) (tF (n) ) bnF (n)
sul tempo di permanenza nello stato S n per tutte le transizioni di T .
29
CAPITOLO 3. ANALISI DI MTPN
Considerando tutti gli stati visitati nella traccia, una prima stima del tempo
globale di esecuzione (T ) si puo esprimere cos:
X
N ;1
n=0
anF (n) (T )
X
N ;1
n=0
min bnk
tk 2T (M n )
Per migliorare questa prima approssimazione si deve stimare il tempo di esecuzione di ogni transizione della traccia, usando iterativamente i vincoli descritti
in precedenza. L' intervallo di esecuzione di una transizione che esegue nella
traccia comincia a scorrere da quando il sistema entra in uno stato che rende
la transizione appena abilitata, dunque tale intervallo puo essere reso assoluto,
cioe riferito all' inizio dell' esecuzione della traccia, sommandovi il tempo a cui
il sistema entra in quello stato. Iterando tale principio per tutta la traccia, si
ottiene una stima migliore sul tempo a cui ogni transizione esegue. Indicando
con EFT n il vettore dei tempi minimi stimati per l' esecuzione di tF (n) e con
LFT n l' analogo vettore dei tempi massimi, tali vettori possono essere calcolati
con l' algoritmo di gura 3.2.
0. sia EFT in LFT in] l' intervallo di esecuzione della transizione
di ingresso nello stato corrente (inizialmente nullo).
1. per n da 0 a N ; 1
1.1. per ogni transizione ti appena abilitata in S n
1.1.1. se ti esegue in S n (ti tF (n) )
1.1.1.1. poni EFT n = EFT in + ani
1.1.1.2. poni LFT n = LFT in + mint T (M ) bnk
1.1.2. se ti esegue dopo S n nello stato S m (9m > n : ti tF (m) )
1.1.2.1. poni EFT m = EFT in + ani
1.1.2.2. poni LFT m = LFT in + bni
1.2. se EFT n < EFT in
1.2.1. poni EFT n = EFT in
1.3. poni EFT in = EFT n
1.4. poni LFT in = LFT n
k2
n
Figura 3.2. Algoritmo di stima a stato singolo
3.4.3 Algoritmo di stima a stato globale
Durante l' esecuzione di una traccia, i possibili tempi di esecuzione delle transizioni sono limitati da vincoli incrociati che ne impediscono il calcolo esatto
andando a considerare solo i vincoli locali ad ogni stato. Infatti, poiche il dominio di esecuzione di ogni classe di stati accetta tutti i tempi di esecuzione che
sono possibili per ogni stato appartenente alla classe stessa, puo succedere che
alcuni degli stati riuniti in una classe non accettino tutti i tempi all' esecuzione
che sono invece compatibili con il dominio di esecuzione della classe stessa.
Questo impedisce all' algoritmo a stato singolo di fornire delle stime minime, stime che invece sono il risultato dell' algoritmo a stato globale, il quale
30
CAPITOLO 3. ANALISI DI MTPN
costruisce un sistema di disequazioni globale in cui compaiono tutti i vincoli che
limitano i tempi all' esecuzione di tutte le transizioni eseguite lungo la traccia.
Per costruire tale sistema di disequazioni si devono considerare, oltre a tutti
i vincoli che compaiono nei domini di esecuzione sulle transizioni che eseguono,
anche i vincoli sulle transizioni che non eseguono mai, ma che impongono delle
condizioni aggiuntive all' esecuzione della traccia. Un' ulteriore complicazione
deriva dal fatto che una transizione ti puo comparire piu volte negli stati visitati
dalla traccia ed essere piu volte abilitata, disabilitata e riabilitata di nuovo
prima di eseguire. Quando ci riferiamo ad una transizione t0 che esegue nella
traccia, intendiamo l' ultima istanza di t0 , escludendo le volte in cui t0 e abilitata
e disabilitata prima che possa eseguire.
L' algoritmo usa l' idea di ultimo stato di persistenza di una transizione
per aggiungere al sistema di disequazioni globale i giusti vincoli. Infatti una
transizione appena abilitata puo imporre due tipi di vincoli, a seconda che arrivi
o meno all' esecuzione:
Se arriva all' esecuzione, il tempo in cui resta persistente deve essere
maggiore del suo EFT s e minore del suo LFT s.
Se non arriva all' esecuzione resta solo il vincolo che essa non puo restare
abilitata senza eseguire per piu del suo LFT s .
Il tempo in cui una transizione resta abilitata e il tempo che passa dalla esecuzione della transizione che porta nello stato in cui e appena abilitata alla
transizione che esce dall' ultimo stato di persistenza.
Un altro vincolo da imporre al sistema di disequazioni globale e che ogni
transizione nella traccia esegue dopo le transizioni che la precedono.
Applicando queste considerazioni intuitive, ampliate e dimostrate in 43], si
ottiene l' algoritmo di calcolo del sistema di disequazioni globale D di gura
3.3.
Il sistema di disequazioni globale si puo scrivere nella stessa forma di un
dominio di esecuzione e quindi, una volta costruito, lo si puo risolvere normalizzandolo, evidenziando cos i vincoli minimi sui tempi di esecuzione delle
singole transizioni della traccia.
3.5 Costruzione di interfacce o erte
Abbiamo visto come le interfacce attese siano usate per nascondere i dettagli
interni di un modello realizzato con le MTPN orendo di esso solo una rappresentazione in termini degli intervalli di tempo che passano tra l' esecuzione di
una transizione osservabile e l' esecuzione di ogni altra transizione osservabile.
La scelta delle transizioni osservabili dipende ovviamente dal tipo di rappresentazione che si vuole del modello, potendosi avere piu rappresentazioni di
uno stesso modello nalizzate ad analisi diverse. Una volta scelte le transizioni,
si deve costruire l' interfaccia attesa in maniera corretta, cioe compatibilmente con la rappresentazione del modello data dal suo grafo di raggiungibilita.
La miglior soluzione e quella di costruire direttamente dal grafo l' interfaccia
oerta.
31
CAPITOLO 3. ANALISI DI MTPN
1. per ogni transizione ti dello stato iniziale S 0
1.1. se ti esegue in LPS (ti )
1.1.1. aggiungi a0i (tF (LPS(t )) ) b0i
1.1.2. per ogni transizione tj in S 0 diversa da ti
1.1.2.1. se tj esegue in LPS (tj )
1.1.2.1.1. aggiungi a0ij (tF (LPS(t )) ) ; (tF (LPS(t )) ) b0ij
1.1.2.2. altrimenti
1.1.2.2.1. aggiungi a0ij (tF (LPS(t )) ) ; (tF (LPS(t )) )
1.2. altrimenti
1.2.1. aggiungi (tF (LPS(t )) ) b0i
2. per n da 1 a N ; 1
2.1. per ogni transizione ti appena abilitata in S n
2.1.1. se ti esegue in LPS (ti )
2.1.1.1. aggiungi ani (tF (LPS(t )) ) ; (tF (n 1) ) bni
2.1.2. altrimenti
2.1.2.1. aggiungi (tF (LPS(t )) ) ; (tF (n 1) ) bni
3. per n da 1 a N ; 1
3.1. aggiungi 0 (tF (n) ) ; (tF (n 1) )
i
i
j
i
j
i
;
i
i
;
;
Figura 3.3. Algoritmo di stima a stato globale
A tal ne, per ogni coppia di transizioni osservabili < t0 tf >, si deve
calcolare l' intervallo di esecuzione statico oerto FIpis (t0 tf ) in modo tale che
dopo l' esecuzione di tf , t0 non esegua prima di essere stato continuamente
abilitato per almeno EFTpis (t0 tf ) e non resti continuamente abilitato senza
eseguire per piu di LFTpis (t0 tf ).
Poiche l' intervallo di esecuzione dinamico di t0 e resettato ogni volta
che si esegue una transizione osservabile, EFTpis (t0 tf ) e posto al minimo
tempo necessario ad eseguire una traccia che inizi da un qualunque stato
in cui si entra attraverso tf e termini con l' esecuzione di t0 senza eseguire
nessun' altra transizione osservabile. Se tale traccia non esiste, si pone
EFTpis (t0 tf ) = 1, poiche t0 non esegue mai dopo l' esecuzione di tf .
Poiche LFTpis (t0 tf ) limita il tempo in cui t0 puo rimanere abilitata senza
eseguire, e posto al massimo tempo necessario ad eseguire una traccia che
inizi da un qualunque stato in cui si entra attraverso tf e termini con l'
esecuzione di una qualunque transizione osservabile. Se non esiste tale
traccia, si pone LFTpis (t0 tf ) = 1.
3.5.1 Enumerazione automatica di tracce
Per costruire una interfaccia oerta e necessario trovare tutte le tracce che partono da un certo stato e terminano con certe transizioni. La costruzione di
tutte queste tracce e un problema non banale, complicato anche dal fatto che
le tracce possono fare dei loop nel grafo e che tali loop devono essere segnalati.
La soluzione ha portato alla creazione di un algoritmo originale modellato sulla
falsa riga dell' algoritmo di attraversamento a ventaglio.
32
CAPITOLO 3. ANALISI DI MTPN
L' idea e quella di costruire tutte le tracce che partono da un certo insieme
di stati S e niscono con una certa condizione di ne traccia, mantenendo un
insieme di tracce # in costruzione, allungandole via via che si attraversa il grafo
e terminandole quando si incontra un loop o una condizione di ne traccia. Le
tracce nite si mettono nell' insieme ;, mentre i loop in %. Una transizione
che innesca un loop si riconosce esaminando la traccia e controllando che non
ci sia un' altra esecuzione della stessa stessa traccia che porta nello stesso stato
cui porta l' esecuzione attuale. Si introduce l' idea di traccia vuota, intendendo
una traccia di lunghezza N = 0 in cui lo stato iniziale coincide con quello nale
(S 0 S N ). L' algoritmo completo e mostrato in gura 3.4.
1. poni in le tracce vuote che niscono negli stati di S
2. nche non e vuoto
2.1. togli da la prima traccia T
2.2. sia S N lo stato nale di T
2.3. se S N e uno stato terminale
2.3.1. aggiungi T a ;
2.4. altrimenti per ogni transizione to di uscita per S N
2.4.1. se to e una transizione terminale
2.4.1.1. aggiungi fT + to g a ;
2.4.2. altrimenti se in to innesca un loop
2.4.2.1. aggiungi T a 2.4.3. altrimenti
2.4.3.1. aggiungi fT + to g a T
T
T
Figura 3.4. Algoritmo di enumerazione automatica delle tracce
3.5.2 Algoritmo per il calcolo di interfacce oerte
Usando il precedente algoritmo per costruire tutte le tracce possibili tra l' esecuzione di una transizione tf e l' esecuzione di una transizione osservabile, e
calcolandone i tempi di esecuzione con i metodi illustrati in precedenza, la
costruzione di una interfaccia oerta risulta quasi banale.
Le uniche considerazioni che restano da fare riguardano il calcolo del limite
superiore ed i loop. Infatti dopo l' esecuzione di tf , tutte le altre transizioni
osservabili possono restare continuamente abilitate no a che una di loro non
esegue, dato che la nuova esecuzione resetta tutti gli intervalli di esecuzione
dinamici. Quindi il LFTpis (t0 tf ) dipende solo da tf , ed e uguale per tutte le
transizioni t0 osservabili e raggiungibili, ovvero per tutte le transizioni t0 per cui
esiste una traccia che le raggiunge partendo da tf senza eseguire nessun' altra
transizione osservabile. Inoltre, poiche si parla di durata massima, quando si
calcola tale durata massima tra tutte le tracce che partono con l' esecuzione di
tf , si devono considerare eventuali loop incontrati, che possono essere eseguiti
in nite volte prima di portare all' esecuzione di una transizione osservabile se
almeno uno di questi loop ha durata massima non nulla, dall' esecuzione di tf
33
CAPITOLO 3. ANALISI DI MTPN
all' esecuzione di una transizione osservabile puo passare un tempo massimo
in nito.
Da tutte queste osservazioni si ottiene l' algoritmo di gura 3.5 che calcola
tutte le interfacce oerte relative all' esecuzione di una transizione tf .
1. sia l' insieme degli stati in cui si entra con tf
2. costruisci le tracce ; ed i loop che partono da e niscono con una transizione osservabile
3. sia LFT = ;1 la durata massima delle tracce che partono con tf
4. per ogni traccia T in ;
4.1. sia E la durata minima di T
4.2. sia L la durata massima di T
4.3. sia T0 l' ultima transizione di T
4.4. se E < EFTpis (t0 tf )
4.4.1. EFTpis (t0 tf ) = E
4.5. se L > LFT
4.5.1. LFT = L
5. per ogni loop L in 5.1. se la durata massima di L e > 0
5.1.1. LFT = 1
6. per ogni transizione t0 osservabile e raggiungibile da tf
6.1. LFTpis (t0 tf ) = LFT
Figura 3.5. Algoritmo di calcolo delle interfacce oerte
3.6 Esempi
Applicando l' algoritmo per la costruzione del grafo degli stati al semplice modello di un protocollo stop and wait (vedi gura 2.1), otteniamo il grafo di gura
3.6, in cui si possono vedere i domini di esecuzione di ciascuno stato.
Lo stesso algoritmo permette di calcolare i gra dei singoli moduli che compongono il modello del protocollo di Stenning (vedi gura 2.2), ottenuti dalle
reti delle gure 2.3, 2.4, 2.5 e 2.6 con l' assunzione delle rispettive interfacce
attese.
I gra dei moduli source ( gura 3.7) e TX ( gura 3.9) e dei moduli RX
( gura 3.10) e sink ( gura 3.8), sono stati successivamente integrati con l' algoritmo di integrazione, veri cando cos la correttezza dei vincoli imposti dalle
interfacce attese ed ottenendo i gra delle gure 3.11 e 3.12.
Applicando nuovamente il processo di integrazione ai gra dei due sottosistemi appena calcolati, otteniamo il grafo dell' intero modello. Il grafo nale e
troppo complesso per essere mostrato gra camente e tale complessita complica
anche la sua interpretazione. Per sempli care la lettura dei risultati conviene
costruire le interfacce oerte dei due sottosistemi source-TX e RX-sink isolando
solo le transizioni relative allo scambio di pacchetti tra i due sistemi. Il risultato
34
CAPITOLO 3. ANALISI DI MTPN
- S2 : P (tP)
0
0 6
0
4
t0
?
S1 : P1 P2 P6
16 (t1) 16
2 (t3) 4
2 (t6) 4
t6
- S12: P P(t )
3
1 6
1
14
t1
t3
?
S2 : P1 P4 P6
12 (t1) 14
0 (t7) 0
t7
?
S4 : P1 P7
12 (t1) 14
1 (t8) 2
t8
?
S5 : P1 P5 P6
10 (t1) 13
2 (t4) 4
2 (t5) 4
t4
- S6 : P (tP)
6
1 6
1
11
t1
t5
?
S7 : P1 P3 P6
6 (t1 ) 11
0 (t2 ) 0
t2
Figura 3.6. Grafo del modello del protocollo stop and wait
35
CAPITOLO 3. ANALISI DI MTPN
S0 : P0 P2
2 (t0 ) 4
t0
- S0
1
?
:P P
1 2
(t1 ) 1
t1
?
S2 : P0
2 (t0) 4
0 (i20 ) 1
- S0 : P (tP)
i20
4
0 2
0
4
t0
t0
?
S3 : P1
0 (i20 ) 1
i20
Figura 3.7. Grafo del modello della sorgente nel protocollo di Stenning
- S0 : P (i
0
14
50
) 1
i50
?
S1 : P12 P14
0 (t13 ) 1
t13
?
S2 : P13
0 (t14 ) 0
t14
Figura 3.8. Grafo del modello della destinazione nel protocollo di Stenning
36
CAPITOLO 3. ANALISI DI MTPN
-S
0 : P6
0 (i31 ) 1
i31
?
:P P
S1 3 6
1 (t3) 2
t3
?
S2 : P4 P8
16 (t5 ) 16
3 (t7 ) 6
3 (t8 ) 6
-S
t8
I@@
t7
?
@@t
t5
S3 : P4
10 (t5) 13
0 (i30 ) 1
4 : P4
10 (t5 ) 13
t5
4
@@ ?
-S : P
5
5
1 (t4) 2
i3 0
?
:P P
S6 4 7
0 (t6) 1
t6
Figura 3.9. Grafo del modello del trasmettitore nel protocollo di Stenning
37
CAPITOLO 3. ANALISI DI MTPN
S0 : P10
0 (i41 ) 1
i41
?
S1 : P9 P10
1 (t10 ) 3
10 (i41 ) 1
t10
- S7 : P (i
2
?
11
41
)
3 (t11 )
3 (t12 )
0 (i40 )
t12
- S0 : P (t P)
i40
1
6
6
1
5
QQt
QQ
10 11
11
6
0 (t12 ) 6
1 (i41 ) 1
?
S4 : ;
0 (i40 ) 1
0 (i41 ) 1 i40
Q
8
10
41 ) 1
i41
QQs
S3 : ;
0 (i40 ) 1
1 (i41 ) 1
i
Q
QQ
i
i
Q
? +
QsS : P ?
41
S7 : P9
0 (i40 ) 1
0 (t9) 0
10 (i41 ) 1
40
- S1 : P (i
11
t12
?i
t11
41
40
6
10
0 (i41 ) 1
6
QkQ t9
QQQQ
QQQQQs
Q
S9 : P9 P10
10 (i41 ) 1
1 (t10 ) 3
i41
i40
i41 S1 0 : ;
0 (i40 ) 1
10 (i41 ) 1
t10
Figura 3.10. Grafo del modello del ricevitore nel protocollo di Stenning
38
CAPITOLO 3. ANALISI DI MTPN
S0 : S0 S0
2 (t0 ) 4
?t
0
S1 : S1 S0
0 (t1 ) 1
?t
1
- 2: ( ) 4
1 ( ) 2
t
t
)
?
:
S2
S2 S1
t0 t3 0
3
S3 : S3 S1
0 (t3 ) 0
S4
t3
- 163
S2 S2
0 (t3 ) 0
16 (t5 ) 16
3 (t7 ) 6
3 (t8 ) 6
t0
?
S5 : S3 S2
(t5 ) 16
(t7 ) 6
3 (t8 ) 6
?
S6 : S3 S2
13 (t5 ) 16
0 (t7 ) 6
0 (t8 ) 6
Qt Q
?t + QQst
?
Qt5
t5
8
7
i30
?
S15 : S3 S6
0 (t6 ) 1
Ht7
S8 : S2 S4
0 (t0 ) 0
13 (t5 ) 13
HHH
H:Hj
S7
t0
S10 : S3 S4
10 (t5 ) 13
?
i
5
S14
4
QtQ
QQ
0
S3 S5
t4 6
S16 : S3 S6
(t6 ) 1
ZZ
ZiZ
30
t
+
0
S1 S0
0 (t1 ) 1
t1
Figura 3.11. Grafo dell' integrazione tra source e TX
39
S3 S4
13 (t5 ) 13
6
S18
QQ
Qs
:
S13
S11 : S3 S3
30 13 (t5 ) 13
0 (i30 ) 1
t
? +
:
1 ( ) 2
@I t 0
HH;t ;t
@
@
; HHHj :
Q
9 QQs
S2 S3
0 (t0 ) 0
13 (t5 ) 13
0 (i30 ) 1
t8
7
S9 : S3 S3
10 (t5 ) 13
0 (i30 ) 1
-
t8
t5
ZZ~
S12 : S2 S6
0 (t0 ) 0
0 (t6 ) 1
?t
6
S17 : S4 S0
0 (t0 ) 0
CAPITOLO 3. ANALISI DI MTPN
S0 : S0 S0
0 (i41 ) 1
-S
i41
?
: S1 S0
1 (t10 ) 3
10 (i41 ) 1
1
t10
?
S2 : S2 S1
7 (i41 )
3 (t11 )
3 (t12 )
0 (t13 )
1
6
6
1
t13
?
S3 : S2 S2
6 (i41 )
2 (t11 )
2 (t12 )
0 (t14 )
1
6
6
0
t14
?
S4 : S5 S0
2 (t11 ) 6
2 (t12 ) 6
6 (i41 ) 1
t12
- S0 : S (iS )
6
0 0
41
1
i41
t11
?
:S S
S5 8 0
1 (i41 ) 1
i41
Figura 3.12. Grafo dell' integrazione tra RX e sink
40
CAPITOLO 3. ANALISI DI MTPN
di questa costruzione e mostrato nelle tabelle 3.1 e 3.2.
t7
i30
init
6 1
1 1
t7
14 1
0 1
i30
4 1
1 1
Tabella 3.1. L' interfaccia oerta del sistema composto source-TX
t12
i41
init
t12
1 1 1 1
0 1 0 1
i41
4 1
10 1
Tabella 3.2. L' interfaccia oerta del sistema composto RX-sink
Integrando i gra ottenuti da queste interfacce oerte, si arriva al grafo di
gura 3.13
S0 : S0 S0
6 (t7 ) 1
-S
t7
?
: S1 S1
14 (t7 ) 1
4 (t12 ) 1
1
t7
t12
?
:S S
S2 2 0
4 (t7 ) 1
t7
Figura 3.13. Grafo dell' integrazione delle interfacce oerte dei sistemi
source-TX e RX-sink
41
Capitolo 4
Modellazione di Bus con
MTPN
4.1 I Bus nei sistemi a microprocessore
Il bus e un canale per lo scambio di informazioni tra i moduli di un sistema18].
Le informazioni trasmesse sono di diversi tipi. Il tipo di trasferimento piu
frequente riguarda i codici delle istruzioni che passano dalla memoria al microprocessore, ed e evidente che questi trasferimenti dovranno essere il piu veloci
possibile, per evitare che il microprocessore si fermi per attendere l' arrivo di
una istruzione. I trasferimenti meno frequenti sono generalmente quelli che
coinvolgono le memoria di massa o altre periferiche di ingresso/uscita, in cui l'
accesso (in termini di indirizzamento sul bus) non e casuale, ma avviene tramite
porte di interfaccia associate a funzioni del dispositivo di I/O.
Il generale il bus deve avere caratteristiche diverse a seconda della natura delle informazioni da trasferire e del tipo di dispositivi che deve mettere
in comunicazione. Funzionalmente si possono de nire diversi tipi di bus per
microcomputer:
Bus locali che permettono frequenti trasferimenti ad alta velocita di pochi
dati tra componenti molto integrate tra loro.
Bus per back-plane, che si occupano di trasferimenti meno frequenti ad
alta velocita tra componenti del sistema che si trovano su schede dierenti
all' interno del cabinet principale.
Bus di sistema usati per trasferimenti paralleli ad alta velocita di blocchi
di dati tra microprocessori e la memoria di sistema condivisa in un sistema multiprocessore o tra un microcomputer e dispositivi di I/O ad alta
velocita in sistemi ad alte prestazioni.
Bus di I/O che forniscono supportano i trasferimenti, relativamente poco
frequenti, di grossi blocchi di dati tra un microcomputer e le sue periferiche
di I/O questi bus sono di due tipi: seriali e paralleli.
42
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
Non e plausibile pensare di costruire un microcomputer dotato di tanti bus
diversi, ognuno dedicato ed ottimizzato per le comunicazioni con un solo dispositivo. Il numero di connessioni da realizzare nelle schede e negli integrati, lo
spazio sico richiesto per disporre i bus e le dicolta di eventuali modi che o
espansioni al progetto originale impongono di usare dei bus condivisi da piu dispositivi. Per questo una singola struttura a bus e comunemente impiegata per
connettere molteplici dispositivi In un semplice bus che collega due dispositivi,
la comunicazione e facile: un dispositivo (il master, tipicamente la CPU) inizia
il trasferimento dei dati e l' altro (lo slave), fornisce o riceve i dati in questione.
Le cose si complicano se al bus sono collegati altri dispositivi slave, poiche per
completare un trasferimento il master deve indicare a quale slave si rivolge (ad
esempio tramite un indirizzo). Se poi sul bus sono presenti altri dispositivi
che possono funzionare come master (ad esempio un controllore di DMA), ogni
master deve ottenere l' uso del bus prima di iniziare un trasferimento. Nella
situazione di maggior complessita si possono individuare tre diverse azioni di
controllo esercitate nelle operazioni di un bus: fasi:
Device synchronization. Il dispositivo slave manda al master la richiesta
di iniziare un trasferimento di dati. La richiesta e riconosciuta dal master,
che ne esamina la priorita ed inizia il trasferimento non appena la richiesta
ha la priorita piu alta tra le eventuali altre richieste fatte.
Bus allocation. Il master richiede l' uso del bus. La richiesta e riconosciuta
e la sua priorita esaminata dalla logica di arbitraggio. Quando la richiesta
ha la priorita piu alta ed il bus e libero, il master ne ottiene il controllo.
Data transfer. Il master segnala allo slave che e pronto per il trasferimento. Lo slave risponde ed ha luogo il trasferimento. Completato il
trasferimento, il master rilascia il bus ed esamina la richiesta successiva.
Durante ogni fase delle operazioni, i dispositivi master e slave devono generare la giusta sequenza di segnali di controllo, in accordo all' ordine ed alla
temporizzazione de nite nel protocollo del bus.
4.1.1 Specica del protocollo di un bus
Il protocollo del bus speci ca completamente il bus, descrivendone le caratteristiche siche (numero di segnali e le loro tensioni, forma dei connettori, ecc.),
logiche (signi cato dei segnali, uso dei segnali, ecc) e temporali (temporizzazioni, vincoli di priorita, ecc.). Le proprieta logico-temporali di un bus sono quelle
che piu lo caratterizzano, ma sono anche le piu dicili da speci care in maniera
completa e non ambigua. I metodi piu usati per descrivere le operazioni di un
bus sono tre: i diagrammi temporali (timing diagram), i diagrammi di sequenza
(sequence diagram) ed i diagrammi di stato (state diagram).
Diagrammi temporali
La sequenza delle operazioni e descritta da un insieme di gra ci che indicano le
variazioni nel tempo dei segnali di controllo rilevanti. Le condizioni logiche che
causano le transizioni dei segnali sono indicate con delle frecce.
43
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
Il metodo dei diagrammi temporali e popolare poiche permette di identi care facilmente le transizioni importanti nella sequenza delle operazioni e presenta
le informazioni nello stesso modo del monitor di un analizzatore di stati logici.
Nonostante questo, l' interpretazione di questi diagrammi non e sempre facile,
per i seguenti motivi:
Lo stato logico dei dispositivi non e mostrato e si ricostruire solo approssimatamente dall' andamento temporale dei segnali di controllo1 .
I segnali di controllo generati da dispositivi diversi e spesso sicamente
lontani sono combinati un un solo diagramma.
Spesso l' unica sequenza di operazioni mostrata e quella normale, poiche
per descrivere tutte le sequenze possibili sarebbero necessari troppi diagrammi. Le operazioni meno comuni, che potrebbero accadere durante l'
accensione del sistema o in caso di errore, sono presentate raramente e
con descrizioni spesso incomplete.
Diagrammi di sequenza
La sequenza delle operazioni e descritta da una lista di frasi che speci cano ogni
evento. Le frasi sono tabulate in ordine cronologico in due o piu colonne, una
per ogni dispositivo. Il usso degli eventi nella tabella e indicato da frecce tra
gli eventi importanti. Poiche gli eventi sono tabulati in ordine cronologico, si
ha una informazione, benche minima, sull' ordine temporale degli eventi stessi.
Questo metodo di descrivere il protocollo di un bus e particolarmente interessante quando la logica di interfacciamento al bus e implementata in software:
Il diagramma si puo banalmente tradurre nel diagramma di usso di un
programma.
Le operazioni di ogni dispositivo sono elencate separatamente e sono
quindi piu facili da capire.
Gli eventi contemporanei sono mostrati chiaramente.
Nonostante questo, i diagrammi di sequenza hanno alcuna pesanti limitazioni:
La descrizione verbale delle operazioni e, oltre che non elegante, imprecisa
ed ambigua.
Mancano nel diagramma informazioni temporali precise.
Le transizioni dei segnali di controllo non sono indicate esplicitamente.
Le condizioni logiche degli ingressi e delle uscite di un circuito logico sequenziale
dicilmente indicano lo stato interno in maniera non ambigua.
1
44
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
Diagrammi di stato
I diagrammi di stato forniscono una descrizione completa e non ambigua delle
operazioni di un bus. Le operazioni di ogni dispositivo sono descritte da un
diverso diagramma di stato, ed in ogni diagramma sono indicati chiaramente
sia lo stato interno del dispositivo che le transizioni dei segnali di ingresso che
provocano un cambio di stato e la transizione dei segnali di uscita. Poiche i
diagrammi di stato de niscono la risposta dei dispositivi a tutti i segnali in tutti
i possibili stati, essi speci cano il protocollo del bus in maniera completa.
Sebbene siano completi e non ambigui, i diagrammi di stato sono dicili da
interpretare in termini di variazioni temporali dei segnali di controllo e possono
diventare oscuri se si mostrano tutte le transizioni. Per sempli carne la lettura,
si usano di solito dei diagrammi incompleti, che mostrano solo le transizioni
che avvengono in circostanze normali e se ne chiarisce l' interpretazione con
diagrammi temporali.
4.2 Modellazione dei componenti di un bus
Le MTPN costituiscono un buon modo per speci care il protocollo di un bus ed
il suo funzionamento, dato che mantengono l' espressivita dei diagrammi di stato
per quanto riguarda le transizioni dei segnali e allo stesso tempo evidenziano
le sequenze temporali ed i vincoli di temporizzazione a cui i segnali devono
sottostare. Inoltre la modularita delle MTPN permette di modellare e veri care
un aspetto del bus per volta e poi comporre i risultati in un modello completo
del bus.
In questa sezione vedremo come modellare con le MTPN le principali componenti di un bus per microcomputer, focalizzando l' attenzione sulle temporizzazioni e le sincronizzazioni tra i segnali di controllo.
Nella modellazione con le MTPN, i segnali sono rappresentati da piazze,
eventualmente importate, ed il livello del segnale e alto se la piazza contiene
un gettone, basso se la piazza e vuota. Inoltre si useranno spesso le funzioni di
abilitazione per abilitare la transizione di un certo segnale in base a condizioni
logiche sugli altri segnali.
4.2.1 Segnali di controllo per il trasferimento dati
Questi segnali di controllo presiedono al trasferimento dei dati. Prima di trasferire un dato e necessario speci care la sua sorgente o la sua destinazione,
ovvero l' indirizzo a cui il master si riferisce di solito il master pone l' indirizzo sulle linee del bus dati o di un bus indirizzi speci co prima di avviare il
trasferimento vero e proprio. Spesso sono necessarie altre informazioni prima
del trasferimento vero e proprio, come la direzione del trasferimento (lettura o
scrittura), il tipo di dispositivo coinvolto (mappato in memoria, nello spazio di
I/O, ecc), l' ampiezza del trasferimento (1, 2, 4 byte o piu), quali linee del bus
si usano, ecc. Quando tutto e pronto, occorrono altri segnali per coordinare
il trasferimento del dato tra il master e lo slave, se questi operano in maniera
asincrona.
45
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
Esistono sono tre modi di controllare il trasferimento dei dati: il trasferimento sincrono, asincrono e semisincrono18].
One-Way (Synchronous) Control
- DREQ
DREQ
master
slave
Figura 4.1. Trasferimento di dati sincrono
Il trasferimento sincrono e il metodo piu semplice e veloce di comunicare tra
dispositivi che operino a velocita comparabili. In questo schema (vedi gura
4.1) il master usa un solo segnale (DREQ) per comunicare allo slave l' inizio
di un trasferimento di dati e lo slave deve rispondere entro un tempo massimo
pre ssato. La rete di gura 4.2 presenta una possibile modello di una lettura
0 1]
t1
DREQ
t2
1 2 ]
DREQ
master
t3
3 4 ]
slave
Figura 4.2. Modello di un trasferimento di dati sincrono
di dati in modalita sincrona. La transizione t1 modella la necessita del master
di leggere un dato quando scatta, il master alza DREQ e dopo aver atteso
un tempo compreso tra 1 e 2 legge il dato e ritorna nella condizione iniziale.
Si noti che la lettura avviene (sulle linee del bus dati) con l' esecuzione di t1 ,
pertanto lo slave deve aver fornito il dato richiesto prima che t1 esegua. Tale
vincolo si traduce nella condizione 4 1 , imponendo che la transizione t3 ,
quella che rende disponibili i dati sul bus, esegua prima del tempo minimo
di durata per DREQ. Per quanto riguarda il modello del modulo slave, esso
puo assumere che il segnale DREQ, una volta asserito, resti asserito per un
intervallo di tempo a b ], con a 1 e b 2 , e tale assunzione si traduce
46
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
in vincoli nell' interfaccia attesa del modulo, come in tabella 4.1:
init . . . DREQ
0 1 . . . 1 1
1 1 . . . a b
"
DREQ
DREQ
"
#
DREQ
0 1
1 1
#
...
...
...
Tabella 4.1. Parte dell' interfaccia attesa dello schema di trasferimento
sincrono
Request/Acknowledge (Handshake) Control
- DREQ
DREQ
DRDY DRDY
master
slave
Figura 4.3. Trasferimento di dati asincrono
In questo caso il master e lo slave si servono di due linee di controllo (DREQ e
DRDY ) per segnalare rispettivamente la necessita di un dato e la disponibilita
a fornirlo (vedi gura 4.3). Di questo metodo esistono tre varianti, a seconda
di quanto strettamente sono legati il master e lo slave.
0 1]
t1
DREQ
DREQ
t2
1 2 ]
5 6 ]
t3
DRDY
t4
3 4 ]
DRDY
master
slave
Figura 4.4. Modello di un trasferimento di dati asincrono non-interlocking
La prima, in gura 4.4, e detta non-interlocking. In essa il master chiede un
dato alzando DREQ, aspetta che lo slave segnali la disponibilita del dato con
DRDY e legge il dato dopo un tempo pre ssato, modellato nella transizione
t2 . Lo slave si limita a rispondere a DREQ alzando, con il ritardo de nito in
t3 , il segnale DRDY e mantenendolo per il tempo de nito in t4 .
Puo succedere che lo slave tolga il dato prima che il master lo legga, causando
un errore di trasferimento.
La seconda, in gura 4.5, e detta half-interlocking. Adesso lo slave mantiene il
dato nche il master segnala la lettura abbassando DREQ. Nel modello cambia
47
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
0 1]
t1
5 6 ]
t3
DREQ
DREQ
DRDY
t4
t2
1 2 ]
3 4 ]
DRDY
master
slave
Figura 4.5. Modello di un trasferimento di dati asincrono half-interlocking
lo slave, in cui si aggiunge l' inibizione di t4 da parte di DREQ, che realizza
quanto detto.
Si puo avere ancora un errore se il master cerca di iniziare un' altro trasferimento prima che lo slave abbia completato il ciclo e sia tornato allo stato
iniziale. Il master interpreterebbe il DRDY residuo come una risposta al nuovo
DREQ e leggerebbe i dati sbagliati.
t1
0 1]
DREQ
t5
7 8 ]
t2
1 2 ]
DRDY
DREQ
t4
5 6 ]
t3
DRDY
3 4 ]
master
slave
Figura 4.6. Modello di un trasferimento di dati asincrono fully-interlocking
La soluzione fully-interlocking di gura 4.6 risolve il problema imponendo che il
master attenda che lo slave abbassi DRDY prima di iniziare un nuovo trasferimento. Nel modello, DRDY inibisce t3 che riporta il master allo stato iniziale,
mentre la lettura del dato avviene sempre con t2 .
Il limite maggiore della soluzione fully-interlocking e la riduzione della la
velocita di trasferimento, a causa degli ulteriori ritardi di propagazione nel bus
introdotti.
Semisynchronous Control
Il trasferimento semisincrono combina la velocita dei trasferimenti sincroni con
la capacita di sincronizzazione con i dispositivi piu lenti dei protocolli asincroni.
Normalmente il master legge i dati sul bus alla massima velocita possibile e sono
i dispositivi lenti a segnalare al master di aspettarli. In questo schema (vedi
48
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
- DREQ
DREQ
DRDY master CLK DRDY
- CLK
slave
CLK
clock
Figura 4.7. Trasferimento di dati semisincrono
gura 4.7) il ciclo di lettura si compone di due stati piu un terzo stato di wait.
Il master controlla il bus solo in corrispondenza dei fronti di discesa del clock e
se trova il segnale WAIT alto, entra nello stato di wait, aspettando il prossimo
ciclo per controllare se puo portare a termina la lettura.
Il modello in gura 4.8 e complicato dal generatore di clock (transizioni t5 e t6 ),
rappresentato da un oscillatore in cui il clock resta alto (un gettone in CLK )
per un periodo " e basso per T ; ".
4.2.2 Segnali di controllo per l' accesso al bus
Prima che un master possa iniziare un trasferimento di dati, esso deve ottenere
il controllo del bus. Questi segnali servono ad indicare quale master ha richiesto
il bus ed a stabilire la sua priorita nel caso ci siano altre richieste da servire.
Il controllo dell' accesso al bus puo essere centralizzato se l' arbitraggio e
gestito da un apposito controllore o decentralizzato se tutti i master possiedono
la logica necessaria a condividere il bus.
Gli schemi piu diusi per il controllo centralizzato dell' accesso al bus sono
tre: seriale con due linee, seriale con tre linee e parallelo a richieste indipendenti.
Two-wire Serial Control
Il controllore del bus usa due linee di controllo per comunicare con i master:
BREQ e BGNT . La linea di bus request e una linea di ingresso per il controllore
a cui i master sono collegati con un wired OR, in modo che tutti i master possano
leggerne lo stato ed asserirla. La linea di bus grant e un uscita del controllore
che si propaga tra i master con una daisy chain, in modo da realizzare un
meccanismo di priorita in cui il master piu vicino al controllore ha la priorita
piu alta.
Un master puo accedere al bus solo se ha asserito BREQ e rileva BGNT
alto in ingresso. Se un master non deve usare il bus, propaga BGNT in uscita
agli altri master della catena. Quando un master deve usare il bus, controlla che
entrambe le linee BREQ e BGNT in ingresso siano basse e poi alza BREQ.
Il controllore, non appena sente BREQ alta, alza a sua volta BGNT , che si
propaga nella catena no a raggiungere il master che ha generato la richiesta.
Adesso il master puo usare il bus, mantenendo BREQ alto no alla ne della
49
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
WAIT
3 4 ]
1 2 ]
5 6 ]
t3
CLK
t2
t4
DREQ
t1 0 1]
master
T ; " T ; "]
t6
CLK
t5
" "]
7 8 ]
DREQ
t7
clock
9 10 ]
WAIT
11 12 ]
t8
13 14 ]
t9
t10
CLK
slave
Figura 4.8. Modello di un trasferimento di dati semisincrono
BGNT
controller
BREQ - BGI
master1 BGO
BREQ
BR1
6
BREQ
?
- BGI
master2 BGO
BREQ
BR2
6
BR1 wiredOR BREQ
Figura 4.9. Arbitraggio seriale del bus con due linee
50
?
BR2
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
transazione. A questo punto abbassa BREQ e propaga BGNT in uscita. Il
controllore nega BGNT non appena rileva l' abbassamento di BREQ.
Nel modello di gura 4.10 si usano delle reti molto semplici per modellare i
segnali. Queste reti hanno generalmente una piazza corrispondente allo stato
della linea, una piazza corrispondente alla sua negazione e due transizioni che
si occupano di alzare ed abbassare il segnale. Associate a queste transizioni ci
sono due funzioni di abilitazione, che abilitano la transizione in accordo con la
logica che gestisce il segnale. Il tempo all' esecuzione di queste transizioni puo
essere usato per modellare i ritardi inseriti dalle porte necessarie a realizzare
praticamente il circuito.
La linea BREQ, che e realizzata con un wired OR, richiede un modulo di
gestione, poiche ogni modulo puo controllare solo le proprie piazze e transizioni,
limitando l' accesso alle altre alla sola lettura. Tale modulo controlla il segnale
BREQ, alzandolo appena una delle linee BRi si alza ed abbassandolo quando
nessuna e attiva.
Il master ha un segnale NEED che prima o poi si alza, segnalando la
necessita di usare il bus. Da quando il master ottiene il bus tramite la linea
BGI (il bus grant in ingresso), esso lo usa per l' intervallo stabilito da t6 e poi
lo rilascia.
Three-wire Serial Control
Le modalita di controllo del bus sono simili al caso a due linee, salvo la presenza
di BBSY , una terza linea di controllo in wired OR che segnala l' uso del bus
da parte di un master.
Quando un master ottiene l' accesso al bus, abbassa BREQ ed asserisce
BBSY , mantenendolo alto durante l' uso del bus. In questo schema i master
possono asserire BREQ in qualsiasi momento, ma devono negarlo non appena
ottengono il controllo del bus. Il controllore asserisce BGNT solo quando rileva
BREQ e BBSY e falso, e poi lo nega non appena il nuovo proprietario del bus
asserisce BBSY .
Il modello (vedi gura 4.12) e simile al caso precedente, cui si e aggiunto un
modulo per il controllo in wired OR di BBSY e si e modi cata la logica delle
transizioni in accordo con il nuovo comportamento.
Indipendent Request
In questo schema ogni master e collegato da due linee di controllo dedicate, BRi
e BGi, ed una condivisa, BBSY con il controllore del bus. Quando un master
i deve accedere al bus, asserisce la sua linea di bus request (BRi). Il controllore
confronta la priorita della richiesta con il proprietario attuale del bus e le altre
eventuali richieste: se la nuova richiesta ha la priorita piu alta, il controllore
nega il segnale di bus grant (BGj ) del master j corrente per spingerlo a rilasciare
il bus il prima possibile. Quando il master corrente libera il bus abbassando
BBSY , il controllore segnala la disponibilita del bus al master in attesa con la
priorita piu alta.
51
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
0 1]
t1
3 4 ]
t3
NEED
BGO
t2
1 2 ]
t4
5 6 ]
BGI
7 8 ]
t5
BREQ
BR
i
t6
9 10 ]
master
i
BREQ
11 12 ]
t7
BGNT
t8
13 14 ]
controller
15 16 ]
t9
BR1
BREQ
BR2
BR
t10
17 18 ]
n
wired OR
Figura 4.10. Modello di accesso al bus seriale a due linee
52
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
- BGI
BGNT
master1 BGO
BBSY BB1 BR1
6
controller
BBSY BREQ ?
?
- BGI
master2 BGO
BBSY BB2 BR2
6
?
?
BBSY BB1 BR1
BBSY BB2 BR2
BREQ
wiredOR
Figura 4.11. Arbitraggio seriale del bus con tre linee
0 1]
t1
3 4 ]
t3
NEED
BGO
BGI
t2
1 2 ]
11 12 ]
t7
t4
5 6 ]
7 8 ]
t5
BR
BBSY
BB
i
t8
13 14 ]
i
t6
9 10 ]
master
i
23 24 ]
t13
BREQ
BGNT
BBSY
t14
25 26 ]
controller
Figura 4.12. Modello di accesso al bus seriale a tre linee
53
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
master1
BG1
BR1
BB1
?
wired OR BB1
BG1
BG2
- BR1controllerBR2
BBSY
6
BBSY
- BG
2
BR2
BB2
master2
?
BB2
Figura 4.13. Arbitraggio del bus tramite richieste indipendenti
Nel modello di gura 4.14 si esempli ca il caso di un controllore che gestisca
no a due master. Si noti ancora il modulo wired OR per la gestione di BBSY .
4.2.3 Segnali di interruzione
I segnali visti no ad ora permettono ai master di comunicare con i dispositivi
slave. Questi segnali forniscono agli slave il mezzo per attirare l' attenzione dei
master, segnalando che sono pronti ad eettuare un trasferimento di dati. In
questo modo si evita che ogni master debba fare il polling dei dispositivi slave
per veri care se possono ricevere altri dati, con il conseguente spreco di risorse.
I segnali interruzione devono permettere di individuare il dispositivo slave che
ha segnalato l' interruzione e la sua priorita.
Gli schemi piu diusi sono due: richieste indipendenti ed interruzioni vettorizzate.
Indipendent Request
E' lo schema piu semplice, in cui ogni dispositivo e collegato da una linea
di interruzione dedicata con il master. Tale linea individua univocamente il
dispositivo che ha richiesto l' attenzione del master, che ne puo valutare la
priorita.
Daisy-chain Vectored Interrupt
In questo schema i dispositivi segnalano la richiesta di interruzione tramite
una linea comune IRQ di tipo wired OR. Quando il master riceve la richiesta,
completa la transazione in corso e risponde con un segnale di riconoscimento
IACK , che si propaga tramite una daisy-chain no al dispositivo a priorita piu
alta che ha richiesto una interruzione. Tale dispositivo fornisce al master un
codice di identi cazione tramite il bus dati, dove il master lo legge in maniera
solitamente sincrona. Una volta identi cato il dispositivo da servire, il master
nega IACK , acquisisce il bus ed inizia i trasferimenti necessari.
4.2.4 Segnali ausiliari
La maggior parte dei bus possiede delle linee usate da segnali di controllo utili
ma non necessari al corretto funzionamento del bus. Sebbene il numero e la
54
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
0 1]
t1
3 4 ]
t3
NEED
t2
1 2 ]
BR
i
BB
i
t4
5 6 ]
BG
7 8 ]
t5
i
t6
9 10 ]
master
i
BR1
11 12 ]
t7
BG1
t8
13 14 ]
BBSY
BR2
15 16 ]
t9
BG2
t10
17 18 ]
controller
Figura 4.14. Modello di accesso al bus tramite richieste indipendenti
55
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
IR1
slave1
- IR
1
master
IR2
IR2
slave2
Figura 4.15. Interruzioni tramite richieste indipendenti
1 2 ]
t1
IR1
IRQ
IR2
t2
2 3 ]
IR
n
master
Figura 4.16. Modello di interruzioni tramite richieste indipendenti
IACK
master
IRQ - IAI
IAO
slave1
IR1
IRQ
IR1
?
- IAI
slave2
wiredOR
Figura 4.17. Interruzioni vettorizzate
56
IAO
IR2
?
IR2
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
0 1]
t1
3 4 ]
t3
IR
i
IAO
IAI
t2
1 2 ]
t4
5 6 ]
slave
i
IRQ
11 12 ]
t7
IACK
t8
13 14 ]
master
Figura 4.18. Modello di interruzioni vettorizzate
funzione di questi segnali vari largamente da bus a bus, essi si possono riunire in
quattro gruppi: controllo del sistema, espansione degli indirizzi, controllo dell'
alimentazione ed alimentazioni ausiliarie.
System Synchronization and Control
Tutti i bus forniscono una linea di RESET che provoca l' inizializzazione dei
dispositivi connessi al bus. Tale segnale di solito e generato dal controllore
del bus subito dopo l' accensione o dopo un errore di sistema. Alcuni bus
hanno piu di una linea di reset per inizializzare indipendentemente diversi tipi
di dispositivi.
Inoltre molti bus forniscono il clock di sistema con cui sincronizzare tutte le
operazioni del bus ed un clock ausiliario, non sincronizzato con il primo, il cui
uso non e de nito nelle speci che.
Slave Addressing
Spesso un bus fornisce delle linee ausiliarie di controllo per espandere, migliorare od abilitare l' indirizzamento dei dispositivi slave. Tramite queste linee
si possono realizzare accessi alla memoria a pagine, abilitare delle mappe di
indirizzamento fantasma (di solito usate durante l' inizializzazione del sistema)
o realizzare degli accessi protetti.
57
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
Power Failure
Quasi tutti i sistemi industriali hanno bisogno di una linea che informi i dispositivi che sta per mancare l' alimentazione e che bisogna prendere provvedimenti
di emergenza. Tale linea e di solito generata dal modulo di alimentazione tramite un circuito che rileva la perdita della tensione di rete prima che la tensione
di sistema ne sia inuenzata. L' attivarsi di questo segnale indica che manchera
l' alimentazione entro un certo tempo. Spesso questo segnale controlla anche le
linee di reset, per inizializzare correttamente tutti i dispositivi dopo la perdita
dell' alimentazione.
Auxiliary Power and Ground
Alcuni bus forniscono su linee addizionali delle tensioni di alimentazione diverse
da quella di sistema, ad uso dei dispositivi collegati al bus.
4.3 Un' esempio: il bus VME
Il bus VME29] deriva dal bus proprietario VERSAbus di Motorola, nato per
interconnettere schede basate sulla famiglia di processori M68k, sia a 16 che a
32 bit. Una versione piu compatta venne sviluppata dalla Motorola di Monaco
e divenne uno standard europeo. Nel 1981 la Motorola, in collaborazione con
altre ditte europee, annuncio il bus VME come standard non proprietario ed
in seguito tale bus ha avuto una larga diusione soprattutto nel campo della
strumentazione automatica di misura.
Il bus VME supporta dispositivi a 8, 16 e 32 bit per le linee dati e permette
indirizzi a 16, 24 e 32 bit inoltre fornisce il supporto per sistemi multiprocessore.
Le schede sono connesse sicamente ad un backplane tramite due connettori a 96
pin, P 1 e P 2: il connettore P 1 contiene il bus primario, mentre P 2 e opzionale,
essendo necessario solo per espandere il bus a 32 bit di dati ed a 32 linee di
indirizzi.
4.3.1 Descrizione dei segnali del bus VME
Le linee possono essere pilotate da dispositivi con stadi di uscita open-collector
(OC), tristate (TS) oppure totem-pole (TP).
ACFAIL* (AC Failure, OC) Indica che l' alimentazione principale non e piu
disponibile.
AM0-AM5 (Address Modier, TS) Forniscono ulteriori informazioni sul bus indirizzi, come la dimensione, il tipo di ciclo, ecc.
AS* (Address Strobe, TS) Indica che il bus indirizzi contiene un indirizzo valido.
A01-A23 (Address Bus, TS) Prime 23 linee del bus indirizzi.
A24-A31 (Address Bus, TS) Linee di espansione del bus indirizzi.
58
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
(Bus Busy, OC) Indica che il bus dati e occupato dalla scheda che lo
genera.
BCLR* (Bus Clear, TP) Generato dal bus arbiter, indica che il possessore attuale
del bus dati deve lasciare l' uso del bus ad un master a priorita piu alta.
BERR* (Bus Error, OC) Indica un errore irrecuperabile durante un trasferimento dati, con la necessita di abortire il ciclo.
BG0IN*-BG3IN* (Bus Grant (0-3) In, TP) Formano insieme a BGxOUT** tre
daisy-chain per l' arbitraggio del bus. Indicano che la scheda puo diventare
il prossimo bus master.
BG0OUT*-BG3OUT* (Bus Grant (0-3) Out, TP) Formano insieme a BGxIN* tre
daisy-chain per l' arbitraggio del bus. Indicano che la scheda successiva
puo diventare il prossimo bus master.
BR0*-BR3* (Bus Request (0-3), OC) Indicano al bus arbiter che un bus master
richiede l' uso del bus.
DS0* (Data Strobe 0, TS) Indica, durante un trasferimento dati, che il trasferimento usera le linee dati D00-D07.
DS1* (Data Strobe 1, TS) Indica, durante un trasferimento dati, che il trasferimento usera le linee dati D08-D15.
DTACK* (Data Transfer Acknowledge, OC) Durante un ciclo di lettura indica
che sul bus dati sono disponibili dei dati validi, mentre in un ciclo di
scrittura indica che i dati sono stati accettati.
D00-D15 (Data Bus, TS) Linee bidirezionali per lo scambio di dati tra master
e slave.
D16-D31 (Data Bus, TS) Linee bidirezionali di espansione del bus dati.
GND (Ground) Linea di massa.
IACK* (Interrupt Acknowledge, OC) Segnala il trattamento da parte di un master di una richiesta di interruzione: e trasportato dal backplane no al
primo slot dove inizia la daisy-chain del riconoscimento di interruzione.
IACKIN* (Interrupt Acknowledge In, TP) Forma insieme a IACKOUT* una daisychain ed indica alla scheda che e in corso un ciclo di riconoscimento di
interruzione.
IACKOUT* (Interrupt Acknowledge Out, TP) Forma insieme a IACKIN* una
daisy-chain ed indica alla scheda successiva che e in corso un ciclo di
riconoscimento di interruzione.
IRQ1*-IRQ7* (Interrupt Request (1-7), OC) Indicano la richiesta di interruzione da parte di un dispositivo: IRQ7* ha la priorita piu alta.
BBSY*
59
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
(Longword, TS) Indica che il trasferimento di dati in corso e a 32 bit.
SERCLK (Serial Clock, TP) E' un segnale riservato all' uso come linea di clock
nel protocollo di comunicazione seriale VMS.
SERDAT (Serial Data, OC) E' un segnale riservato all' uso come linea dati nel
protocollo di comunicazione seriale VMS.
SYSCLK (System Clock, TP) E' un segnale di clock a 16 MHz indipendente dalla
velocita del processore, usato per generiche temporizzazioni.
SYSFAIL* (System Fail, OC) Indica un malfunzionamento del sistema e pu
o
essere generato da qualunque scheda.
SYSRESET* (System Reset, OC) Provoca il reset del sistema.
WRITE* (Write, TS) Speci ca il tipo di trasferimento dati: alto per operazioni
di lettura e basso per operazioni di scrittura.
+5V STDBY (+5 Vdc Standby) Fornisce +5 Vdc ai dispositivi che richiedono una
batteria tampone.
+5V (+5Vdc Power) Alimentazione a +5Vdc.
+12V (+12Vdc Power) Alimentazione a +12Vdc.
-12V (-12Vdc Power) Alimentazione a -12Vdc.
LWORD*
4.3.2 Funzionamento del bus VME
Le linee del bus VME possono essere raggruppate in diverse categorie: linee
indirizzi, linee dati, linee di interruzione e controllo, linee di arbitraggio del bus
e linee di utilita. Le linee indirizzi e dati sono pilotate da dispositivi tristate
mentre la maggior parte delle linee di controllo sono pilotate da dispositivi
open-collector.
Il bus principale ha 23 linee indirizzi, A01-A23. Includendo il bus opzionale
si aggiungono altre 8 linee, A24-A31, per l' indirizzamenti no a 4 gigabyte.
Le linee indirizzi sono pilotate dal bus master per speci care la locazione della
word (16 bit) a cui si vuole accedere. Oltre all' indirizzo si usano i segnali DS0*
e DS1* per selezionare la parte da trasferire: byte basso, byte alto o tutta la
word. Insieme all' indirizzo il master usa AS* per segnalare un indirizzo valido
ed un modi catore a 6 bit, AM0-AM5, ad indicare la dimensione ed il tipo di
accesso (accesso dati, accesso programma, accesso protetto, ecc).
Il bus dati principale e composto da 16 linee bidirezionali, D00-D15, di cui
le prime otto sono usate in sistemi a 8 bit. Il supporto di dispositivi a 32 bit si
ha con l' aggiunta del bus opzionale, che fornisce le linee necessarie, D16-D31.
Un trasferimento a 32 bit e indicato dal bus master con il segnale LWORD*.
Si noti che un trasferimento a 32 bit puo essere eettuato solo ad indirizzi
divisibili per 4. Il trasferimento dei dati nel bus VME avviene in modalita
fully-interlocking. Il master usa il segnale WRITE* per speci care una lettura
60
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
(WRITE* alto) od una scrittura (WRITE* basso), mentre lo slave usa DTACK* per
terminare il trasferimento.
Per gestire con gurazioni multiprocessore, sono fornite 14 linee per l' arbitraggio del bus, gestite generalmente da un arbitro nel modulo di controllo del
sistema. L' arbitraggio avviene con lo schema seriale a tre linee con quattro
livelli di priorita. Un bus master puo richiedere il controllo del bus tramite
una delle quattro linee di richiesta, BR0*-BR3*. Ogni linea di richiesta corrisponde ad una linea di grant che e gestita con una daisy-chain tramite le linee
BGxIT/OUT. Il master che riceve il segnale di bus grant asserisce BBSY* e non
propaga il grant ai moduli successivi nella catena. Il controllo del bus resta al
master nche questo non lo lascia negando BBSY*. L' arbitro puo risolvere i
conitti tra le richieste con uno di tre schemi diversi. L' arbitraggio a priorita
assegna il bus sulla base di priorita sse, con la linea 3 che indica la priorita
piu alta in questo caso l' arbitro usa BCLR* per informare il master corrente
che deve rilasciare il bus ad un modulo a priorita piu alta. Nell' arbitraggio
round-robin il master che ha ottenuto il controllo per ultimo ha la priorita piu
bassa nel successivo ciclo di arbitraggio. L' arbitraggio ad un solo livello usa
una sola linea BR3* per le richieste ed assegna le priorita in base al solo ordine
nella daisy-chain.
Il bus VME supporta interruzioni con priorita vettorizzate. Sette linee di
richiesta di interruzione, IRQ1*-IRQ7*, sono a disposizione di un master per
ricevere richieste, con la linea 7 alla priorita piu alta. Alla richiesta di interruzione il master risponde con un codice di livello sulle linee A01-A03 lo slave
decodi ca il codice e controlla il segnale di riconoscimento della daisy-chain
IACKIN*: se il livello della richiesta non corrisponde al livello indicato dal master, lo slave passa il segnale di riconoscimento al modulo successivo nella catena
tramite IACKOUT*, altrimenti invia al master il suo codice di interruzione sulle
linee D00-D08.
4.3.3 Il protocollo per il trasferimento dati nel bus VME
data
control
READWRITE-
DONE
.
data
master
AS DS 0 WRITEDTACK
data
slave
Figura 4.19. Modello di lettura di un byte nel bus VME
In gura 4.19 vediamo lo schema dei moduli necessari a modellare un trasferimento di un byte da un dispositivo slave ad un master (lettura). Nel modello
sono presenti solo le linee di controllo interessate nel trasferimento.
Il modulo Data Control comanda una lettura od una scrittura al modulo
Data Master asserendo READ o WRITE no a che il il master non risponde
61
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
asserendo DONE naturalmente si suppone che il modulo di controllo abbia
gia ottenuto il controllo del bus ed abbia posto l' indirizzo giusto sul bus nel
momento che comanda la lettura. Il modulo Data Master funge da interfaccia
tra il bus ed il modulo di controllo, gestendo i dettagli della comunicazione con
il Data Slave e comunicando con DONE che il dato e disponibile sul bus.
Data Control
0 1]
t0
data control
READ
1 2]
t1
DONE
Figura 4.20. Modello del modulo di controllo del trasferimento dati su bus VME
Il modulo di gura 4.20 modella un controller che deve eettuare una sola lettura da un modulo slave. Prima o poi t0 esegue, comandando la lettura tramite
il segnale READ, segnale che viene disasserito non appena il modulo di interfaccia risponde con DONE . In questo semplice esempio si suppone che tutti i
segnali cambino stato in un intervallo di tempo 1 2], ed e questo l' intervallo
di esecuzione che che e assegnato a tutte le transizioni che gestiscono i segnali.
L' interfaccia attesa del modulo speci ca semplicemente che il segnale DONE
si alza dopo che READ va alto e si abbassa dopo che READ e tornato basso
(vedi tabella 4.2). Si noti che poiche il bus VME e completamente asincrono, il
tempo minimo di attesa ad un segnale e il tempo minimo che impiega il segnale
a commutare (di norma 1), mentre il massimo e 1.
init DONE
1 1 1 1
1 1 |
"
DONE
DONE
"
#
DONE
#
|
1 1
t0
1 1
|
t1
|
0 1
Tabella 4.2. L' interfaccia attesa del modulo Data Control
Data Master
Il modulo di gura 4.21 modella l' interfaccia tra il controller ed il dispositivo
slave. In risposta ad un comando di lettura, il modulo asserisce prima AS
e poi DS 0 ed aspetta che lo slave asserisca DTACK per asserire DONE .
Si noti come le transizioni relative alla piazza CY CLE (che segnala l' inizio
di un ciclo di accesso alla memoria) ed alla piazza DONE abbiano tempi di
esecuzione istantanei, dato che non modellano segnali sici ma servono a mantenere le temporizzazioni. L' interfaccia attesa del modulo speci ca che il segnale
DTACK si alza dopo AS e torna basso dopo che DS 0 e tornato basso e
che i segnali READ e WRITE sono mutualmente esclusivi e tornano bassi in
risposta a DONE (vedi tabella 4.2).
62
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
1 2]
t2
DTACK
AS
t3
1 2]
1 2]
t0
READ
WRITE
1 2]
t4
DS 0
0 0] t8
t5
1 2]
WRITE
t1
1 2]
DONE
0 0]
t6
t7
1 2]
CY CLE
data master
Figura 4.21. Modello del modulo master nel trasferimento dati su bus VME
63
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
init DTACK
1 1 1 1
1 1 |
DTACK
"
DTACK
DTACK
"
#
init READ
1 1 1 1
1 1 |
1 1 1 1
1 1 |
"
READ
READ
WRITE
WRITE
"
#
"
#
t2
#
1 1
READ
1 1
1 1
#
|
|
t5
1 1 |
| 1 1
|
WRITE
1 1
WRITE
|
1 1
"
t8
#
|
|
1 1
|
1 1
|
1 1
|
1 1
Tabella 4.3. L' interfaccia attesa del modulo Data Master
Data Slave
1 2]
t0
AS
DTACK
t1
1 2]
t2
1 2]
DS 0
WRITE
data slave
Figura 4.22. Modello del modulo slave nel trasferimento dati su bus VME
Il modulo di gura 4.22 modella il dispositivo slave che risponde ad un comando
di lettura ponendo sul bus dati il byte richiesto. Il segnale DTACK puo
essere asserito in seguito ad una lettura od in seguito ad una scrittura, e le due
transizioni t1 e t2 modellano i due casi in maniera distinta per permettere tempi
di risposta diversi. Il segnale DTACK torna alto dopo che sia AS che DS 0
sono tornati alti.
L' interfaccia attesa del modulo speci ca che AS precede DS 0 e che entrambi tornano alti dopo che lo slave ha asserito DTACK . Il segnale WRITE
e completamente asincrono e l' unico vincolo impedisce l' accumulo di gettoni
nella piazza importata (vedi tabella 4.4).
64
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
init AS
AS DS 0 DS 0
t1
t2
1 1 1 1 | | | 1 1 1 1
1 1 1 1 1 1
|
|
|
|
1 1 | | 1 1 | 1 1 1 1
1 1 | 1 1 | 1 1 | |
"
AS
AS
DS 0
DS 0
"
#
"
#
WRITE
WRITE
"
#
#
"
init WRITE
1 1 1 1
1 1
1 1
"
#
WRITE
1 1
1 1
#
Tabella 4.4. L' interfaccia attesa del modulo Data Slave
Analisi del modello di trasferimento dati su bus VME
L' analisi dei singoli moduli che compongono il modello di trasferimento dati sul
bus VME con le rispettive interfacce attese produce tre gra di raggiungibilita
che contengono tutti gli stati in cui il modello si puo trovare in seguito a tutte
le combinazioni possibili di segnali in ingresso. Il modello del modulo Data
Control produce 5 stati, il modello del modulo Data Master produce 87 stati e
quello del modulo Data Slave produce 57 stati.
Integrando questi tre gra si ottiene il grafo del sistema completo, che esprime le possibili sequenze di segnali durante la lettura, fornendo anche informazioni sulle temporizzazioni di tali segnali. Il grafo integrato risulta composto di
25 stati.
4.3.4 Il protocollo per l' arbitraggio nel bus VME
bus
control
NEED-
OWN
.
bus
master
BR3 BG3
BBSYBCLR
bus
arbiter
Figura 4.23. Modello dell' arbitraggio del bus VME
In gura 4.23 vediamo lo schema dei moduli necessari a modellare l' arbitraggio
del bus, nel caso in cui un solo master debba ottenere l' accesso.
Il modulo Bus Control comanda al modulo Bus Master di prendere il controllo del bus tramite il segnale NEED. Il modulo Bus Master inizia un ciclo
di arbitraggio con il modulo Bus Arbiter ed alla ne, quando ha ottenuto il
bus, segnala il possesso asserendo OWN . Il Bus Arbiter usa il meccanismo a
priorita sse, ed il master ha la priorita piu alta.
65
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
Bus Control
0 1]
t0
bus control
10 20]
t1
NEED
OWN
Figura 4.24. Modello del modulo di controllo dell' arbitraggio del bus VME
Il modulo di gura 4.24 modella un dispositivo che ha bisogno del bus per
un periodo di tempo compreso nell' intervallo 10 20]. Prima o poi t0 esegue,
comandando l' acquisizione del bus tramite il segnale NEED, segnale che viene
disasserito dopo un tempo compreso tra 10 e 20 da quando il modulo ottiene il
bus. L' interfaccia attesa del modulo speci ca che il segnale OWN si alza dopo
che NEED va alto e si abbassa dopo che NEED e tornato basso (vedi tabella
4.5).
init OWN
1 1 1 1
1 1 |
OWN
"
OWN
OWN
"
#
#
|
1 1
t0
1 1
|
t1
|
0 1
Tabella 4.5. L' interfaccia attesa del modulo Bus Control
Bus Master
Il modulo di gura 4.25 modella l' interfaccia tra il dispositivo di controllo e
l' arbitro del bus VME. Il modulo asserisce BGiOUT solo se riceve BGiIN
e non ha bisogno del bus. Il segnale BRi viene asserito quando il modulo
ha bisogno del bus, e resta asserito nche non arriva BGiIN ed il modulo
occupa il bus asserendo BBSY . Il segnale BBSY e piu complesso, dato che
si puo rilasciare il bus anche in seguito ad un BCLR , oltre che all' abbassarsi
di NEED. Inoltre il modulo deve aspettare a segnalare OWN no a che il
master corrente non ha concluso la sua operazione, ovvero no a che AS non
viene disasserito.
L' interfaccia attesa del modulo speci ca che il segnale BGiIN puo arrivare normalmente in qualunque momento e risalire dopo che il modulo lo ha
propagato con BGiOUT . Se il modulo richiede il bus con BRi , ci si aspetta
ancora BGiIN , che risale dopo che BRi e stato negato. Il segnale BCLR
puo essere asserito in qualunque momento, e risale dopo che il modulo ha lasciato il bus alzando BBSY . Il segnale AS e completamente asincrono rispetto
al modulo.
66
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
1 2]
t0
1 2]
t2
BGiOUT
BRi
t1
1 2]
BGiIN NEED
t3
1 2]
1 2]
t4
OWN
t7 1 2]
BCLR
AS
t5
1 2]
t8
0 0]
BBSY
1 2]
t6
bus master
Figura 4.25. Modello del modulo master nell' arbitraggio del bus VME
67
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
BGiIN
BGiIN
AS
AS
init BGiIN
1 1 1 1
1 1
1 1
1 1 |
1 1
|
"
#
"
#
"
BCLR
BCLR
NEED
NEED
#
"
#
#
|
|
init BCLR
1 1 1 1
1 1
1 1
1 1
|
1 1 |
"
"
BGiIN
1 1
1 1
BCLR
#
|
1 1
|
|
AS
AS
"
|
|
#
|
|
1 1
1 1
1 1 1 1
t1
NEED
NEED
1 1
1 1
1 1
"
|
|
t2
t3
1 1 1 1 |
|
| 1 1
|
|
|
|
|
|
#
|
|
1 1
t5
t7
1 1 |
|
|
|
|
| 1 1
Tabella 4.6. L' interfaccia attesa del modulo Bus Master
Bus Arbiter
t6
1 2]
OWN 2
t8
1 2]
1 2]
t12
BG2
BR2
t7
1 2]
t9
1 2]
OWN 3
t11
1 2]
BCLR
t13
1 2]
BBSY
BG3
BR3
t10
1 2]
bus arbiter
Figura 4.26. Modello parziale del modulo arbitro del bus VME
Il modulo di gura 4.26 modella l' arbitro del bus VME. Per semplicita si
mostrano solo i segnali dei due livelli piu alti di priorita, BG2 e BG3 . Le
piazze OWN 2 e OWN 3 contengono un gettone se il bus e usato da un master
68
CAPITOLO 4. MODELLAZIONE DI BUS CON MTPN
nella rispettiva catena di daisy-chain e vengono usate per forzare il rilascio del
bus in presenza di una richiesta a piu alta priorita tramite il segnale BCLR .
Il segnale BGi viene asserito in presenza di una richiesta su BRi se il bus e
libero (BBSY alto) e nessuno dei master a priorita piu alta lo richiede.
L' interfaccia attesa del modulo speci ca che le richieste BRi possono arrivare in qualunque momento e restare asserite no a che il master non ottiene
il bus tramite BGi . Il segnale BBSY si abbassa dopo un BGi ed e forzato
a tornare alto da un BCLR .
init BRi BRi BBSY
1 1 1 1 |
|
1 1 1 1 1 1
|
1 1 | | 1 1
1 1 | |
|
"
BRi
BRi
BBSY
BBSY
"
#
"
#
#
"
BBSY
#
|
|
1 1
1 1
BGi
1 1
#
|
|
1 1
BCLR
#
|
|
1 1
|
Tabella 4.7. L' interfaccia attesa del modulo Bus Arbiter
Analisi del modello di arbitraggio del bus VME
Il modello dell' arbitro del bus VME e stato analizzato nella sua forma completa,
restringendo solamente l' interfaccia attesa dell' arbitro per mantenere sempre
alti i due ingressi BR0 e BR1 . Anche con queste riduzioni il grafo risultante
e sempre piuttosto vasto, essendo composto da 655 stati. Il grafo del modulo
di controllo e ovviamente molto piu semplice, consistendo in solo 5 stati. Il
modulo master risulta di gran lunga il piu vasto, anche a causa dei segnali AS
e BCLR che sono quasi completamente asincroni, risultando composto da piu
di 7700 stati.
Integrando i tre gra si ottiene il grafo del sistema completo, in cui il numero
di stati cala drasticamente grazie al fatto che i moduli sono asserviti ad un
controllo molto semplice, arrivando ad appena 12 stati diversi.
69
Capitolo 5
Sistema software
Le tecniche di analisi di Modular Time Petri Net illustrate nei capitoli precedenti sono state implementate in un sistema software con l' obiettivo di formare
il nucleo di base per un futuro ambiente gra co per l' editing e la veri ca di
modelli di Reti di Petri.
Il sistema e stato sviluppato con il linguaggio C++39], per garantire una
facile integrazione in un sistema piu complesso ed una reale trasportabilita
dei sorgenti su macchine diverse. In particolare, il sistema, sviluppato con un
Amiga 4000 sotto AmigaOS 3.1, e stato usato compilato senza modi che anche
su workstation Sun con SunOS 5.1, ed e facilmente compilabile in qualsiasi
piattaforma per la quale sia disponibile un compilatore C++.
In accordo con le metodologie di programmazione ad oggetti, il sistema e
organizzato come una gerarchia di classi collegate ciascuna corrispondente ad
un oggetto ben de nito e separato dagli altri. Queste classi permettono da una
parte di descrivere il sistema in termini di reti ed interfacce (oerte od attese),
e dall' altra forniscono i metodi necessari alla loro analisi, come ad esempio i
costruttori di un grafo degli stati a partire da una rete.
In tal modo l' analisi di una rete si realizza tramite la compilazione di un
programma che descrive la rete e richiama i metodi necessari alla sua analisi.
5.1 Le classi implementate
Il sistema fornisce una classe per ogni tipo di oggetto, ed ogni oggetto fornisce
i metodi necessari alla sua analisi e stampa (vedi gura 5.1).
Le classi possono essere divise in tre gruppi: classi base, gra di stati, classi
di analisi.
5.1.1 Classi base
Le classi base comprendono sia dei tipi de niti dall' utente che delle classi che
servono a descrivere il sistema da analizzare.
Il tipo tempo e usato diusamente e permette, tramite l' overloading di alcuni operatori, di trattare automaticamente in maniera speciale sia le operazioni che coinvolgono tempi in niti che le operazioni di ingresso/uscita.
70
CAPITOLO 5. SISTEMA SOFTWARE
IntegNode
StateSetNode
PINode
? ? ?
- StateNode
6 6
Trace
6
TPNNode
StateLink
-
Domain
6
TraceSetNode
Profile
-
StateGraph
6 6 6
-
StateSet
IntegGraph
PIGraph
TPNGraph
IntegData
ProvidedIface
TPN
?
?
?
Figura 5.1. Grafo delle classi. Gli archi a tratto continuo denotano relazioni di
specializzazione, quelli a tratteggio indicano relazioni di uso.
Poiche il tipo di analisi che si eettua sulle MTPN e centrato sulle transizioni, ad esse si deve spesso far riferimento attraverso un nome unico in
tutto il sistema. Il tipo TName serve a tenere questo nome, che al momento
e semplicemente un numero ed una etichetta (tag), che identi ca il tipo
di transizione cui il nome si riferisce, ma che potrebbe essere esteso ad un
nome simbolico, magari tramite una hash table globale.
Nel sistema spesso si usano contenitori per oggetti piu complessi come i
nodi dei gra , gli elementi degli insiemi, ecc. A tal ne si usano delle
normali liste doppie concatenate.
I domini di esecuzione si rappresentano tramite un Domain, che fornisce
anche i metodi necessari alla normalizzazione.
Gli oggetti da analizzare sono rappresentati da una TPN oppure da una
ProvidedIface, che forniscono, oltre ai metodi necessari alla propria
costruzione, anche i metodi che permettono l' esecuzione di transizioni
aggiornando gli stati interni.
5.1.2 Classi dei gra degli stati
Le classi dei gra degli stati (TPNGraph, PIGraph, IntegGraph), sono specializzazioni di StateGraph tramite l' aggiunta di un costruttore speci co per il tipo
di grafo:
TPNGraph si costruisce partendo da una TPN.
PIGraph si costruisce da una ProvidedIface.
71
CAPITOLO 5. SISTEMA SOFTWARE
si costruisce da un vettore di StateGraph, che possono naturalmente essere sia gra di reti, che gra di interfacce oerte, che ancora
gra di integrazione.
Queste classi fanno uso di altre classi minori per rappresentare i nodi del grafo,
gli insiemi dei nodi, ecc. A tutti i costruttori di queste classi si puo passare
il livello massimo di profondita del grafo cui deve arrivare l' analisi. Se un
costruttore si ferma prima di aver completato il grafo, la costruzione si puo
riprendere ed approfondire con GrowToLevel().
Per applicare gli strumenti di analisi realizzati per le MTPN ad altri tipi
di sistemi che siano riconducibili ad un grafo di stati e transizioni, e suciente
aggiungere a questo gruppo una nuova classe derivata da StateGraph con il
relativo costruttore per poter analizzare sia i nuovi sistemi che sistemi misti.
IntegGraph
5.1.3 Classi di analisi
Le classi di analisi permettono di ottenere informazioni sul sistema partendo
dal grafo del suo modello.
Tramite la classe Trace e possibile rappresentare una traccia di esecuzione
sul grafo e stimarne la durata con l' algoritmo a stato singolo, mentre per
determinare i limiti ottimi sulla durata di una traccia si deve usare la classe
Profile. La funzione GrowTraces() permette di costruire tutte le tracce di un
grafo che terminano con l' esecuzione di una certa transizione. Questa funzione
viene usata dal costruttore di ProvidedIface per calcolare l' interfaccia attesa
direttamente da un grafo qualunque.
A questo gruppo si potrebbero aggiungere strumenti di attraversamento del
grafo mirati alla veri ca di determinate condizioni come l' assenza di deadlock,
il rispetto di vincoli temporali, ecc.
5.2 Documentazione delle Classi
Diamo adesso una documentazione completa di tutte le classi del sistema, fornendo di ognuna una descrizione del funzionamento, una lista dei dati interni
ed una lista dei metodi che supporta.
72
CAPITOLO 5. SISTEMA SOFTWARE
Classe tempo
Superclassi: Sottoclassi: Usa: Usata in: TPN, Domain, StateGraph, Trace, ProvidedIface.
Descrizione:
Estende un tipo standard (normalmente un intero) per rappresentare un
tempo, che puo anche essere 1, e le operazioni che sul tempo si possono
fare. Il tipo di base e de nito tramite il tipo ausiliario TEMPOT, ed il
valore di 1 e il massimo valore rappresentabile in un TEMPOT, de nito
con la costante INF.
Il tipo tempo supporta operazioni di I/O, confronto e somma/sottrazione.
Dati:
TEMPOT t
E' il valore del tempo.
Metodi:
tempo(TEMPOT i)
Costruisce un tempo a partire dal tipo base.
tempo operator+(tempo a, tempo b)
Somma due tempi considerando che 1 + i = 1.
tempo operator-(tempo a, tempo b)
Sottrae due tempi considerando che 1 ; i = 1 ed i ; 1 = ;1.
ostream& operator<<(ostream& s, tempo a)
Inserisce un tempo in un usso di uscita, rappresentando 1
\INF".
come
istream& operator>>(istream& s, tempo &a)
Legge un tempo da un usso di ingresso, interpretando \INF" o \inf"
come 1.
73
CAPITOLO 5. SISTEMA SOFTWARE
Classe TName
Superclassi: Sottoclassi: Usa: Usata in: TPN, Domain, StateGraph, Channel, Trace, ProvidedIface.
Descrizione:
Serve a memorizzare in un unico oggetto sia il nome di una transizione
(un numero), che il suo tipo. Esistono transizioni normali (T_T), importate (T_I), di incremento (T_U) e di decremento (T_D). Ci sono poi due
transizioni speciali: TINIT e la transizioni iniziale e TNONE e usata per i
fallimenti nelle ricerche. Supporta assegnamenti, confronti e operazioni
di I/O.
Dati:
int n
In un unico intero si memorizza sia il tipo che il numero.
Metodi:
TName(int ty, int t)
Costruisce il nome partendo dal numero e dal tipo.
int Name()
Ritorna il numero della transizione.
int Type()
Ritorna il tipo della transizione.
ostream& operator<<(ostream& s, TName a)
Inserisce un TName in un usso di uscita, rappresentando
un carattere di pre sso al numero della transizione.
istream& operator>>(istream& s, TName &a)
Legge un TName da un usso di ingresso, interpretando
il tipo con
il primo carattere come il tipo della transizioni, che deve essere seguito dal suo
numero.
74
CAPITOLO 5. SISTEMA SOFTWARE
Classe Domain
Superclassi: Sottoclassi: Usa: tempo, TName.
Usata in: StateNode, Profile.
Descrizione:
Implementa i domini di esecuzione. I nomi delle transizioni sono memorizzati in un vettore nel seguente ordine: per prime le transizioni persistenti,
seguite da quelle appena abilitate, da quelle persistenti slave ed in ne da
quelle slave appena abilitate.
I vincoli semplici sono memorizzati in due vettori, mentre quelli incrociati sono memorizzati in una matrice implementata tramite un vettore di
dimensione adeguata.
Dati:
int N
Numero delle transizioni (e quindi delle incognite).
int P
Indice della ne delle transizioni persistenti.
int E
Indice della ne delle transizioni appena abilitate.
int SP
Indice della ne delle transizioni slave persistenti.
int S
Indice della ne delle transizioni slave appena abilitate.
TName* Trans
Vettore dei nomi delle transizioni.
tempo* pa
Vettore dei coecienti semplici.
tempo* pb
Vettore dei coecienti semplici.
tempo* paa
Vettore dei coecienti incrociati.
tempo* pbb
Vettore dei coecienti incrociati.
Metodi:
Domain(int n, int p=0)
Costruisce il Domain allocando i vettori e partizionando le transizioni:
p
e l' indice della ne delle transizioni persistenti, mentre n e l' indice
della ne di quelle appena abilitate.
75
CAPITOLO 5. SISTEMA SOFTWARE
Domain(const Domain&)
Costruttore di copia, alloca un nuovo Domain e ci ricopia l' argomento.
Domain()
Distruttore, libera la memoria usata dai vettori.
void SetSize(int n, int p=0)
Ridimensiona il Domain liberando
seguito della nuova dimensione.
prima i vettori e riallocandoli in
void SetPart(int p, int e, int sp, int s)
Partiziona il Domain : p e il numero delle transizioni persistenti, e
quello delle transizioni appena abilitate, sp quello delle transizioni
slave persistenti e s e quello delle transizioni slave appena abilitate.
int idx(TName t)
Ritorna l' indice della transizione di nome t o -1 se la transizione
non appartiene al dominio.
TName& trn(int i)
Ritorna il nome della transizione di indice i.
tempo& a(int i)
Accede al limite inferiore del vincolo sulla transizione di indice i.
tempo& b(int i)
Accede al limite superiore del vincolo sulla transizione di indice i.
tempo& a(int i, int j)
Accede al limite inferiore del vincolo incrociato sulle transizioni di
indice i e j.
tempo& b(int i, int j)
Accede al limite superiore del vincolo incrociato sulle transizioni di
indice i e j.
int TrnCnt()
Ritorna il numero di transizioni nel dominio.
int PerstCnt()
Ritorna l' indice della ne delle transizioni persistenti.
int EnbldCnt()
Ritorna l' indice della ne delle transizioni appena abilitate (numero
di transizioni abilitate).
int SlaveCnt()
Ritorna l' indice della ne delle transizioni slave appena abilitate.
tempo minb()
Ritorna il minimo tra i coecienti superiori dei vincoli del dominio.
tempo maxa()
Ritorna il massimo tra i coecienti inferiori dei vincoli del dominio.
void Minimize()
Riduce il dominio in forma minima, operando solo sulle transizioni
non slave.
76
CAPITOLO 5. SISTEMA SOFTWARE
void Normalize()
Riduce il dominio in forma normale, operando solo sulle transizioni
non slave. Prima di ridurlo in forma normale, lo minimizza con
Minimize().
bool CanFire(TName t)
Veri ca se il dominio consente l' esecuzione della transizione non
slave di nome t.
void Restrict(TName t)
Restringe il dominio con la condizione che la transizione non slave di
nome t esegue per prima. Il dominio deve essere in forma normale e
ritorna in forma normale.
void SyncMasterSlave(TName m, TName s)
Impone la sincronizzazione tra le due transizioni di nome m e s,
aggiungendo il vincolo che eseguano allo stesso tempo. Il dominio
risultante non e in forma normale.
void SlaveRestrict(TName t)
Restringe il dominio con la condizione che la transizione slave di
nome t esegue per prima. Il dominio deve essere in forma normale e
ritorna in forma normale.
void SlaveMinimize()
Riduce il dominio in forma minima, operando solo sui vincoli delle
transizioni slave.
void SlaveNormalize()
Riduce il dominio in forma normale, operando solo sui vincoli delle
transizioni slave. Prima di ridurlo in forma normale, lo minimizza
con SlaveMinimize().
bool IsNormal()
Veri ca se un dominio normalizzato con SlaveNormalize() e eettivamente ridotto in forma normale.
int operator==(Domain &x, Domain &y)
Operatore di confronto tra due domini: confronta i nomi delle transizioni, il modo in cui sono partizionate ed i loro vincoli.
ostream& operator<<(ostream& s, Domain& d)
Operatore di uscita: inserisce in un usso di uscita il dominio, stampando un vincolo per linee, prima tutti quelli semplici e poi quelli
incrociati. Non stampa i vincoli sulle transizioni slave.
77
CAPITOLO 5. SISTEMA SOFTWARE
Superclassi: Sottoclassi: Usa: tempo, TName.
Usata in: TPNGraph.
Descrizione:
Classe TPN
Implementa una Time Petri Net. Essa e rappresentata con un vettore di
struct Transition ed un vettore di struct Place, in cui si memorizza
lo stato delle transizioni e delle piazze. Per ogni piazza si memorizza il
numero di gettoni che contiene, mentre per ogni transizione si memorizza
l' intervallo di esecuzione e si include sia un vettore di archi, che contiene
i collegamenti tra la transizione e tutte le altre piazze, che un vettore
contenente i nuovi intervalli di esecuzione da associare alle transizioni di
interfaccia all' esecuzione della transizione in esame.
Nella TPN si memorizza sia lo stato iniziale che lo stato dinamico. Nello
stato dinamico sono inclusi 3 vettori con i nomi delle transizioni che,
dopo l' esecuzione di una transizione, sono abilitate, persistenti e appena
abilitate.
Esistono dei metodi privati, con il nome tutto minuscolo, che richiedono
l' indice della transizione invece del suo nome generale.
Dati:
int Trans
Numero di transizioni vere.
int Places
Numero di piazze vere.
int gTrans
Numero di transizioni fantasma.
int gPlaces
Numero di piazze fantasma.
int ITrans
Numero di transizioni di interfaccia.
int IPlaces
Numero di piazze di interfaccia.
struct Transition* TransArray
Vettore di transizioni.
struct Place* PlaceArray
Vettore di piazze
bool EnabledValid
Segnala la validita delle variabili relative alle transizioni abilitate.
78
CAPITOLO 5. SISTEMA SOFTWARE
int EnabledCount
Numero di transizioni abilitate.
int NewlyEnabledCount
Numero di transizioni appena abilitate.
int PersistentCount
Numero di transizioni persistenti.
int* enbldarray
Vettore di transizioni abilitate.
int* newlyarray
Vettore di transizioni appena abilitate.
int* perstarray
Vettore di transizioni persistenti.
Metodi:
TPN(int t, *tn, p, *pn, it=0, *itn=NULL, ip=0, *ipn=NULL)
Costruisce la TPN allocando i vettori di piazze e transizioni ed inizializzandoli: t e il numero di transizioni, tn e il vettore dei nomi
da dare alle transizioni, p e il numero di piazze, pn e il vettore dei
nomi da dare alle piazze, it e il numero di transizioni di interfaccia,
itn e il vettore dei nomi da dare alle transizioni di interfaccia, ip e
il numero di piazze di interfaccia, ipn e il vettore dei nomi da dare
alle piazze di interfaccia. I nomi sono dati come semplici int, poiche
il tipo giusto viene assegnato dal costruttore.
TPN(const TPN&)
Costruttore di copia, alloca una nuova TPN e ci ricopia l' argomento.
TPN()
Distruttore, libera la memoria usata dai vettori.
int NTrans()
Ritorna il numero di transizioni vere.
int NPlace()
Ritorna il numero di piazze vere.
int NITrans()
Ritorna il numero di transizioni di interfaccia, comprese quelle associate alle piazze di interfaccia.
int NIPlace()
Ritorna il numero di piazze di interfaccia.
TName trn(int i)
Ritorna il nome della transizioni di indice i.
int tidx(TName t)
Ritorna l' indice della transizione di nome t o -1 se la transizione
non appartiene alla rete.
int plc(int i)
Ritorna il nome della piazza di indice i.
79
CAPITOLO 5. SISTEMA SOFTWARE
int pidx(int p)
Ritorna l' indice della piazza di nome p o -1 se la piazza non appartiene alla rete.
tempo EFTs(TName t)
Ritorna l' EFT statico della transizioni di nome t.
tempo LFTs(TName t)
Ritorna il LFT statico della transizioni di nome t.
tempo EFTd(TName t)
Ritorna l' EFT dinamico della transizioni di nome t.
tempo LFTd(TName t)
Ritorna il LFT dinamico della transizioni di nome t.
tempo EFTri(TName t, int it)
Ritorna l' EFT della Required Interface che viene assegnato a it all'
esecuzione di t.
tempo LFTri(TName t, int it)
Ritorna il LFT della Required Interface che viene assegnato a it all'
esecuzione di t.
void SetTOKs(int p, int m)
Assegna il numero statico di gettoni m alla piazza p.
void SetTOKd(int p, int m)
Assegna il numero dinamico di gettoni m alla piazza p.
void SetEFunc(TName t, EnableFuncPtr ef)
Assegna la funzione di abilitazione ef alla
funzione deve essere dichiarata come
transizione t. Questa
bool ef(int P, int* mark, Condition* cond)
dove P e il numero di piazze vere e di interfaccia, mark e il marcamento e cond e il vettore degli archi collegati alla transizione.
void SetPre(TName t, int p)
Crea un arco di ingresso per la transizione t dalla piazza p.
void SetPost(TName t, int p)
Crea un arco di uscita per la transizione t alla piazza p.
void SetInhibit(TName t, int p)
Crea un arco di inibizione per la transizione t dalla piazza p.
void SetFTs(TName t, tempo eft, tempo lft)
Assegna i tempi di esecuzione statici eft e lft
alla transizione t.
void SetFTd(TName t, tempo eft, tempo lft)
Assegna i tempi di esecuzione dinamici eft e lft
alla transizione t.
void SetRI(TName it, TName t, tempo eft, tempo lft)
Assegna alla transizione di interfaccia it i tempi di esecuzione eft
e lft che devono esserle associati all' esecuzione di t.
void SetMarking(int* m)
Assegna il marcamento alla rete dal vettore m.
80
CAPITOLO 5. SISTEMA SOFTWARE
void GetMarking(int* m)
Copia in m il vettore che
rappresenta il marcamento della rete.
bool IsEnabled(TName t)
Veri ca se la transizione t e abilitata nello stato corrente della rete.
void Fire(TName t)
Esegue la transizione t, aggiornando lo stato della rete.
int NewlyEnabled()
Ritorna il numero di transizioni appena abilitate.
int Persistent()
Ritorna il numero di transizioni persistenti.
int Enabled()
Ritorna il numero di transizioni abilitate.
void GetNewlyEnabled(TName* n)
Copia nel vettore n i nomi delle
transizioni appena abilitate.
void GetPersistent(TName* p)
Copia nel vettore p i nomi delle
transizioni persistenti.
void GetEnabled(TName* e)
Copia nel vettore e i nomi
delle transizioni abilitate.
ostream& operator<<(ostream& s, TPN& tpn)
Operatore di uscita: inserisce in un usso di uscita la rete.
81
CAPITOLO 5. SISTEMA SOFTWARE
Classe StateNode
Superclassi: ListNode.
Sottoclassi: TPNNode, IntegNode, PINode.
Usa: TName, Domain, StateLink.
Usata in: StateGraph.
Descrizione:
Rappresenta un nodo nel grafo degli stati. Ogni nodo contiene il dominio
di esecuzione dello stato ed una catena di archi che lo collegano agli stati
successivi.
Per comodita la classe replica la maggior parte dei metodi del Domain
anche se in sola lettura.
Dati:
int StateNum
Numero identi cativo dello stato.
int Level
Livello dello stato nel grafo.
StateLink* arcs
Catena degli archi uscenti dal nodo.
Domain domain
Dominio di esecuzione dello stato.
Metodi:
StateNode(StateNode& p, int s)
Costruisce il nodo a partire dal padre p, associandogli il numero s.
int Num()
Ritorna il numero dello stato.
int Lev()
Ritorna il livello dello stato.
StateNode* next(TName t0)
Ritorna, se esiste, il successore del nodo attraverso t0, altrimenti
ritorna NULL. Eettua una ricerca lineare sugli archi uscenti dal nodo.
StateLink* firstarc()
Ritorna il primo arco uscente dal nodo.
StateLink* nextarc(StateLink* l)
Ritorna l' arco che segue l. Serve
a scandire tutti gli archi del nodo.
ostream& operator<<(ostream& s, StateNode& n)
Operatore di uscita: inserisce in un usso di uscita lo stato, compreso
il suo dominio di esecuzione.
82
CAPITOLO 5. SISTEMA SOFTWARE
Classe StateLink
Superclassi: Sottoclassi: Usa: TName.
Usata in: StateNode, StateGraph.
Descrizione:
Rappresenta un arco nel grafo degli stati. Gli archi sono inseriti in una
lista la cui testa e nel nodo da cui partono tutti gli archi. Ad ogni arco e associata una transizione e il nodo in cui si arriva tramite la sua
esecuzione.
Dati:
StateLink* nxt
Prossimo arco nella catena.
StateNode* node
Nodo del grafo cui punta l' arco.
TName Transition
Nome della transizione associata all' arco.
Metodi:
TName trn()
Ritorna il nome della transizione associata all' arco.
StateLink* next()
Ritorna il prossimo arco della catena.
StateNode* state()
Ritorna lo stato cui si arriva tramite l' arco.
ostream& operator<<(ostream& s, StateLink& l)
Operatore di uscita: inserisce in un usso di uscita l' arco.
83
CAPITOLO 5. SISTEMA SOFTWARE
Classe StateSet
Superclassi: List.
Sottoclassi: Usa: StateNode.
Usata in: StateGraph, Trace.
Descrizione:
E' una lista specializzata per rappresentare un insieme di stati e le operazioni che sull' insieme si possono fare.
Gli stati sono inseriti tramite uno StateSetNode (non descritto per semplicita), che contiene un semplice puntatore allo stato.
Metodi:
void Add(StateNode* )
Aggiunge uno stato all' insieme.
void AddUnique(StateNode* )
Aggiunge uno stato all' insieme solo se il nodo non e gia presente.
StateNode* Get()
Toglie il primo stato dall' insieme.
StateSetNode* head()
Ritorna il primo stato dell' insieme.
StateSetNode* next()
Ritorna lo stato successivo a quello corrente.
ostream& operator<<(ostream& s, StateSet& ss)
Operatore di uscita: inserisce in un usso di uscita l' insieme di stati.
84
CAPITOLO 5. SISTEMA SOFTWARE
Classe StateGraph
Superclassi: Sottoclassi: TPNGraph, IntegGraph, PIGraph.
Usa: List, TName, StateNode, StateLink, StateSet.
Usata in: IntegGraph.
Descrizione:
E' la classe principale, che poi viene specializzata nei vari tipi di gra
degli stati. Per potervi accedere con semplicita i nodi del grafo sono tutti
collegati tramite una lista doppia, oltre che dai normali archi del grafo. Il
grafo viene normalmente costruito con un algoritmo di scansione a ventaglio, in cui si usa un insieme che contiene i nodi incontrati e non ancora
esaminati questo insieme viene mantenuto nella classe StateGraph per
poter costruire il grafo in piu passi.
Inoltre uno StateGraph deve fornire alcune informazioni sul numero ed i
nomi delle transizioni che lo interessano.
La classe non e molto utile se non e specializzata e dotata di un costruttore
signi cativo.
Dati:
int TrnCnt
Numero di transizioni nel grafo.
int StateCnt
Numero di stati nel grafo.
int LevelCnt
Numero di livelli nel grafo.
StateList list
Lista dei nodi del grafo.
StateSet Sigma
Insieme dei nodi da espandere.
StateNode* root
Radice del grafo degli stati.
Metodi:
StateGraph(int t)
Inizializza le dimensioni del grafo, dichiarando t transizioni.
StateGraph()
Distruttore del grafo: libera la memoria allocata e distrugge tutti i
nodi del grafo.
StateNode* head()
Ritorna il primo nodo del grafo, usato per scorrere tutti i nodi.
85
CAPITOLO 5. SISTEMA SOFTWARE
StateNode* next()
Ritorna il nodo successivo a quello attuale, usato per scorrere tutti i
nodi.
StateNode* rootnode()
Ritorna la radice del grafo.
StateNode* state(int n)
Ritorna lo stato di nome n. Eettua una ricerca lineare nella lista
dei nodi.
void Link(StateNode* p, StateNode* c, TName t)
Collega il nodo c come successore di p tramite la transizione t.
int NTrans()
Ritorna il numero di transizioni presenti nel grafo.
virtual TName trn(int i)
Ritorna il nome della transizione di indice i. Se non e ride nita nella classe derivata, converte semplicemente i nel nome di una
transizione.
virtual int idx(TName t)
Ritorna l' indice della transizione di nome t. Se non e ride nita nella
classe derivata, converte semplicemente t nell' intero corrispondente.
ostream& operator<<(ostream& s, StateGraph& g)
Operatore di uscita: inserisce in un usso di uscita il grafo, elencando
tutti gli stati.
86
CAPITOLO 5. SISTEMA SOFTWARE
Classe TPNNode
Superclassi: StateNode.
Sottoclassi: Usa: tempo, TName, TPN, Domain.
Usata in: Descrizione:
Rappresenta uno stato nel grafo ottenuto da una TPN. Aggiunge al semplice StateNode il marcamento ed i costruttori.
Dati:
int M
E' la dimensione del vettore marcamento, corrisponde al numero di
piazze nella TPN.
int* marking
E' il vettore che contiene il marcamento.
Metodi:
TPNNode(TPN& tpn)
Costruisce la radice del grafo degli stati. Il marcamento si ottiene
con TPN::GetMarking(). Il dominio di esecuzione viene calcolato
dalla tpn usando i metodi TPN::EFT() e TPN::LFT() e normalizzato
con Domain::Normalize().
TPNNode(TPNNode& p, TPN& tpn, TName t0, int s)
Costruisce il nodo del grafo di tpn successore di p attraverso t0.
Per prima cosa si riporta la TPN allo stato p tramite TPN::SetFTs()
e TPN::SetMarking(), poi si esegue t0 tramite TPN::Fire(). Il
nuovo dominio si calcola a partire dal domino di p ristretto con
Domain::Restrict() e dai nuovi intervalli di esecuzione della TPN.
TPNNode()
Libera la memoria usata dallo stato.
int operator==(TPNNode& a, TPNNode& b)
Confronta due stati, considerando dominio e marcamento.
ostream& operator<<(ostream& s, TPNNode& n)
Operatore di uscita: inserisce in un usso di uscita lo stato.
87
CAPITOLO 5. SISTEMA SOFTWARE
Classe TPNGraph
Superclassi: StateGraph.
Sottoclassi: Usa: tempo, TName, TPN, Domain.
Usata in: Descrizione:
Rappresenta il grafo degli stati ottenuto da una TPN. Aggiunge al semplice
StateGraph la rete ed il costruttore.
Dati:
TPN tpn
E' la rete di cui si vuole il grafo.
Metodi:
TPNGraph(TPN& net, int depth=INT MAX)
Costruisce il grafo della rete net, arrivando
dita depth.
al massimo alla profon-
TPNGraph()
Libera la memoria occupata dal grafo e dai suoi nodi.
void GrowToLevel(int depth)
Continua la costruzione del grafo usando gli stati inseriti nell' insieme
Sigma, arrivando al massimo alla profondit
a depth.
Per ogni stato padre usa Domain::CanFire() prima di costruire ed
inserire il glio nel grafo.
TName trn(int i)
Ritorna il nome della transizione di indice i della tpn.
int idx(TName t)
Ritorna l' indice della transizione di nome t nella tpn, o -1 se t non
e presente.
ostream& operator<<(ostream& s, TPNGraph& g)
Operatore di uscita: inserisce in un usso di uscita il grafo.
88
CAPITOLO 5. SISTEMA SOFTWARE
Superclassi: Sottoclassi: Usa: TName.
Usata in: IntegGraph.
Descrizione:
Classe Channel
Rappresenta un canale tra due transizioni di gra diversi, come una coppia
di nomi di transizioni, una e il master, l' altra lo slave.
Dati:
TName master
E' il master del canale.
TName slave
E' lo slave del canale.
Metodi:
Channel(TName m, TName s)
Costruttore del canale tra il master m e lo slave s.
TName Master()
Ritorna il master del canale.
TName Slave()
Ritorna lo slave del canale.
89
CAPITOLO 5. SISTEMA SOFTWARE
Classe IntegData
Superclassi: Sottoclassi: Usa: Channel, StateGraph.
Usata in: IntegGraph.
Descrizione:
Contiene i dati necessari alla integrazione di piu stati in un grafo di integrazione, tramite un vettore di StateGraph, un vettore di Channel ed
un vettore di nomi di transizioni. I nomi delle transizioni sono quelli contenuti nei gra da integrare, salvo i casi in cui ci sono collisioni, dove le
transizioni sono rinominate con un nome funzione del numero del grafo di
appartenenza e del nome originale. Un ag segnala che la rimappatura e
stata fatta ed i nomi delle transizioni sono validi.
Dati:
int GraphNum
Numero dei gra da integrare.
StateGraph** GraphArray
Vettore dei gra da integrare.
int ChannelNum
Numero dei canali.
Channel* ChannArray
Vettore dei canali di integrazione.
int N
Numero totale di transizioni.
TName* Trans
Nomi rimappati delle transizioni dei gra .
int* lwr
Questo vettore contiene gli indici necessari a partizionare il vettore di transizioni in pezzi corrispondenti alle transizioni dei gra da
integrare.
bool validtrans
Segnala la validita dei nomi.
Metodi:
IntegData(int g, int c)
Costruttore IntegData
allocando lo spazio per g gra e c canali.
IntegData(IntegData& id)
Costruttore di copia, alloca un nuovo IntegData e ci ricopia l' argomento.
90
CAPITOLO 5. SISTEMA SOFTWARE
IntegData()
Distruttore, libera la memoria usata dai vettori.
int NGraph()
Ritorna il numero di gra da integrare.
int NTrans()
Ritorna il numero di transizioni totali.
StateGraph& Graph(int g)
Ritorna il grafo di indice g.
void SetGraph(int g, StateGraph& sg)
Assegna il grafo sg all' indice g.
void SetChannel(int i, int mg, TName mt, int sg, TName st)
Costruisce un canale tra la transizione mt del grafo mg e la transizione
st del grafo sg e lo assegna all' indice i.
TName trn(int i)
Ritorna il nome globale della transizione di indice i.
int idx(TName t)
Ritorna l' indice della transizione globale t, o -1 se t non e presente.
TName Trn(int g, TName t)
Ritorna il nome globale della transizione t del grafo g.
TName TrnTrn(TName t)
Ritorna il nome originale della transizione il cui nome globale e t.
int TrnGraph(TName t)
Ritorna l' indice del grafo cui appartiene la transizione globale t.
TName TrnSlave(TName t)
Ritorna il nome della transizione di cui t e il master, o TNONE se t
non ha slave.
TName TrnMaster(TName t)
Ritorna il nome della transizione di cui t e lo slave, o TNONE se t non
ha master.
bool IsSlave(TName t)
Controlla se t e una
transizione slave.
bool IsMaster(TName t)
Controlla se t e una transizione
91
master.
CAPITOLO 5. SISTEMA SOFTWARE
Classe IntegNode
Superclassi: StateNode.
Sottoclassi: Usa: StateNode, TName, IntegData, Domain.
Usata in: Descrizione:
Rappresenta uno stato nel grafo di integrazione. Aggiunge al semplice
StateNode gli stati dei singoli gra ed i costruttori.
Uno IntegNode puo essere uno stato di errore per il processo di integrazione: in tal caso il primo stato del vettore e NULL, mentre il secondo
indica il tipo dell' errore (ERR_MISSED o ERR_EARLY).
Dati:
int S
E' la dimensione del vettore di stati, corrisponde al numero di gra
da integrare.
StateNode** states
E' il vettore che contiene i puntatori agli stati che sono integrati in
questo nodo.
Metodi:
IntegNode(IntegData& id)
Costruisce la radice del grafo di integrazione. Si riuniscono le radici di tutti i gra con StateGraph::rootnode() e si separano le
transizioni slave dalle altre con IntegData::IsSlave(). Il dominio di esecuzione si calcola usando i metodi di IntegData per accedere alle transizioni e poi si normalizza in due tempi: prima, con
Domain::Normalize(), si sistemano le transizioni normali e poi si
passa alle slave con IntegData::SlaveNormalize() per veri care
che la required interface sia soddisfatta.
IntegNode(IntegNode& p, IntegData& id, TName t0, int in)
Costruisce il nodo del grafo di integrazione che e il successore di p
attraverso t0.
Per prima cosa si calcola il nuovo insieme di stati integrati con i
metodi di IntegData e StateGraph::next(). Se durante questa
fase si veri ca una violazione della required interface il nodo diventa
uno stato di errore. Durante la costruzione del dominio di esecuzione
si usano i metodi di Domain per restringere il dominio padre in due
tempi, per poi veri care eventuali violazioni alla required interface.
IntegNode()
Libera la memoria usata dallo stato.
92
CAPITOLO 5. SISTEMA SOFTWARE
int operator==(IntegNode& a, IntegNode& b)
Confronta due stati, considerando dominio e stati integrati.
ostream& operator<<(ostream& s, IntegNode& n)
Operatore di uscita: inserisce in un usso di uscita lo stato.
93
CAPITOLO 5. SISTEMA SOFTWARE
Classe IntegGraph
Superclassi: StateGraph.
Sottoclassi: Usa: tempo, TName, StateGraph, Domain.
Usata in: Descrizione:
Rappresenta il grafo di integrazione. Si possono integrare gra di qualsiasi
classe derivata da StateGraph. Aggiunge al semplice StateGraph una
copia di IntegData ed il costruttore.
Dati:
IntegData id
Contiene i dati necessari all' integrazione.
Metodi:
IntegGraph(IntegData& id, int depth=INT MAX)
Costruisce il grafo di integrazione partendo da
massimo alla profondita depth.
id
ed arrivando al
IntegGraph()
Libera la memoria occupata dal grafo e dai suoi nodi.
void GrowToLevel(int depth)
Continua la costruzione del grafo usando gli stati inseriti nell' insieme
Sigma, arrivando al massimo alla profondit
a depth.
Per ogni stato padre usa Domain::CanFire() prima di costruire ed
inserire il glio nel grafo.
TName trn(int i)
Ritorna il nome globale della transizione di indice i.
int idx(TName t)
Ritorna l' indice della transizione di nome globale t, o -1 se t non e
presente.
ostream& operator<<(ostream& s, IntegGraph& g)
Operatore di uscita: inserisce in un usso di uscita il grafo.
94
CAPITOLO 5. SISTEMA SOFTWARE
Classe Trace
Superclassi: Sottoclassi: Usa: TName, tempo, StateNode.
Usata in: Profile
Descrizione:
Rappresenta una traccia di esecuzione nel grafo degli stati. Una traccia e
una successione di coppie stato-transizione unita ad uno stato nale cui
giunge la traccia. Una traccia puo essere lunga 0 ed avere comunque uno
stato di arrivo.
Dalla traccia si possono ricavare in maniera semplice le stime sui vincoli
dei tempi di esecuzione delle singole transizioni e quindi di tutta la traccia.
Dati:
int N
Lunghezza della traccia.
StateNode** states
Vettore degli stati della traccia.
TName* Trans
Vettore delle transizioni della traccia.
StateNode* endstate
Nodo in cui termina la traccia.
bool validbounds
Segnala se i limiti sono validi.
tempo gEFT
Tempo minimo di esecuzione di tutta la traccia.
tempo gLFT
Tempo massimo di esecuzione di tutta la traccia.
tempo* tEFT
Vettore dei tempi minimi di esecuzione delle transizioni.
tempo* tLFT
Vettore dei tempi massimi di esecuzione delle transizioni.
Metodi:
Trace(StateNode* s, int n, TName* t)
Costruttore completo, costruisce una traccia lunga n a partire dallo
stato s, dimensionando i vettori ed usando il vettore di transizioni
t e StateNode::next() per formare le coppie ed arrivare allo stato
nale.
95
CAPITOLO 5. SISTEMA SOFTWARE
Trace(Trace* tau)
Quasi un costruttore di copia, salvo usare un puntatore alla traccia
invece di un riferimento.
Trace(Trace* Tau, TName T)
Costruttore di allungamento. Costruisce una traccia aggiungendo
alla traccia Tau la transizione T.
Trace()
Distruttore, libera la memoria usata dai vettori.
int idx(int n, TName t)
Ritorna l' indice della transizione di nome t che esegue non prima
di quella in posizione n nella traccia, o -1 se non esiste.
TName trn(int i)
Ritorna il nome della transizione che esegue in posizione i.
int lenght()
Ritorna la lunghezza della traccia.
StateNode* start()
Ritorna il primo stato della traccia, quello di partenza.
StateNode* end()
Ritorna l' ultimo stato della traccia, quello di arrivo.
int LastPerstState(int n, TName t)
Ritorna la posizione nella traccia dell' ultimo stato in cui t e persistente dopo lo stato in posizione n. Usa Domain::IsPersistent().
bool HasLoop(StateNode* S, TName T)
Controlla se la coppia (S,T) e presente
nella traccia.
tempo EFT()
Ritorna il tempo minimo di esecuzione di tutta la traccia.
tempo LFT()
Ritorna il tempo massimo di esecuzione di tutta la traccia.
tempo EFT(int i)
Ritorna il tempo minimo di esecuzione della transizione di indice i.
tempo LFT(int i)
Ritorna il tempo massimo di esecuzione della transizione di indice i.
ostream& operator<<(ostream& s, Trace& t)
Operatore di uscita: inserisce in un usso di uscita la traccia.
96
CAPITOLO 5. SISTEMA SOFTWARE
Classe TraceSet
Superclassi: List.
Sottoclassi: Usa: TName, StateNode, StateLink, StateSet, Trace.
Usata in: Profile.
Descrizione:
E' una lista specializzata per rappresentare un insieme di tracce e le
operazioni che sull' insieme si possono fare.
Le tracce sono inserite tramite un TraceSetNode (non descritto per semplicita), che contiene un semplice puntatore alla traccia.
Metodi:
void Add(Trace* )
Aggiunge una traccia all' insieme.
Trace* Get()
Toglie la prima traccia dall' insieme.
StateSetNode* head()
Ritorna la prima traccia dell' insieme.
StateSetNode* next()
Ritorna la traccia successiva a quella corrente.
GrowTraces(StateSet& s, int ts, TName* t, TraceSet& trc,lop)
E' una funzione (e non un metodo), che trova tutte le tracce semplici
di un grafo che partono da un insieme di stati e terminano con l'
esecuzione di una certa transizione.
La funzione si aspetta in s l' insieme degli stati di partenza delle
tracce ed nel vettore t di lunghezza ts le transizioni che eseguendo
terminano le tracce.
L' insieme delle tracce costruite e ritornato in trc, mentre in lop si
ottengono gli eventuali loop rilevati tramite Trace::HasLoop() nella
costruzione delle tracce.
97
CAPITOLO 5. SISTEMA SOFTWARE
Classe Profile
Superclassi: Domain.
Sottoclassi: Usa: tempo, Trace.
Usata in: ProvidedIface.
Descrizione:
Specializza un Domain aggiungendo un costruttore che da una traccia
ricava i vincoli minimi sui tempi di esecuzione delle singole transizioni
della traccia.
Metodi:
Profile(Trace& tr)
Costruisce il pro lo minimo di esecuzione della traccia. Scorre la
traccia e, per ogni transizione dei domini degli stati incontrati, cerca
con Trace::LastPerstState() lo stato in cui la transizione sparisce
ed aggiunge i vincoli giusti al sistema di disequazioni globale. In ne
risolve il sistema con Domain::Normalize().
Profile()
Distrugge il pro le.
tempo EFT()
Ritorna il tempo di esecuzione minimo di tutta la traccia.
tempo LFT()
Ritorna il tempo di esecuzione massimo di tutta la traccia.
tempo EFT(int i)
Ritorna il tempo di esecuzione minimo della transizione che esegue
in posizione i nella traccia.
tempo LFT(int i)
Ritorna il tempo di esecuzione massimo della transizione che esegue
in posizione i nella traccia.
98
CAPITOLO 5. SISTEMA SOFTWARE
Classe ProvidedIface
Superclassi: Sottoclassi: Usa: TName, tempo, StateSet, StateNode, StateGraph.
Usata in: PIGraph.
Descrizione:
Implementa una interfaccia oerta.
Contiene sia i dati necessari a calcolare l' interfaccia che quelli necessari ad eseguirla in maniera simile ad una TPN: per ogni transizione si
memorizza in una struct Transition, oltre al nome, due vettori che
contengono i nuovi intervalli di esecuzione da assegnare alle altre transizioni quando esegue la transizione in esame. La transizione iniziale TINIT
e memorizzata in fondo alle transizioni osservabili.
Esistono dei metodi privati, con il nome tutto minuscolo, che richiedono
l' indice della transizione invece del suo nome generale.
Dati:
int N
Numero di transizioni osservabili (escluso TINIT).
struct Transition* TransArray
Vettore delle transizioni osservabili.
int EnabledCount
Numero di transizioni abilitate dopo l' ultima esecuzione.
bool enabledvalid
Segnala che il numero di transizioni abilitate e corretto.
Metodi:
ProvidedIface(StateGraph& g, int n, TName* t)
Costruttore
ProvidedIface(const ProvidedIface&)
Costruttore di copia, alloca una nuova ProvidedIface e ci ricopia l'
argomento.
ProvidedIface()
Distruttore, libera la memoria usata dai vettori.
int NTrans()
Ritorna il numero di transizioni osservabili.
TName trn(int i)
Ritorna il nome della transizione di indice i.
int idx(TName t)
Ritorna l' indice della transizione di nome t o -1 se la transizione
non appartiene al dominio.
99
CAPITOLO 5. SISTEMA SOFTWARE
void Fire(TName t)
Esegue la transizione di nome t, aggiornando lo stato dinamico ed il
conteggio delle transizioni abilitate.
int Enabled()
Ritorna il numero di transizioni abilitate
void GetEnabled(TName* e)
Copia nel vettore e i nomi
delle transizioni abilitate.
tempo EFT(TName t)
Ritorna l' EFT dinamico della transizioni di nome t.
tempo LFT(TName t)
Ritorna il LFT dinamico della transizioni di nome t.
tempo EFT(TName t0, TName tf)
Ritorna l' EFT che viene assegnato alla transizione t0 all' esecuzione
di tf.
tempo LFT(TName t0, TName tf)
Ritorna il LFT che viene assegnato alla transizione t0 all' esecuzione
di tf.
ostream& operator<<(ostream& s, ProvidedIface& pi)
Operatore di uscita: inserisce in un usso di uscita l' interfaccia
oerta.
100
CAPITOLO 5. SISTEMA SOFTWARE
Classe PINode
Superclassi: StateNode.
Sottoclassi: Usa: tempo, TName, ProvidedIface, Domain.
Usata in: Descrizione:
Rappresenta uno stato nel grafo ottenuto da una ProvidedIface. Aggiunge al semplice StateNode dei costruttori specializzati.
Metodi:
PINode(ProvidedIface& pi)
Costruisce la radice del grafo degli stati. Il dominio di esecuzione viene calcolato da pi usando i metodi ProvidedIface::EFT() e
ProvidedIface::LFT() e normalizzato con Domain::Normalize().
PINode(PINode& p, ProvidedIface& pi, TName t0, int s)
Costruisce il nodo del grafo di pi successore di p attraverso t0.
Per prima cosa si esegue t0 tramite ProvidedIface::Fire(). Il
nuovo dominio si calcola a partire dai nuovi intervalli di esecuzione
della ProvidedIface.
PINode()
Libera la memoria usata dallo stato.
int operator==(PINode& a, PINode& b)
Confronta due stati.
ostream& operator<<(ostream& s, PINode& n)
Operatore di uscita: inserisce in un usso di uscita lo stato.
101
CAPITOLO 5. SISTEMA SOFTWARE
Classe PIGraph
Superclassi: StateGraph.
Sottoclassi: Usa: tempo, TName, ProvidedIface, Domain.
Usata in: Descrizione:
Rappresenta il grafo degli stati ottenuto da una ProvidedIface. Aggiunge al semplice StateGraph la copia della interfaccia ed il costruttore.
Dati:
ProvidedIface pi
E' l' interfaccia di cui si vuole il grafo.
Metodi:
PIGraph(ProvidedIface& pi, int depth=INT MAX)
Costruisce il grafo dell' interfaccia pi, arrivando
profondita depth.
al massimo alla
PIGraph()
Libera la memoria occupata dal grafo e dai suoi nodi.
void GrowToLevel(int depth)
Continua la costruzione del grafo usando gli stati inseriti nell' insieme
Sigma, arrivando al massimo alla profondit
a depth.
Per ogni stato padre usa Domain::CanFire() prima di costruire ed
inserire il glio nel grafo.
TName trn(int i)
Ritorna il nome della transizione di indice i della pi.
int idx(TName t)
Ritorna l' indice della transizione di nome t nella pi, o -1 se t non
e presente.
ostream& operator<<(ostream& s, PIGraph& g)
Operatore di uscita: inserisce in un usso di uscita il grafo.
102
CAPITOLO 5. SISTEMA SOFTWARE
5.3 Un esempio d' uso
Come esempio vediamo il listato del programma che de nisce ed analizza il
protocollo di Stenning secondo il modello discusso nella sezione 2.2.4 ed il listato
del programma che de nisce ed analizza il protocollo di arbitraggio del bus VME
discusso nella sezione 4.3.4.
5.3.1 Listato di testpgSTRS.cpp
#include
#include
#include
#include
#include
#include
#include
<iostream.h>
"common.h"
"tpn.h"
"tpngraph.h"
"igraph.h"
"pintface.h"
"pigraph.h"
//
// Source:
//
//
p0
t0
p1
|
init |ready(20)|
1
|
//
_
|
_
------+---------+---------+-------+
//
(_)---->|---->(_)
ready |+INF,+INF|+INF,+INF| 0,+INF|
// 1 ^
|
| 0
------+---------+---------+-------+
//
|
2,4]
|
//
|
|
ready -> t20
//
|
|
data -> p20
//
|
|
//
|
t1
|
//
|
|<-----+
p2
//
+------|
_
//
|<----------(_)
//
0,1]
1
//
data!
ready?
//
// TX:
//
t7
//
----//
^ 3,6]
//
| pkt!
ack -> t30
//
|
data -> t31
//
t8
|
//
|
_ p8
t4
p5
ready -> p30
//
|<---(_)<--------------|
_
pkt
-> p31
//
|
^ 0
|<-----(_)
//
3,6]
|
+---------|
^ 0
//
p3
|
|
1,2]
|
//
_
t3
|
|
|
//
(_)------->|-----+
v
|
//
0
|
_ p4
t5
|
// data? +--->|---------->(_)------->|
|
//
| 1,2]
| 0
|-------+
//
|
|
+---*|
//
|
t6
|
| 16,16]
//
p6 _
|<-----+
|
//
(_)<--------|
_ p7
103
CAPITOLO 5. SISTEMA SOFTWARE
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
1
|<---------(_)
0,1]
0
ready!
ack?
|
init | data(31)| ack(30) |
5
|
6
|
7
|
-----+---------+---------+---------+---------+---------+---------+
data | 0,+INF |+INF,+INF|
--|
--| 0,+INF |
--|
-----+---------+---------+---------+---------+---------+---------+
ack |+INF,+INF|
--|+INF,+INF|+INF,+INF|
--| 0,+INF |
-----+---------+---------+---------+---------+---------+---------+
RX:
t9
p10
|
_
+------->|*-----(_)
|
|
| 1
|
0,0]
| ready?
|
|
|
|
|
|
t10
p11
t12
|
+---->|
_
|
p9 _
|------>(_)------>|
(_)-------------------->|
| 0
|
0
1,3]
|
3,6]
pkt?
data!
|
ack!
v t11
----3,6]
ready -> t40
pkt
-> t41
data
ack
-> p40
-> p41
|
init | pkt(41) |ready(40)|
12
|
10
|
------+---------+---------+---------+---------+---------+
ready |+INF,+INF|
--|+INF,+INF|
--|
0,+INF|
------+---------+---------+---------+---------+---------+
pkt
|
0,+INF| 10,+INF|
--| 0,+INF |
--|
------+---------+---------+---------+---------+---------+
Sink:
p13
t14
p14
_
|
_
(_)---->|---->(_)
0 ^
|
| 1
|
0,0]
|
|
ready!
|
|
|
|
|
|
t13
|
|
|<-----+
p12
+------|
_
|<----------(_)
0,1]
0
data?
|
init |data(50) | 14
|
------+---------+---------+-------+
data |
0,+INF|+INF,+INF| 0,+INF|
------+---------+---------+-------+
ready -> p50
data -> t50
void main()
{
104
CAPITOLO 5. SISTEMA SOFTWARE
int source_T2]={0,1}"
int source_P3]={0,1,2}"
int source_R1]={20}"
class TPN source(2,source_T, 3,source_P, 1,source_R)"
// t0
source.SetPre(T(0), 0)"
source.SetPost(T(0), 1)"
source.SetFTs(T(0), 2, 4)"
// t1
source.SetPre(T(1), 1)"
source.SetPre(T(1), 2)"
source.SetPost(T(1), 0)"
source.SetFTs(T(1), 0, 1)"
// ready (t20)
source.SetPost(I(20), 2)"
source.SetRI(I(20), TINIT, +INF, +INF)" // RI(ready, init)
source.SetRI(I(20), I(20), +INF, +INF)" // RI(ready, ready)
source.SetRI(I(20), T(1), 0,
+INF)" // RI(ready, 1)
// Setta il marcamento piazza per piazza
source.SetTOKs( 0, 1)"
source.SetTOKs( 1, 0)"
source.SetTOKs( 2, 1)"
cout << "TPN di Source\n" << source"
TPNGraph source_graph(source, 15)"
cout << "Grafo di Source\n" << source_graph"
int tx_T6]={3,4,5,6,7,8}"
int tx_P6]={3,4,5,6,7,8}"
int tx_R2]={30,31}"
class TPN tx(6,tx_T, 6,tx_P, 2,tx_R)"
// t3
tx.SetFTs(T(3), 1, 2)"
tx.SetPre(T(3), 3)"
tx.SetPre(T(3), 6)"
tx.SetPost(T(3), 8)"
tx.SetPost(T(3), 4)"
// t4
tx.SetFTs(T(4), 1, 2)"
tx.SetPre(T(4), 5)"
tx.SetPost(T(4), 8)"
tx.SetPost(T(4), 4)"
// t5
tx.SetFTs(T(5), 16, 16)"
tx.SetPre(T(5), 4)"
tx.SetPost(T(5), 5)"
tx.SetInhibit(T(5), 7)"
// t6
tx.SetFTs(T(6), 0, 1)"
tx.SetPre(T(6), 4)"
tx.SetPre(T(6), 7)"
tx.SetPost(T(6), 6)"
// t7
tx.SetFTs(T(7), 3, 6)"
tx.SetPre(T(7), 8)"
// t8
tx.SetFTs(T(8), 3, 6)"
tx.SetPre(T(8), 8)"
105
CAPITOLO 5. SISTEMA SOFTWARE
// ack? (t30)
tx.SetPost(I(30), 7)"
tx.SetRI(I(30), TINIT, +INF, +INF)"
tx.SetRI(I(30), I(30), +INF, +INF)"
tx.SetRI(I(30), T(5), +INF, +INF)" // mia aggiunta
tx.SetRI(I(30), T(7), 0,
+INF)"
// data? (t31)
tx.SetPost(I(31), 3)"
tx.SetRI(I(31), TINIT, 0,
+INF)"
tx.SetRI(I(31), I(31), +INF, +INF)"
tx.SetRI(I(31), T(6), 0,
+INF)"
// Setta il marcamento piazza per piazza
tx.SetTOKs( 3, 0)"
tx.SetTOKs( 4, 0)"
tx.SetTOKs( 5, 0)"
tx.SetTOKs( 6, 1)"
tx.SetTOKs( 7, 0)"
tx.SetTOKs( 8, 0)"
cout << "TPN di TX\n" << tx"
TPNGraph tx_graph(tx, 100)"
cout << "Grafo di TX\n" << tx_graph"
int rx_T4]={9,10,11,12}"
int rx_P3]={9,10,11}"
int rx_R2]={40,41}"
class TPN rx(4,rx_T, 3,rx_P, 2,rx_R)"
// t9
rx.SetFTs(T(9), 0, 0)"
rx.SetPre(T(9), 9)"
rx.SetInhibit(T(9), 10)"
// t10
rx.SetFTs(T(10), 1, 3)"
rx.SetPre(T(10), 9)"
rx.SetPre(T(10), 10)"
rx.SetPost(T(10), 11)"
// t11
rx.SetFTs(T(11), 3, 6)"
rx.SetPre(T(11), 11)"
// t12
rx.SetFTs(T(12), 3, 6)"
rx.SetPre(T(12), 11)"
// ready? (t40)
rx.SetPost(I(40), 10)"
rx.SetRI(I(40), TINIT, +INF, +INF)"
rx.SetRI(I(40), I(40), +INF, +INF)"
rx.SetRI(I(40), T(10), 0,
+INF)"
// pkt? (t41)
rx.SetPost(I(41), 9)"
rx.SetRI(I(41), TINIT, 0, +INF)"
rx.SetRI(I(41), I(41), 10, +INF)"
rx.SetRI(I(41), T(12), 0, +INF)"
// Setta il marcamento piazza per piazza
rx.SetTOKs( 9, 0)"
rx.SetTOKs( 10, 1)"
rx.SetTOKs( 11, 0)"
cout << "TPN di RX\n" << rx"
TPNGraph rx_graph(rx, 100)"
106
CAPITOLO 5. SISTEMA SOFTWARE
cout << "Grafo di RX\n" << rx_graph"
int sink_T2]={13,14}"
int sink_P3]={12,13,14}"
int sink_R1]={50}"
class TPN sink(2,sink_T, 3,sink_P, 1,sink_R)"
// t13
sink.SetFTs(T(13), 0, 1)"
sink.SetPre(T(13), 14)"
sink.SetPre(T(13), 12)"
sink.SetPost(T(13), 13)"
// t14
sink.SetFTs(T(14), 0, 0)"
sink.SetPre(T(14), 13)"
sink.SetPost(T(14), 14)"
// data (t50)
sink.SetPost(I(50), 12)"
sink.SetRI(I(50), TINIT, 0,
+INF)"
sink.SetRI(I(50), I(50), +INF, +INF)"
sink.SetRI(I(50), T(14), 0,
+INF)"
// Setta il marcamento piazza per piazza
sink.SetTOKs( 12, 0)"
sink.SetTOKs( 13, 0)"
sink.SetTOKs( 14, 1)"
cout << "TPN di Sink\n" << sink"
TPNGraph sink_graph(sink, 15)"
cout << "Grafo di Sink\n" << sink_graph"
IntegData sourcetx(2, 2)"
// 2 grafi e 2 canali
sourcetx.SetGraph(0, source_graph)"
sourcetx.SetGraph(1, tx_graph)"
sourcetx.SetChannel(0, 0,T(1), 1,I(31))"// SOURCE_data! -->
TX_data?
sourcetx.SetChannel(1, 1,T(6), 0,I(20))"//
TX_ready! --> SOURCE_ready?
IntegGraph sourcetx_graph(sourcetx, 100)"
cout << "Grafo integrato di Source e TX\n" << sourcetx_graph"
IntegData rxsink(2, 2)"
// 2 grafi e 2 canali
rxsink.SetGraph(0, rx_graph)"
rxsink.SetGraph(1, sink_graph)"
rxsink.SetChannel(0, 0,T(10), 1,I(50))" //
RX_data! -->
rxsink.SetChannel(1, 1,T(14), 0,I(40))" //
SINK_ready! -->
IntegGraph rxsink_graph(rxsink, 10)"
cout << "Grafo integrato di RX e Sink\n" << rxsink_graph"
TName sourcetx_tobs] = {T(7),I(30)}"
ProvidedIface sourcetxpi(sourcetx_graph, 2, sourcetx_tobs)"
cout << "PI di SourceTX\n" << sourcetxpi"
PIGraph sourcetxpi_graph(sourcetxpi,15)"
cout << "Grafo della PI di SourceTX\n" << sourcetxpi_graph"
TName rxsink_tobs] = {T(12),I(41)}"
ProvidedIface rxsinkpi(rxsink_graph, 2, rxsink_tobs)"
cout << "PI di RXSink\n" << rxsinkpi"
PIGraph rxsinkpi_graph(rxsinkpi,15)"
cout << "Grafo della PI di RXSink\n" << rxsinkpi_graph"
107
SINK_data?
RX_ready?
CAPITOLO 5. SISTEMA SOFTWARE
IntegData st_rs(2, 2)"
st_rs.SetGraph(0, sourcetxpi_graph)"
st_rs.SetGraph(1, rxsinkpi_graph)"
st_rs.SetChannel(0, 0,T(7), 1,I(41))"
st_rs.SetChannel(1, 1,T(12), 0,I(30))"
//
//
TX_pkt!
RX_ack!
-->
-->
RX_pkt?
TX_ack?
IntegGraph st_rs_graph(st_rs, 100)"
cout << "Grafo integrato delle PI di SourceTX e RXSink\n" << st_rs_graph"
}
5.3.2 Listato di testigBUS.cpp
#include
#include
#include
#include
#include
<iostream.h>
"common.h"
"tpn.h"
"tpngraph.h"
"igraph.h"
#define P(a) (a)
//
// E' bene che le piazze siano nominate con il loro indice, per comodita'
//
// ************************** Bus Control **********************
#define NEED (mark1]!=0)
#define OWN (mark2]!=0)
bool NEEDdn(int P, int *mark, Condition *cond)
{
return (bool)(OWN)"
}
#undef NEED
#undef OWN
// ************************** Bus Master **********************
#define BGiOUT (mark 0]!=0)
#define BRi
(mark 2]!=0)
#define BBSY
(mark 4]!=0)
#define OWN
(mark 6]!=0)
#define BGiIN (mark 8]!=0)
#define BCLR
(mark 9]!=0)
#define AS
(mark10]!=0)
#define NEED
(mark11]!=0)
bool BGiOUTup(int P, int *mark, Condition *cond)
{
return (bool)(BGiIN)"
}
bool BGiOUTdn(int P, int *mark, Condition *cond)
{
return (bool)(!BGiIN && !NEED)"
}
bool BRiup(int P, int *mark, Condition *cond)
{
return (bool)(NEED && !BGiIN && !BBSY)"
}
bool BRidn(int P, int *mark, Condition *cond)
108
CAPITOLO 5. SISTEMA SOFTWARE
{
return (bool)(NEED && BBSY )"
}
bool OWNdn1(int P, int *mark, Condition *cond)
{
return (bool)(!NEED)"
}
bool OWNdn2(int P, int *mark, Condition *cond)
{
return (bool)(!BCLR)"
}
bool OWNup(int P, int *mark, Condition *cond)
{
return (bool)(AS && BGiIN)"
}
bool BBSYdn(int P, int *mark, Condition *cond)
{
return (bool)(NEED && !BGiIN && BCLR)"
}
#undef BGiOUT
#undef BRi
#undef BBSY
#undef OWN
#undef BGiIN
#undef BCLR
#undef AS
#undef NEED
// ************************** Bus Arbiter **********************
#define BG0
(mark 0]!=0)
#define OWN0 (mark 2]!=0)
#define BG1
(mark 3]!=0)
#define OWN1 (mark 5]!=0)
#define BG2
(mark 6]!=0)
#define OWN2 (mark 8]!=0)
#define BG3
(mark 9]!=0)
#define OWN3 (mark11]!=0)
#define BCLR (mark12]!=0)
#define BR0
(mark14]!=0)
#define BR1
(mark15]!=0)
#define BR2
(mark16]!=0)
#define BR3
(mark17]!=0)
#define BBSY (mark18]!=0)
bool BG0up(int P, int *mark, Condition *cond)
{
return (bool)(!BBSY && BR0)"
}
bool BG0dn(int P, int *mark, Condition *cond)
{
return (bool)(BBSY && !BR0 && BR1 && BR2 && BR3 && !OWN0)"
}
bool OWN0dn(int P, int *mark, Condition *cond)
{
return (bool)(BBSY)"
}
bool BG1up(int P, int *mark, Condition *cond)
{
109
CAPITOLO 5. SISTEMA SOFTWARE
return (bool)(!BBSY && BR1)"
}
bool BG1dn(int P, int *mark, Condition *cond)
{
return (bool)(BBSY && !BR1 && BR2 && BR3 && ! OWN1)"
}
bool OWN1dn(int P, int *mark, Condition *cond)
{
return (bool)(BBSY)"
}
bool BG2up(int P, int *mark, Condition *cond)
{
return (bool)(!BBSY && BR2)"
}
bool BG2dn(int P, int *mark, Condition *cond)
{
return (bool)(BBSY && !BR2 && BR3 && !OWN2)"
}
bool OWN2dn(int P, int *mark, Condition *cond)
{
return (bool)(BBSY)"
}
bool BG3up(int P, int *mark, Condition *cond)
{
return (bool)(!BBSY && BR3)"
}
bool BG3dn(int P, int *mark, Condition *cond)
{
return (bool)(BBSY && !BR3 && !OWN3)"
}
bool OWN3dn(int P, int *mark, Condition *cond)
{
return (bool)(BBSY)"
}
bool BCLRup(int P, int *mark, Condition *cond)
{
return (bool)(BBSY)"
}
bool BCLRdn(int P, int *mark, Condition *cond)
{
return (bool)(!BBSY &&
(OWN0&&!BR1 ||
(OWN0||OWN1)&&!BR2 ||
(OWN0||OWN1||OWN2)&&!BR3 ) )"
}
#undef BG0
#undef OWN0
#undef BG1
#undef OWN1
#undef BG2
#undef OWN2
#undef BG3
#undef OWN3
#undef BCLR
#undef BR0
#undef BR1
#undef BR2
#undef BR3
110
CAPITOLO 5. SISTEMA SOFTWARE
#undef BBSY
void main()
{
int BusControl_T2]={0,1}"
int BusControl_P2]={0,1}"
int BusControl_IP1]={2}"
class TPN BusControl(2,BusControl_T, 2,BusControl_P,
0,NULL, 1,BusControl_IP)"
// t0
BusControl.SetFTs(T(0), 0, +INF)"
BusControl.SetPre(T(0), P(0))"
BusControl.SetPost(T(0), P(1))"
// t1
BusControl.SetFTs(T(1), 10, 20)"
BusControl.SetPre(T(1), P(1))"
BusControl.SetEFunc(T(1), NEEDdn)"
// marcamenti
BusControl.SetTOKs(P(0), 1)"
BusControl.SetTOKs(P(1), 0)"
// NEED (p2)
BusControl.SetTOKs(P(2), 0)"
// u2
BusControl.SetRI(U(2), TINIT,
BusControl.SetRI(U(2), U(2),
BusControl.SetRI(U(2), T(0),
// d2
BusControl.SetRI(D(2), TINIT,
BusControl.SetRI(D(2), D(2),
BusControl.SetRI(D(2), T(1),
+INF, +INF)"
+INF, +INF)"
1, +INF)"
+INF, +INF)"
+INF, +INF)"
0, +INF)"
TPNGraph BusControl_g(BusControl,10)"
cout << "Grafo del Bus Control\n" << BusControl_g"
int BusMaster_T9]={0,1,2,3,4,5,6,7,8}"
int BusMaster_P8]={0,1,2,3,4,5,6,7}"
int BusMaster_IP4]={8,9,10,11}"
class TPN BusMaster(8,BusMaster_T, 8,BusMaster_P,
0,NULL, 4,BusMaster_IP)"
// t0
BusMaster.SetFTs(T(0), 1, 1)"
BusMaster.SetPre(T(0), P(1))"
BusMaster.SetPost(T(0), P(0))"
BusMaster.SetEFunc(T(0), BGiOUTup)"
// t1
BusMaster.SetFTs(T(1), 1, 2)"
BusMaster.SetPre(T(1), P(0))"
BusMaster.SetPost(T(1), P(1))"
BusMaster.SetEFunc(T(1), BGiOUTdn)"
// marcamenti
111
CAPITOLO 5. SISTEMA SOFTWARE
BusMaster.SetTOKs(P(0), 1)"
BusMaster.SetTOKs(P(1), 0)"
// t2
BusMaster.SetFTs(T(2), 1, 2)"
BusMaster.SetPre(T(2), P(3))"
BusMaster.SetPost(T(2), P(2))"
BusMaster.SetEFunc(T(2), BRiup)"
// t3
BusMaster.SetFTs(T(3), 1, 2)"
BusMaster.SetPre(T(3), P(2))"
BusMaster.SetPost(T(3), P(3))"
BusMaster.SetEFunc(T(3), BRidn)"
// marcamenti
BusMaster.SetTOKs(P(2), 1)"
BusMaster.SetTOKs(P(3), 0)"
// t4
BusMaster.SetFTs(T(4), 1, 2)"
BusMaster.SetPre(T(4), P(6))"
BusMaster.SetPost(T(4), P(7))"
BusMaster.SetEFunc(T(4), OWNdn1)"
// t5
BusMaster.SetFTs(T(5), 1, 2)"
BusMaster.SetPre(T(5), P(6))"
BusMaster.SetPost(T(5), P(7))"
BusMaster.SetEFunc(T(5), OWNdn2)"
// t6
BusMaster.SetFTs(T(6), 1, 2)"
BusMaster.SetPre(T(6), P(4))"
BusMaster.SetPost(T(6), P(5))"
BusMaster.SetEFunc(T(6), BBSYdn)"
// t7
BusMaster.SetFTs(T(7), 1, 2)"
BusMaster.SetPre(T(7), P(5))"
BusMaster.SetPost(T(7), P(6))"
BusMaster.SetEFunc(T(7), OWNup)"
// t8
BusMaster.SetFTs(T(8), 0, 0)"
BusMaster.SetPre(T(8), P(7))"
BusMaster.SetPost(T(8), P(4))"
// marcamenti
BusMaster.SetTOKs(P(4), 1)"
BusMaster.SetTOKs(P(5), 0)"
BusMaster.SetTOKs(P(6), 0)"
BusMaster.SetTOKs(P(7), 0)"
// BGiIN (p8)
BusMaster.SetTOKs(P(8), 1)"
// u8
BusMaster.SetRI(U(8), TINIT, +INF, +INF)"
BusMaster.SetRI(U(8), U(8), +INF, +INF)"
BusMaster.SetRI(U(8), D(8), +INF, +INF)"
BusMaster.SetRI(U(8), T(1),
1, +INF)"
BusMaster.SetRI(U(8), T(2),
1, +INF)"
// d8
BusMaster.SetRI(D(8), TINIT,
1, +INF)"
112
// BGiOUTdn
// BRiup
CAPITOLO 5. SISTEMA SOFTWARE
BusMaster.SetRI(D(8),
BusMaster.SetRI(D(8),
BusMaster.SetRI(D(8),
U(8),
1, +INF)"
D(8), +INF, +INF)"
T(3),
1, +INF)"
// BCLR (p9)
BusMaster.SetTOKs(P(9), 1)"
// u9
BusMaster.SetRI(U(9), TINIT, +INF, +INF)"
BusMaster.SetRI(U(9), U(9), +INF, +INF)"
BusMaster.SetRI(U(9), T(5),
1, +INF)"
// d9
BusMaster.SetRI(D(9), TINIT,
1, +INF)"
BusMaster.SetRI(D(9), U(9),
1, +INF)"
BusMaster.SetRI(D(9), D(9), +INF, +INF)"
// BRidn
// BBSYup2
// BCLRup
// AS (p10)
BusMaster.SetTOKs(P(10), 1)"
// u10
BusMaster.SetRI(U(10), TINIT, +INF, +INF)"
BusMaster.SetRI(U(10), U(10), +INF, +INF)"
BusMaster.SetRI(U(10), D(10),
1, +INF)"
// d10
BusMaster.SetRI(D(10), TINIT,
1, +INF)"
BusMaster.SetRI(D(10), U(10),
1, +INF)"
BusMaster.SetRI(D(10), D(10), +INF, +INF)"
// NEED (p11)
BusMaster.SetTOKs(P(11), 0)"
// u11
BusMaster.SetRI(U(11), TINIT,
BusMaster.SetRI(U(11), U(11),
BusMaster.SetRI(U(11), D(11),
// d11
BusMaster.SetRI(D(11), TINIT,
BusMaster.SetRI(D(11), U(11),
BusMaster.SetRI(D(11), D(11),
BusMaster.SetRI(D(11), T(7),
1, +INF)"
+INF, +INF)"
1, +INF)"
+INF,
+INF,
+INF,
1,
+INF)"
+INF)"
+INF)"
+INF)"
TPNGraph BusMaster_g(BusMaster,20)"
cout << "Grafo del Bus Master\n" << BusMaster_g"
int BusArbiter_T14]={0,1,2,3,4,5,6,7,8,9,10,11,12,13}"
int BusArbiter_P14]={0,1,2,3,4,5,6,7,8,9,10,11,12,13}"
int BusArbiter_IP5]={14,15,16,17,18}"
class TPN BusArbiter(14,BusArbiter_T, 14,BusArbiter_P,
0,NULL, 5,BusArbiter_IP)"
// t0
BusArbiter.SetFTs(T(0), 1, 2)"
BusArbiter.SetPre(T(0), P(1))"
BusArbiter.SetPost(T(0), P(0))"
BusArbiter.SetPost(T(0), P(2))"
BusArbiter.SetEFunc(T(0), BG0up)"
// t1
BusArbiter.SetFTs(T(1), 1, 2)"
113
CAPITOLO 5. SISTEMA SOFTWARE
BusArbiter.SetPre(T(1), P(0))"
BusArbiter.SetPost(T(1), P(1))"
BusArbiter.SetEFunc(T(1), BG0dn)"
// t2
BusArbiter.SetFTs(T(2), 1, 2)"
BusArbiter.SetPre(T(2), P(2))"
BusArbiter.SetEFunc(T(2), OWN0dn)"
// marcamenti
BusArbiter.SetTOKs(P(0), 1)"
BusArbiter.SetTOKs(P(1), 0)"
BusArbiter.SetTOKs(P(2), 0)"
// t3
BusArbiter.SetFTs(T(3), 1, 2)"
BusArbiter.SetPre(T(3), P(4))"
BusArbiter.SetPost(T(3), P(3))"
BusArbiter.SetPost(T(3), P(5))"
BusArbiter.SetEFunc(T(3), BG1up)"
// t4
BusArbiter.SetFTs(T(4), 1, 2)"
BusArbiter.SetPre(T(4), P(3))"
BusArbiter.SetPost(T(4), P(4))"
BusArbiter.SetEFunc(T(4), BG1dn)"
// t5
BusArbiter.SetFTs(T(5), 1, 2)"
BusArbiter.SetPre(T(5), P(5))"
BusArbiter.SetEFunc(T(5), OWN1dn)"
// marcamenti
BusArbiter.SetTOKs(P(3), 1)"
BusArbiter.SetTOKs(P(4), 0)"
BusArbiter.SetTOKs(P(5), 0)"
// t6
BusArbiter.SetFTs(T(6), 1, 2)"
BusArbiter.SetPre(T(6), P(7))"
BusArbiter.SetPost(T(6), P(6))"
BusArbiter.SetPost(T(6), P(8))"
BusArbiter.SetEFunc(T(6), BG2up)"
// t7
BusArbiter.SetFTs(T(7), 1, 2)"
BusArbiter.SetPre(T(7), P(6))"
BusArbiter.SetPost(T(7), P(7))"
BusArbiter.SetEFunc(T(7), BG2dn)"
// t8
BusArbiter.SetFTs(T(8), 1, 2)"
BusArbiter.SetPre(T(8), P(8))"
BusArbiter.SetEFunc(T(8), OWN2dn)"
// marcamenti
BusArbiter.SetTOKs(P(6), 1)"
BusArbiter.SetTOKs(P(7), 0)"
BusArbiter.SetTOKs(P(8), 0)"
// t9
BusArbiter.SetFTs(T(9), 1, 2)"
BusArbiter.SetPre(T(9), P(10))"
BusArbiter.SetPost(T(9), P(9))"
BusArbiter.SetPost(T(9), P(11))"
114
CAPITOLO 5. SISTEMA SOFTWARE
BusArbiter.SetEFunc(T(9), BG3up)"
// t10
BusArbiter.SetFTs(T(10), 1, 2)"
BusArbiter.SetPre(T(10), P(9))"
BusArbiter.SetPost(T(10), P(10))"
BusArbiter.SetEFunc(T(10), BG3dn)"
// t11
BusArbiter.SetFTs(T(11), 1, 2)"
BusArbiter.SetPre(T(11), P(11))"
BusArbiter.SetEFunc(T(11), OWN3dn)"
// marcamenti
BusArbiter.SetTOKs(P(9), 1)"
BusArbiter.SetTOKs(P(10), 0)"
BusArbiter.SetTOKs(P(11), 0)"
// t12
BusArbiter.SetFTs(T(12), 1, 2)"
BusArbiter.SetPre(T(12), P(13))"
BusArbiter.SetPost(T(12), P(12))"
BusArbiter.SetEFunc(T(12), BCLRup)"
// t13
BusArbiter.SetFTs(T(13), 1, 2)"
BusArbiter.SetPre(T(13), P(12))"
BusArbiter.SetPost(T(13), P(13))"
BusArbiter.SetEFunc(T(13), BCLRdn)"
// marcamenti
BusArbiter.SetTOKs(P(12), 1)"
BusArbiter.SetTOKs(P(13), 0)"
// BR0 (p14)
BusArbiter.SetTOKs(P(14), 1)"
// u14
BusArbiter.SetRI(U(14), TINIT, +INF, +INF)"
// d14
BusArbiter.SetRI(D(14), TINIT, +INF, +INF)"
// BR1 (p15)
BusArbiter.SetTOKs(P(15), 1)"
// u15
BusArbiter.SetRI(U(15), TINIT, +INF, +INF)"
// d15
BusArbiter.SetRI(D(15), TINIT, +INF, +INF)"
// BR2 (p16)
BusArbiter.SetTOKs(P(16), 1)"
// u16
BusArbiter.SetRI(U(16), TINIT, +INF, +INF)"
BusArbiter.SetRI(U(16), U(16), +INF, +INF)"
BusArbiter.SetRI(U(16), T(7),
1, +INF)" // dopo BG2dn, BR2up
// d16
BusArbiter.SetRI(D(16), TINIT,
1, +INF)"
BusArbiter.SetRI(D(16), U(16),
1, +INF)"
BusArbiter.SetRI(D(16), D(16), +INF, +INF)"
// BR3 (p17)
BusArbiter.SetTOKs(P(17), 1)"
// u17
115
CAPITOLO 5. SISTEMA SOFTWARE
BusArbiter.SetRI(U(17),
BusArbiter.SetRI(U(17),
BusArbiter.SetRI(U(17),
// d17
BusArbiter.SetRI(D(17),
BusArbiter.SetRI(D(17),
BusArbiter.SetRI(D(17),
TINIT, +INF, +INF)"
U(17), +INF, +INF)"
T(10),
1, +INF)" // dopo BG3dn, BR3up
TINIT,
1, +INF)"
U(17),
1, +INF)"
D(17), +INF, +INF)"
// BBSY (p18)
BusArbiter.SetTOKs(P(18), 1)"
// u18
BusArbiter.SetRI(U(18), TINIT,
BusArbiter.SetRI(U(18), U(18),
BusArbiter.SetRI(U(18), D(18),
BusArbiter.SetRI(U(18), T(13),
// d18
BusArbiter.SetRI(D(18), TINIT,
BusArbiter.SetRI(D(18), D(18),
BusArbiter.SetRI(D(18), T(7),
BusArbiter.SetRI(D(18), T(10),
+INF,
+INF,
1,
1,
+INF)"
+INF)"
+INF)"
+INF)"
+INF,
+INF,
1,
1,
+INF)"
+INF)"
+INF)" // dopo BG2dn, BBSYdn
+INF)" // dopo BG3dn, BBSYdn
TPNGraph BusArbiter_g(BusArbiter,30)"
cout << "Grafo del Bus Arbiter\n" << BusArbiter_g"
IntegData Bus(3, 17)"
// 3 grafi e 18 canali
Bus.SetGraph(0, BusControl_g)"
Bus.SetGraph(1, BusMaster_g)"
Bus.SetGraph(2, BusArbiter_g)"
Bus.SetChannel( 0,
Bus.SetChannel( 1,
Bus.SetChannel( 2,
Bus.SetChannel( 3,
Bus.SetChannel( 4,
Bus.SetChannel( 5,
Bus.SetChannel( 6,
Bus.SetChannel( 7,
Bus.SetChannel( 8,
Bus.SetChannel( 9,
Bus.SetChannel(10,
Bus.SetChannel(11,
Bus.SetChannel(12,
Bus.SetChannel(13,
Bus.SetChannel(14,
Bus.SetChannel(15,
Bus.SetChannel(16,
0,T(0),
0,T(1),
1,T(7),
1,T(4),
1,T(5),
1,T(2),
1,T(3),
1,T(8),
1,T(6),
2,T(9),
2,T(10),
2,T(12),
2,T(13),
2,TNONE,
2,TNONE,
1,TNONE,
1,TNONE,
1,U(11))"
1,D(11))"
0,U(2))"
0,D(2))"
0,D(2))"
2,U(17))"
2,D(17))"
2,U(18))"
2,D(18))"
1,U(8))"
1,D(8))"
1,U(9))"
1,D(9))"
1,U(10))"
1,D(10))"
2,U(16))"
2,D(16))"
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
ctrl_NEEDup
ctrl_NEEDdn
mstr_OWNup
mstr_OWNdn
mstr_OWNdn
mstr_BR3up
mstr_BR3dn
mstr_BBSYup
mstr_BBSYdn
arbt_BG3up
arbt_BG3dn
arbt_BCLRup
arbt_BCLRdn
arbt_ASup
arbt_ASdn
mstr_BG2up
mstr_BG2dn
IntegGraph Bus_g(Bus, 20)"
cout << "Grafo del sottosistema Bus\n" << Bus_g"
}
116
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
mstr_NEEDup
mstr_NEEDdn
ctrl_OWNup
ctrl_OWNdn
ctrl_OWNdn
arbt_BR3up
arbt_BR3dn
arbt_BBSYup
arbt_BBSYdn
mstr_BG3up
mstr_BG3dn
mstr_BCLRup
mstr_BCLRdn
mstr_ASup
mstr_ASdn
arbt_BG2up
arbt_BG2dn
Conclusioni
In questa tesi e stato presentata un modello per la progettazione e la validazione
di sistemi hardware, in particolare bus per microcomputer. L' approccio si
basa su una estensione delle Communicating Time Petri Net che permette la
comunicazione tra moduli attraverso segnali, in modo da soddisfare i requisiti
espressivi incontrati nella modellazione di sistemi a bus. L' estensione proposta
mantiene le possibilita di analisi esaustiva proprie delle CmTPN.
Le tecniche di analisi di MTPN sono state implementate in un sistema software che realizza un nucleo di analisi tale da permettere la generazione composizionale dello spazio degli stati e la valutazione di pro li di temporizzazione
per le possibili sequenze di esecuzione del modello.
L' espressivita del modello proposto e stata veri cata con la modellazione
dei meccanismi basilari incontrati nella progettazione di bus per microcomputer. Riuscendo a modellare gli elementi di base per la realizzazione un bus (bus
arbiter, bus master, interrupt controller, ecc.) il modello dimostra di poter essere ecacemente usato nella progettazione di tali sistemi. Come caso concreto
di applicazione e stato modellato ed analizzato il bus VME di Motorola.
Il sistema realizzato e unico nel suo genere, non essendo noti in letteratura
altri tool per l' analisi di raggiungibilita di modelli con temporizzazioni nello
stile delle Time Petri Net. Gli sviluppi futuri del sistema potranno includere:
studio di tecniche atte ad evitare una eccessiva esplosione del grafo degli
stati, magari indagando sulla possibilita di usare per i ring domain delle
transizioni degli intervalli di tempo aperti a destra
uno strumento per facilitare l' esplorazione del grafo degli stati attraverso
un linguaggio di interrogazione di tipo descrittivo
un editor visuale per modelli di Modular Time Petri Net che faciliti al
progettista il compito di de nire il modello da analizzare.
117
Bibliography
1] W.R. Adrion, M.A. Branstad, and J.C. Cherniavsky. Validation, veri cation and testing of computer software. ACM Computing Surveys, 14(2),
June 1982.
2] M. Afghahi and C. Svensson. Performance of synchronous and asynchronous schemes for vlsi systems. IEEE Transactions on Computers,
41(7):858{872, July 1992.
3] T. Agerwala. Putting petri nets to work. IEEE Computer, 12(12):85{94,
December 1979.
4] R. Alur, C. Courcoubetis, and D. Dill. Model checking for real time systems. In Proc. of the 5th Symp. on Logics in Computer Science (LICS),
pages 414{425. IEEE Computer Society Press, 1990.
5] R. Alur, C. Courcoubetis, and D. Dill. Model checking for probabilistic
real-time systems. In Proc. of the 18th ICALP. Madrid, July 1991.
6] R. Alur and D. Dill. Automata for modeling real time systems. In Proc. of
the 17th ICALP, Lecture Notes on Computer Science 443, pages 332{335.
Springer Verlag, 1990.
7] R. Alur and T.A. Henzinger. Logics and models of real time: a survey. In
Real-Time: Theory in Practice, Lecture Notes on Computer Science 600.
Springer Verlag, 1991.
8] M. Ben-Ari, A.Pnueli, and Z.Manna. The temporal logic of branching
time. Acta Informatica, 20:2207{226, 1983.
9] B. Berthomieu and M. Diaz. Modeling and veri cation of time dependent
systems using time petri nets. IEEE Transactions on Software Engineering,
17(3):259+, March 1991.
10] B. Berthomieu and M. Menasche. An enumerative approach fo analyzing
time petri nets. In Proc. IFIP Congress, September 1983.
11] G.V. Bochmann. Hardware speci cation with temporal logic: An example.
IEEE Transactions on Computers, C{31(3):223{231, March 1982.
12] G. Bucci, R. Mattolini, and E. Vicario. A framework for the development of distribuited object-oriented systems. In Proc. Int. Symposium on
Autonomous Decentralized Systems (ISADS), March 1993.
118
BIBLIOGRAPHY
13] G. Bucci and E. Vicario. Compositional validation of time-critical systems
using communicating time petri nets. submitted to IEEE Transactions on
Software Engineering, 1995.
14] J. Calvo, J.I. ACHA, and M. Valencia. Asynchronous modular arbiter.
IEEE Transactions on Computers, C{35(1):67{70, January 1986.
15] E.M. Clarke, E.A. Emerson, and A.P. Sistla. Automatic veri cation of
nite-state concurrent systems using temporal logic speci cations. ACM
Transactions on Programming Languages and Systems, 8(2), April 1986.
16] A.A.S. Danthine. Protocol representation with nite state models. IEEE
Transactions on Communications, COM-28(4), April 1984.
17] D.Dill. Timing assumptions and veri cation of nite-state concurrent systems. In Proc. of the Workshop on Computer Aided Verication Methods
for Finite State Systems. Grenoble, France, 1989.
18] A.L. Dexter. Microcomputer Bus Structures and Bus Interface Design,
volume 32 of Electrical Engineering and Electronics. MARCEL DEKKER,
INC., 270 Madison Avenue, New York, New Jork 10016, 1986.
19] D.B. Gustavson. Computer buses | a tutorial. IEEE Micro, 4(4):7{22,
1984.
20] T.A. Henzinger, Z. Manna, and A. Pnueli. Timed transition systems. Tech.
Rep. 92{1263, Dept. of Computer Science, Cornell University, Itaha, NY,
January 1992.
21] G.J. Holzmann. Protocol design: Rede ning the state of the art. IEEE
Software, January 1992.
22] P. Huber, K. Jensen, and R. Shapiro. Hierarchies in coloured petri nets. In
G. Rozenberg, editor, Advances in Petri Nets 1990, Springer Verlag, 1991.
23] R.M. Keller. Formal veri cation of parallel programs. Communications of
the ACM, 19(7), July 1976.
24] S. Kipnis. Analysis of asynchronous binary arbitration on digital trasmission line buses. IEEE Transactions on Computers, 43(4):484{489, April
1994.
25] S.S. Lam and A.U. Shankar. Protocol veri cation via projections. IEEE
Transactions on Software Engineering, 10(4), July 1984.
26] H. Lee-Kwang, J. Favrel, and P. Baptiste. Generalized petri net reduction
method. IEEE Transactions on Systems, Man and Cybernetics, SE-10(4),
July 1984.
27] N. Leveson. Safety analysis using petri nets. IEEE Transactions on Software Engineering, SE-13(3), March 1987.
119
BIBLIOGRAPHY
28] F.J. Lin and M.T. Liu. Prototcol validation for large scale applications.
IEEE Software, January 1992.
29] Yu-Cheng Liu. The M68000 Microprocessor Family, chapter 7.7, pages
224{234. Prentice-Hall International, Inc., Reading, Massachusetts, 1991.
30] A.J. McAuley. Four state asynchronous architectures. IEEE Transactions
on Computers, 41(2):129{142, February 1992.
31] P. Merlin. A methodology for the design and the implementation of communication protocols. IEEE Transactions on Communications, COM-24(6),
June 1976.
32] P. Merlin and D.J. Farber. Recoverability of communication protocols.
IEEE Transactions on Communications, COM-24(9), September 1976.
33] T. Murata. Petri nets: Properties, analysis and applications. Proceedings
of the IEEE, 77(4), April 1989.
34] M. Notomi and T. Murata. Hierarchical reachability graph og bounded
petri nets for concurrent software analysis. IEEE Transactions on Software
Engineering, 20(5), May 1994.
35] Y.A. Papelis and T.L. Casavant. Speci cation of parallel/distribuited software and systems by petri nets with transition enabling functions. IEEE
Transactions on Software Engineering, 18(3):252+, March 1992.
36] J.L. Peterson. Petri nets. ACM Computing Surveys, 9(3), September 1977.
37] W.W. Plummer. Asynchronous arbiters. IEEE Transactions on Computers, 11(1):37{42, 1972.
38] N.V. Stenning. A data transfer protocol. Computer Networks, 1, September
1976.
39] B. Stroustrup. Il linguaggio C++ - Seconda Edizione. Addison-Wesley
Masson, 1993.
40] I.E. Sutherland. Micropipelines. Communcations of the ACM, 32(6):720{
738, June 1989.
41] I. Suzuki and H. LU. Temporal petri nets and their application to modeling
and analysis of a handshake daisy chain arbiter. IEEE Transactions on
Computers, 38(5):696{704, May 1989.
42] S.H. Unger and C.J. Tan. Clocking schemes for high-speed digital systems.
IEEE Transactions on Computers, C-35(10):880{895, October 1986.
43] E. Vicario. Automated derivation of time bounds for real-time cuncurrent
systems using time petri nets. Forthcoming.
120
BIBLIOGRAPHY
44] E. Vicario. Riformulazione dell' algoritmo di integrazione, veri ca delle required interfaces, soundness theorem. Appunti non pubblicati, September
1994.
45] E. Vicario. Validazione di Sistemi di Tempo Reale Mediante Modelli di
Petri Estesi. Tesi di dottorato, Universita degli Studi di Firenze | Facolta
di Ingegneria, Dipartimento di Sistemi e Informatica, 1994.
46] E. Vicario. A polynomial solution method for systems of inequalities as
encountered in the analysis of time petri nets. submitted to IEEE Transactions on Software Engineering, 1995.
121