Semantica di Scicos

Un segnale x in SCICOS è una coppia {x(t), T }, dove x(t) è una funzione del tempo e T è il tempo di attivazione associato su cui il segnale x può potenzialmente evolversi e cambiare il suo valore [Benveniste (1998)]. Il tempo di attivazione è costituito dall’unione di intervalli di tempo e punti isolati chiamati eventi. Infatti, un segnale generico in SCICOS può essere il risultato del funzionamento sia su segnali continui (intervalli di tempo) che discreti (eventi temporali). Al di fuori del suo tempo di attivazione impostato, un segnale è costretto a rimanere costante come illustrato in

Figura 3.7: Un segnale Scicos rimane costante al di fuori del tempo di attivazione impostato.

Figura 3.7, che mostra l’evoluzione di un segnale ibrido x. I tempi di attivazione sono utilizzati in SCICOS allo stesso modo come i clock sono usati nel linguaggio di programmazione sincrono SIGNAL [Benveniste (1998),Halbwachs (1993)], vale a dire come un meccanismo di controllo del tipo. Ad esempio, due segnali possono essere costretti ad avere identiche serie temporali. In generale, i vari operatori di segnale SCICOS inducono relazioni tra le serie temporali corrispondenti. Dato un generico operatore binario f , il tempo di attivazione impostato del segnale risultante è l’unione delle serie temporali di attivazione dei suoi operandi, cioè:

f({x₁(t), T₁}, {x₂(t), T₂}) = {f (x₁(t), x₂(t)), (T₁∪ T₂)}

È possibile ragionare formalmente sulle serie temporali di segnali SCICOS come nel caso dei clock delle variabili di SIGNAL. Quindi, gli utenti di SCICOS hanno una base solida per attività come l’ottimizzazione del design e l’analisi della pianificazione.

A seconda del tipo di blocco e della direttiva del simulatore, l’invocazione di una funzione computazionale può provocare varie azioni come la valutazione di nuovi output, l’aggiornamento dello stato o il calcolo dello stato derivato. Ci sono quattro tipi di blocchi base in SCICOS: continuo, discreto, a passaggio dello zero e sincro.

Un blocco base continuo (CBB) può avere sia porte regolari di input (output) e porte di evento di input (output) . I CBB possono modellare molto di più rispetto ai soli sistemi dinamici continui. Un CBB può avere uno stato continuo x e uno stato discreto z. Sia u la funzione vettoriale che indica gli ingressi regolari e y le uscite regolari. Quindi un CBB impone le seguenti relazioni:

y= h(t, x, z, u, p)

dove f e h sono funzioni specifiche del blocco e p è un vettore di parametri di costanti. La relazione di cui sopra rappresenta due vincoli sono imposti dal CBB fino a quando nessun evento (impulso) arriva sulle sue porte di input degli eventi. Un evento di input può causare un salto negli stati del CBB. Supponiamo che uno o più eventi arrivino sulle porte degli eventi del CBB al tempo t_e. Quindi gli stati saltano secondo le seguenti equazioni:

x= g_c(t_e, x(t⁻_e), z(t⁻_e), u(t⁻_e), p, n_evprt) y= g_d(te, x(t⁻_e), z(t⁻_e), u(t⁻_e), p, nevprt)

dove g_c e g_d sono funzioni specifiche del blocco, n_evprt designa le porte attraverso le quali sono arrivati gli eventi, e z(t⁻_e) è il valore precedente dello stato discreto z (che rimane costante tra due eventi successivi). Infine, i CBB possono generare segnali di eventi sulle loro porte di evento di uscita. Questi eventi possono essere programmati solo all’arrivo di un evento di input. Se un evento è arrivato al tempo t_e, il tempo di ogni evento di uscita è generato secondo

t_evo= k(t_e, z(t_e), u(t_e), p, n_evprt)

per una funzione k specifica del blocco e dove t_evo è un vettore di valori temporali, dove ogni voce corrisponde ad una porta evento di output. Normalmente tutti gli elementi di t_evo sono più grandi di t_e. Se un elemento è inferiore a t_e, significa semplicemente l’assenza di un segnale di evento di output sulla porta evento di uscita corrispondente. Si noti che l’impostazione “t_evo = t” dovrebbe essere evitata perché la struttura causale risultante è ambigua. Inoltre, notare che l’impostazione “t_evo= t” non significa che l’evento di output sia sincronizzato con l’evento di input perché due eventi possono avere lo stesso tempo senza essere sincronizzati. Il t_evo programmato è registrato all’interno del CBB in un registro che ha dimensioni pari al numero di porte degli eventi di output. Il valore nel registro viene utilizzato per “attivare” gli eventi al tempo specificato. Questo registro può essere precaricato all’inizio della simulazione impostando l’accensione iniziale corrispondente nel CBB. Poiché il registro può contenere un solo valore per porta evento di output, è possibile pianificare un solo evento di output su ciascuna porta degli eventi di output alla volta (sia all’inizio che nel corso della simulazione). In altre parole, quando un nuovo evento è pronto per essere programmato, il vecchio deve essere già stato generato. Un’altra interpretazione è che finché l’evento programmato in precedenza non è ancora stato

