La waveform OSSIE realizzata

Fig. 4. 7 – Waveform implementata.

Il risultato a video delle operazioni dette è il seguente, Fig 4.8:

Fig. 4. 8 – Risultato a video della waveform implementata.

Tutti i componenti sono stati implementati su un unico nodo GPP come mostra la seguente fiugra (Fig. 4.9).

66

Fig. 4. 9 – Prospetto di OSSIE per la creazione della waveform.

4.2.2.1 Generatore e Ricevitore di pacchetti

Il componente generatore è denominato Pkt_Generator. Così come tutti gli altri componenti, è stato generato come Template (nel Generation Options)

py_comp; e con le caselle di Timing Port Support e di ACE Support non spuntati.

L’unica porta di uscita, (Uses), denominata data_out, è stata aggiunta con interfaccia Standard complexChar. È questa il tipo di interfaccia per tutti i componenti. Queste caratteristiche sono riassunte in Fig. 4.10.

Il generatore mette in uscita un flusso di bit in accordo con la struttura dati generata dall’applicazione ITM. La struttura dati, denominata app_hdr, consiste in un campo sorgente di 8 bit, un campo destinazione di 8 bit, un campo length di 2 byte che indica la lunghezza in byte del messaggio e un campo payload di lunghezza massima 99 byte. Il messaggio trasmesso è quello contenuto nell’array message definito localmente.

Il ricevitore Pkt_receiver è stato creato con porta di ingresso (Provides) data_in e interfaccia complexChar come mostrato in Fig 4.11. Il compito di questo

67

componente è quello di ricavare dal flusso di bit in ingresso la struttura trasmessa dal generatore, e stamparla a video. Questa operazione avviene tramite un buffer di appoggio.

68

Fig. 4. 11 – Prospetto di OSSIE per la creazione del componente Pkt_receiver.

4.2.2.2 Componente DLC

Per semplicità questo componente, rispetto al codice originale, è stato diviso in due: DLC_tx e DLC_rx. Il componete DLC_tx svolge le funzioni di trasmissione del membro left_in della classe Resource del componente DLC di Calit2, mentre invece il componente DLC_rx svolge le funzioni del membro right_in.

4.2.2.2.1 DLC_tx

DLC_tx è stato generato con due porte complexChar: una porta di ingresso (Provides) data_in ed una porta di uscita (Uses) data_out, Fig. 4.12. La porta di ingresso verrà collegata al generatore Pkt_Generator.

Questo componente lascia invariato il messaggio ma converte l’app_hdr in un altro header denominato frame_hdr. Il frame_hdr è una struttura simile a app_hdr con l’aggiunta di un campo id di 11 byte. Il campo id viene settato con il valore sequence number e incrementato ad ogni pacchetto inviato. Nel codice

69

Calit2 questo campo è utilizzato per implementare l’ARQ. Infine, il flusso di dati viene inviato alla porta di uscita.

Nel progeto Calit2, il flusso di dati del componente dlc, in trasmissione, va a riempire una coda d’appoggio. Solo quando un ACK conferma una corretta ricezione, un nuovo pacchetto viene prevelavato dalla coda ed inviato alla porta d’uscita.

Fig. 4. 12 – Prospetto di OSSIE per la creazione del componente DLC_tx.

4.2.2.2.2 DLC_rx

Il componente DLC_rx è stato generato con due porte complexChar, una porta di ingresso (Provides) data_in ed una porta di uscita (Uses) data_out. Queste caratteristiche sono riassunte in Fig 4.13. La porta di uscita verrà collegata al ricevitore Pkt_receiver.

La funzione che svolge questo componente, oltre i controlli sulla corretta ricezione del messaggio, è inversa a quella del DLC_tx, cioè cambia l’header frame_hdr in app_hdr. Il componente Calit2, in più, per ogni pacchetto ricevuto, provvede a trasmettere alla porta di uscita (right out in questo caso) il corrispondente ACK.

70

Fig. 4. 13 – Prospetto di OSSIE per la creazione del componente DLC_rx.

4.2.2.3 Componente RS

La cascata delle due codifiche RS (esterna ed interna) realizzate sono le stesse implementate anche dal componente RS del progetto Calit2. Il componente unico di Calit2 (rs) è stato però suddiviso in due componenti: un componente che implementa la codifica (RS_enc) ed un componente che implementa la decodifica (RS_dec).

Il componente Calit2 per le operazioni di codifica e decodifica chiama, dalla classe Resource, le funzioni membro della classe RS contenuta nel file rs.cc, nella cartella rs. In Fig 4.14 è riportata la cartella rs con in evidenza il file rs.cc.

In questo lavoro, invece di far riferimento a classi esterne, i componenti RS_enc e RS_dec implementano le funzioni membro di rs.cc come funzioni membro della classe figlia RS. Per fare questo nei file RS_enc.h e RS_dec.h è stata aggiunta, nella parte pubblica la definizione della classe RS. Le funzioni membro della classe RS sono poi state definite nei file RS_enc.cpp e RS_dec.cpp del componente.

71

Fig. 4. 14 – Cartella rs con in evidenza il file rs.cc.

4.2.2.3.1 RS_enc

Il componente RS_enc è stato generato con due porte complexChar: una porta di ingresso (Provides) denominata data_in ed una porta di uscita (Uses) denominata data_out. La porta di ingresso verrà collegata alla porta di uscita del componente DLC_tx, la porta di uscita verrà collegata alla porta di ingresso del componente RS_dec.

Le caratteristiche di generazione di questo componente RS_enc sono riassunte in Fig. 4.15.

72

Fig. 4. 15 – Prospetto di OSSIE per la creazione del componente RS_enc.

Nel file RS_enc.h, nella parte pubblica, è stata aggiunta la classe figlia RS (Fig. 4.16). Le funzioni membro di questa classe sono definite nel file RS_enc.cpp con l’operatore di visibilità RS_enc_i::.

73

Fig. 4. 16 – Classe figlia di RS_enc.h..

4.2.2.3.2 RS_dec

Il componente RS_dec è stato generato con due porte complexChar: una porta di ingresso (Provides) denominata data_in ed una porta di uscita (Uses) denominata data_out. La porta di ingresso verrà collegata alla porta di uscita del componente RS_enc, la porta di uscita verrà collegata alla porta di ingresso del componente DLC_rx. Le caratteristiche di generazione di questo componente RS_enc sono riassunte in Fig. 4.17.

Nel file RS_dec.h, nella parte pubblica, è stata aggiunta la classe figlia RS (Fig. 4.18). Le funzioni membro di questa classe sono definite nel file RS_dec.cpp con l’operatore di visibilità RS_enc_i::.

74

Fig. 4. 17 – Prospetto di OSSIE per la creazione del componente RS_dec.

75