attivato, la corrispondente porta di output è considerata occupata, il che significa che non può accettare una nuova programmazione degli eventi. Se il simulatore incontra un tale conflitto, si arresta e restituisce il messaggio di errore relativo al conflitto di eventi [Nikoukhah and Steer (1997)].

Mentre un CBB controlla permanentemente le sue porte di ingresso e aggiorna periodicamente le sue porte di uscita e lo stato continuo, un blocco discreto di base (DBB) agisce solo quando riceve un evento di input e le sue azioni sono istantanee. I DBB possono avere sia input regolari che porte degli eventi di output, ma devono avere almeno una porta di evento di input. I DBB possono modellare sistemi dina-mici discreti. Un DBB può avere uno stato discreto z ma non uno stato continuo. Al momento dell’arrivo degli eventi al tempo t_e, lo stato e gli output di un DBB cambiano come segue

z= fd(te, z(t⁻_e), u(t⁻_e), p, nevprt) y= g_d(t_e, z, u(t_e), p)

dove f_de h_dsono funzioni specifiche del blocco. L’output regolare y rimane costante tra due eventi successivi. In effetti, l’output y e lo stato z sono costanti a tratti, funzioni continue del tempo. Come i CBB, i DBB possono generare eventi di output secondo una funzione specifica k ed i loro eventi possono essere pre-programmati tramite l’attivazione iniziale. La differenza tra un CBB e un DBB è che un DBB non può avere uno stato continuo e che le sue uscite rimangano costanti tra due eventi. Sebbene in teoria i CBB sussumano i DBB, specificando un blocco, come un DBB ha vantaggi prestazionali dal momento che il simulatore può ottimizzare la sua esecuzione perché sa che le uscite del blocco rimangono costanti tra gli eventi. Si noti che il segnale di uscita regolare di un DBB è sempre costante a tratti. Essere costante a tratti non implica necessariamente che un segnale sia discreto. Ad esempio, l’output di un integratore (che è un CBB con uno stato continuo) può, in alcuni casi speciali, essere costante. Tuttavia, i segnali sono costanti a tratti possono essere identificati basandosi esclusivamente sulle proprietà di base dei blocchi che li ha generati. In particolare, in Scicos, ogni segnale di uscita regolare di un DBB è discreto e ogni segnale di uscita regolare di un CBB invariante nel tempo senza stato che riceve solo segnali discreti sui suoi ingressi è anche discreto. Pertanto, è possibile specificare staticamente la natura discreta dei segnali in un modello. Ancora una volta, il compilatore SCICOS si basa su queste informazioni per ottimizzare le prestazioni del simulatore SCICOS.

Un blocco base ad attraversamento dello zero (ZCBB) ha input regolari output degli eventi ma nessuna uscita regolare o input degli eventi. Gli ZCBB possono

generare eventi in uscita solo se almeno uno dei loro ingressi regolari attraversa lo zero (cioè, cambia segno). In tal caso, la generazione dell’evento, e il suo tempismo, possono dipendere dalla combinazione degli input che hanno attraversato lo zero e il segno degli input (poco prima che l’attraversamento si verifichi). L’esempio più semplice di un blocco di base attraversante la superficie è lo zcross [Nikoukhah and Steer (1997)]. Questo blocco genera un evento se tutti gli input attraversano lo zero allo stesso tempo. Gli ingressi dello ZCBB possono iniziare pari a zero, ma non possono rimanere uguale a zero durante la simulazione. Questo è considerato uno stato ambiguo ed è dichiarato come errore. Allo stesso modo l’input di uno ZCBB non dovrebbe attraversare lo zero. Se lo fa, l’attraversamento potrebbe o non potrebbe essere rilevato. Gli ZCBB non possono essere modellati come CBB o DBB perché in questi blocchi, nessun evento di output può essere generato a meno che un evento di input è arrivato in anticipo.

I blocchi Synchro di base (SBB) sono gli unici blocchi in grado di generare eventi di output che sono sincronizzati con i loro eventi di input. Questi blocchi hanno una porta di ingresso di evento unica, un unico input regolare (possibilmente vettoriale), nessuno stato, nessun parametro e due o più porte di uscita degli eventi. A seconda del valore dell’input regolare, l’input dell’evento in entrata viene instradato ad una delle porte di uscita degli eventi. Gli SBB vengono utilizzate per il routing di segnali e per segnali sottocampionati. Esempi tipici sono il blocco di selezione dell’evento e il blocco if-then-else [Nikoukhah and Steer (1997)].

Sincronizzazione. In SCICOS se due segnali evento hanno lo stesso tempo, non sono necessariamente sincronizzati. In altre parole, uno è attivato appena prima o subito dopo l’altro ma non “allo stesso tempo”. Due segnali di eventi possono essere sincronizzati solo quando possono essere ricondotti ad una origine comune (una singola porta di uscita degli eventi) attraverso percorsi di eventi, aggiunte di eventi, interruzioni di eventi e ad un solo SBB. In particolare, un blocco di base non può avere due porte evento di uscita sincronizzate. Questo è possibile, tuttavia, per i super blocchi come il 2-freq clock block.