ITTO20080719A1 - "procedimento per eseguire operazioni in reti di comunicazione, rete di comunicazione e prodotto informatico relativi" - Google Patents

"procedimento per eseguire operazioni in reti di comunicazione, rete di comunicazione e prodotto informatico relativi" Download PDF

Info

Publication number
ITTO20080719A1
ITTO20080719A1 IT000719A ITTO20080719A ITTO20080719A1 IT TO20080719 A1 ITTO20080719 A1 IT TO20080719A1 IT 000719 A IT000719 A IT 000719A IT TO20080719 A ITTO20080719 A IT TO20080719A IT TO20080719 A1 ITTO20080719 A1 IT TO20080719A1
Authority
IT
Italy
Prior art keywords
packet
address
destination
header
field
Prior art date
Application number
IT000719A
Other languages
English (en)
Inventor
Salvatore Pisasale
Gregory Poivre
Alberto Scandurra
Original Assignee
St Microelectronics Sa
St Microelectronics Srl
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by St Microelectronics Sa, St Microelectronics Srl filed Critical St Microelectronics Sa
Priority to ITTO2008A000719A priority Critical patent/IT1391040B1/it
Publication of ITTO20080719A1 publication Critical patent/ITTO20080719A1/it
Application granted granted Critical
Publication of IT1391040B1 publication Critical patent/IT1391040B1/it

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

DESCRIZIONE
“Procedimento per eseguire operazioni in reti di comunicazione, rete di comunicazione e prodotto informatico relativiâ€
TESTO DELLA DESCRIZIONE
Campo dell’invenzione
La presente invenzione si riferisce alle tecniche di comunicazione in un sistema di comunicazione on-chip basato su un approccio di rete.
L’invenzione à ̈ stata sviluppata con particolare attenzione al suo possibile impiego nelle cosiddette architetture Network-on-Chip (NoC), come quelle usate per la comunicazione tra diversi nuclei di Intellectual Property (IP) all’interno di un System on Chip (SoC) che richiedono un elevato livello di prestazioni. Il campo dell’elettronica di consumo,i set top box, la TV digitale, le comunicazioni mobili, il trattamento dell’immagine ed i SoC general purpose sono alcuni esempi di tali applicazioni.
L’invenzione à ̈ tuttavia applicabile a tutti i sistemi di comunicazione che presentano requisiti operativi così come descritti nel seguito.
Descrizione della tecnica nota
I normali protocolli di rete prevedono di solito che l’informazione sia trasportata da entità chiamate pacchetti. Questi pacchetti tipicamente comprendono un’intestazione (header), che trasporta informazioni di controllo come l’identificativo della destinazione, il tipo di funzionamento, e così via, ed un carico utile (payload), che trasporta i dati effettivi coinvolti nell’operazione. Sia l’intestazione, sia il carico utile sono trasmessi allo strato data-link da entità chiamate “flit†(unità di controllo di flusso – flow control unit).
La trasmissione dell’intestazione, sebbene necessaria ed inevitabile, riduce le prestazioni, dato che alcuni “flit†nella trasmissione non sono utilizzati per il trasferimento dei dati veri e propri, ma piuttosto per la propagazione di informazioni accessorie.
I normali protocolli Network-on-Chip ed i tipici formati dei pacchetti, così come descritti per esempio in W. J. Dally, B. Towles “Principles and practices of interconnection networks†Morgan Kaufmann, San Francisco, 2003, pag. 223-225, seguono un approccio a strati e in questo modo il sovraccarico in termini di trasmissione di flit di intestazione non à ̈ sicuramente trascurabile.
Scopo e sintesi dell’invenzione
Lo scopo dell’invenzione à ̈ quindi di minimizzare il numero di flit di intestazione trasmessi in modo da migliorare le prestazioni di rete.
Secondo la presente invenzione, questo scopo à ̈ raggiunto grazie ad un procedimento avente le caratteristiche richiamate specificamente nelle rivendicazioni che seguono. L’invenzione si riferisce anche ad una corrispondente rete di comunicazioni, nonché un prodotto informatico, caricabile nelle memoria di almeno un elaboratore e comprendente porzioni di codice software per attuare i passi del procedimento dell’invenzione quando il prodotto à ̈ eseguito su almeno un elaboratore. Così come qui utilizzato, il riferimento ad un tale prodotto informatico à ̈ inteso essere equivalente al riferimento ad un mezzo leggibile da elaboratore contenente istruzioni per il controllo del sistema di elaborazione per coordinare l’attuazione del procedimento secondo l’invenzione. Il riferimento ad “almeno un elaboratore†à ̈ evidentemente inteso a mettere in luce la possibilità che la presente invenzione sia attuata in forma modulare e/o distribuita.
Le rivendicazioni sono una parte integrante della descrizione dell’invenzione qui fornita.
Una forma di attuazione dell’invenzione si basa sul riconoscimento del fatto che le informazioni di intestazione non sono sempre necessarie, e in realtà possono essere effettivamente utili solo quando questa informazione differisce, in termini di campi significativi (vale a dire campi che caratterizzano la transazione), dall’informazione che à ̈ stata trasmessa precedentemente.
In una forma di realizzazione, il numero di flit di intestazione trasmessi per caratterizzare diverse operazioni à ̈ notevolmente ridotto se paragonato con le soluzioni convenzionali. In termini di cifre quantitative, questo si traduce in una ridotta latenza di trasmissione, una maggiore efficienza di trasmissione ed una migliore utilizzazione del collegamento fisico.
In una forma di realizzazione, il procedimento qui descritto prevede che le informazioni di intestazione siano trasmesse solo quando il campo caratterizzante la transazione differisce dai campi precedentemente trasmessi. Per esempio, in una forma di attuazione preferita, se una sequenza di dati deve essere memorizzata in indirizzi di memoria consecutivi, non c’à ̈ alcuna necessità di specificare l’indirizzo di ciascun elemento della sequenza di dati; à ̈ infatti possibile specificare l’indirizzo solo per il primo pacchetto, e quindi incrementare automaticamente gli indirizzi delle successive celle di memoria di una quantità pari alla dimensione dei dati memorizzati fino a quel momento.
In una forma di attuazione, il cosiddetto initiator e il ricevitore (o la memoria di destinazione) sono sincronizzati e consapevoli della modalità di trasferimento che si sta svolgendo; di conseguenza, la destinazione à ̈ in grado di riutilizzare l’ultima intestazione ricevuta se l’initiator non genera alcune intestazioni.
In una forma di realizzazione, un meccanismo di modalità di trasferimento con generazione dinamica delle intestazioni (Dynamic Header Generation – DHG) viene attuato per generare l’intestazione del pacchetto nella Network-on-Chip solo quando questa informazione à ̈ effettivamente necessaria; viene quindi stabilito un adeguato meccanismo di corrispondenza, al fine di specificare in modo inequivocabile quando una nuova intestazione deve essere trasmessa o meno.
Breve descrizione dei disegni annessi
L’invenzione sarà ora descritta, a titolo di esempio non limitativo, con riferimento alle figure dei disegni annessi, in cui:
- le figure 1a e 1b mostrano sequenze di memorizzazione/scrittura (store) di pacchetti;
- la figura 2 mostra un diagramma di un circuito che esegue le operazioni di generazione di pacchetti da memorizzare/scrivere (store);
- le figure 3a e 3b mostrano sequenze di lettura/carico (load) di pacchetti; e
- la figura 4 mostra un diagramma di un circuito per eseguire le operazioni di generazione dei pacchetti da leggere/caricare (load).
Descrizione particolareggiata di esempi di attuazione dell’invenzione
Il diagramma della figura 1 à ̈ esemplificativo di un sistema di comunicazione per l’uso in un ambiente Networkon-Chip (NoC) che utilizza ad esempio un protocollo (IP) ad alte prestazioni.
Un esempio di un protocollo IP ad elevate prestazioni à ̈ il protocollo STBus, descritto in dettaglio nella pubblicazione “STBus Communication System: Concepts and Definitions†Novembre 2007. Tale documento à ̈ accessibile al sito www.st.com.
In questo protocollo di comunicazione i dati vengono scambiati tra gli iniziatori e le destinazioni per mezzo di transazioni separate e asimmetriche.
In particolare, una transazione di memorizzazione (store), ossia una richiesta di scrivere dati in una destinazione comprende un pacchetto di richiesta, che contiene il numero di elementi (o celle) di dati da memorizzare nella destinazione a partire da un indirizzo iniziale ed un pacchetto di risposta avente solo un singolo elemento.
Allo stesso modo, una transazione di lettura (load), ossia una richiesta di leggere dati da una destinazione, comprende un pacchetto di richiesta, che contiene solo un singolo elemento per specificare il numero di dati da leggere a partire da un indirizzo iniziale, ed un pacchetto di risposta comprendente gli elementi letti.
Le figure 1a ed 1b mostrano esempi di sequenze di operazioni di memorizzazione (store) sul cammino di richiesta, e le figure 2a e 2b mostrano esempi di sequenze di operazioni di lettura (load) sul cammino di risposta.
Nonostante in relazione alla codifica del tipo di operazione da eseguire si faccia riferimento al protocollo STBus, il tecnico esperto apprezzerà che si può usare ogni protocollo di comunicazione in grado di fornire simili richieste di memorizzazione e di lettura.
La figura 1b mostra un possibile meccanismo di generazione dinamica delle intestazioni (DHG) applicato alla sequenza di operazioni di memorizzazione sul cammino di richiesta di figura 1a.
In particolare, la figura 1a mostra una tipica sequenza di pacchetti 11 sul cammino di richiesta trasmessa secondo le note modalità di trasferimento. La sequenza di pacchetti 11 comprende una sequenza di tre pacchetti SP di richiesta di memorizzazione, ciascuno comprendente un pacchetto di intestazione, denominato rispettivamente HD1, HD2 e HD3, e due pacchetti di carico utile, denominati a coppie rispettivamente PL11 e PL12, PL21 e PL22, PL31 e PL32. In questo esempio, si assume che la rete Network-on-Chip abbia un ampio collegamento fisico a 72 bit e che, di conseguenza, per trasmettere i 16 byte dell’operazione di memorizzazione siano richiesti due flit di carico utile, con ogni flit di carico utile che porta 8 byte.
L’esperto del settore apprezzerà che sia il numero di bit del collegamento fisico sia il numero di byte di carico utile possono variare, anche in maniera significativa, senza per questo uscire dall’ambito di protezione dell’invenzione.
Il protocollo STBus à ̈ definito da un codice operativo chiamato “opcode†e da un indirizzo di pacchetto.
Nell’esempio della sequenza delle operazioni di memorizzazione (store) mostrato nella figura 1a, il pacchetto di intestazione HD1 trasporta - in una campo operativo O1 - l’istruzione di memorizzare 16 byte, mentre l’indirizzo OxOO di destinazione à ̈ specificato nel campo indirizzo A1. Il secondo pacchetto di intestazione HD2 trasporta informazioni simili in un corrispondente campo operativo O2 e nel campo indirizzo A2 per memorizzare 16 byte a partire dall’indirizzo 0x10. Infine, il pacchetto di intestazione HD3 trasporta nel campo operativo O3 l’informazione di memorizzare 16 byte all’indirizzo 0x20, specificato nel campo di indirizzo A3.
La figura 1b mostra invece una possibile sequenza di pacchetti 21 sul cammino di richiesta secondo una modalità di trasferimento con generazione dinamica delle intestazioni (DHG), in cui solo una singola intestazione con rispettivi campi O1 e A1 à ̈ necessaria per caratterizzare la transazione. Come mostra la figura 1b, i pacchetti SP da memorizzare in sequenza, contengono lo stesso opcode, nel campo operativo O1, O2 e O3 (cioà ̈ “Store16b†), e di conseguenza solo un singolo pacchetto di intestazione HD1 potrebbe essere utilizzato. L’indirizzo di memoria nel campo indirizzo A1 della figura 1b à ̈ l’indirizzo 0x00.
Durante un meccanismo di generazione dinamica delle intestazioni (DHG), gli indirizzi di memoria originali per le successive operazioni di memorizzazione devono essere generati, per ogni pacchetto di carico utile seguente, incrementando l’indirizzo di memoria iniziale della dimensione dell’opcode (cioà ̈ 16 byte).
In questo modo à ̈ possibile trasmettere le informazioni del pacchetto intestazione HD1 una sola volta all’inizio della transazione, avendo di conseguenza un solo flit di intestazione.
La figura 2 mostra una possibile forma di realizzazione di un circuito per l’attuazione delle operazioni del procedimento per l’esecuzione di transazioni in una rete di comunicazione descritto con riferimento alle figure 1a e 1b.
Nel circuito della figura 2 i pacchetti di carico utile PL possono essere memorizzati in una memoria di carico utile 36 di tipo FIFO (First In First Out). Allo stesso modo, i pacchetti di intestazione HD possono essere memorizzati in una memoria di intestazioni 37 anch’essa di tipo FIFO.
Un primo circuito di controllo 38 à ̈ quindi in grado di leggere i pacchetti di carico utile (cioà ̈ P11, P12,…) dalla memoria FIFO 36. Allo stesso modo, un secondo circuito di controllo 39 à ̈ in grado di leggere i corrispondenti pacchetti di intestazione (ovvero HD1, HD2,…) dalla memoria FIFO 37. Questi pacchetti vengono poi sistemati su due rami paralleli che portano agli ingressi di un multiplexer 35. Il multiplexer 35 emette in uscita la sequenza 21 sotto il controllo di un segnale di selezione (S).
Il segnale di selezione S Ã ̈ generato da un circuito di selezione 100. In una forma di realizzazione, il circuito di selezione 100 ha una configurazione che garantisce che:
a) l’intestazione di una richiesta di transazione di memorizzazione à ̈ sempre generata, poiché le istruzioni di memorizzazione forniscono già il numero di byte da scrivere;
b) l’intestazione del primo flit à ̈ sempre generata; c) le successive intestazioni delle istruzioni di richiesta di memorizzazione non vengono generate se:
- il codice operativo rimane invariato, e - l’indirizzo della successiva transazione à ̈ uguale all’indirizzo precedente incrementato del numero di byte scritti con la precedente istruzione.
Nel seguito, verrà descritta una possibile realizzazione del circuito di selezione 100, utilizzabile in combinazione con il protocollo di comunicazione STBus.
In questo esempio di realizzazione, il circuito di selezione 100 ha tre ingressi.
Un primo ingresso I1 Ã ̈ direttamente connesso ad uno degli ingressi di una porta logica OR 34 che fornisce in uscita il segnale di selezione S.
Un secondo ingresso I2 à ̈ connesso agli ingressi di dato di un insieme di registri 31, la cui uscita à ̈ connessa ad un primo ingresso di un sommatore 32.
Un secondo ingresso del sommatore 32 Ã ̈ direttamente connesso ad un terzo ingresso I3 del circuito di selezione 100.
L’uscita del sommatore 32 rappresenta uno degli ingressi di un comparatore 33, mentre l’altro ingresso di tale comparatore 33 à ̈ anch’esso collegato al secondo ingresso I2 del circuito di selezione 100. L’uscita del comparatore 33 à ̈ infine connessa all’altro ingresso della porta logica OR 34.
Nell’esempio di realizzazione mostrato, i campi indirizzo (cioà ̈ A1, A2,…) sono connessi all’ingresso I2 mentre il codice operativo (cioà ̈ O1, O2 ,…) à ̈ connesso all’ingresso I3. Un segnale di lettura/memorizzazione, suscettibile di rappresentare sia una operazione di lettura, sia una operazione di memorizzazione, può essere connesso al primo ingresso I1 del circuito di selezione 100. Tale segnale di lettura/memorizzazione può essere posto a “1†per le operazioni di lettura e a “0†per le operazioni di memorizzazione. In una realizzazione, il circuito di controllo 39 fornisce i segnali I1, I2, I3.
Il circuito di controllo 39 può inoltre fornire il segnale I1, analizzando il campo operativo del pacchetto intestazione. In un’altra realizzazione, il segnale di lettura/memorizzazione può essere creato internamente dal circuito 100 confrontando il campo operativo presente sull’ingresso I2 con il valore di una operazione di lettura. Gli esperti del ramo non mancheranno di apprezzare l’esistenza di diverse altre implementazioni per generare questi segnali senza uscire per questo dall’ambito dell’invenzione.
Nella forma di realizzazione qui considerata, la condizione a) à ̈ garantita dal segnale di lettura/memorizzazione all’ingresso I1, che à ̈ direttamente connesso all’ingresso della porta logica OR 34.
Le condizioni b) e c) sono garantite dal segnale sul secondo ingresso della porta logica OR 34, che à ̈ generato dai restanti blocchi del circuito 100.
Il segnale indirizzo attuale sull’ingresso I2 à ̈ memorizzato dal registro 31 e di conseguenza il segnale presente sul primo ingresso del sommatore 33 à ̈ l’indirizzo della precedente operazione. Questo indirizzo della precedente operazione viene quindi incrementato di una quantità pari al segnale di codice operativo presente sull’ingresso I3. Questo risultato viene quindi confrontato con l’indirizzo dell’attuale operazione.
La condizione c) à ̈ garantita perché, se il codice operativo cambia o se l’indirizzo della prossima operazione à ̈ diverso dall’indirizzo precedente incrementato del numero di byte scritti con la precedente istruzione, questo fa variare gli ingressi al comparatore 33 e di conseguenza l’uscita del comparatore 33 viene impostata a “1†.
Gli esperti del settore apprezzeranno che possono essere richiesti ulteriori blocchi di conversione per estrarre il numero di byte che devono essere scritti dal codice operativo se il codice stesso non contiene esplicitamente il numero di byte che devono essere scritti.
Con riferimento all’esempio della sequenza 11 della figura 1a, il segnale di lettura/memorizzazione viene posto a “0†e viene trasmessa solo la prima intestazione, in quanto:
- il campo del codice operativo rimane invariato, ovvero O1=O2=O3, e
- l’indirizzo della prossima operazione risulta essere uguale al vecchio indirizzo dell’operazione incrementato del successivo codice operativo, ovvero A2=A1+16byte e A3=A2+16byte.
La figura 3b mostra un possibile meccanismo di generazione dinamica delle intestazioni (DHG) applicato alla sequenza di operazioni di lettura sul cammino di risposta di figura 3a.
Le figure 3a e 3b mostrano sequenze d’esempio di operazioni di lettura (load), che includono quattro pacchetti LP di risposta. Le prime tre intestazioni dei pacchetti LP indicano che 16 byte sono stati letti dalla memoria, mentre l’ultimo pacchetto indica che solo 8 byte sono stati letti.
In particolare, la figura 3a mostra una tipica sequenza di pacchetti 41 sul cammino di risposta trasmessi secondo le note modalità di trasferimento. Tale sequenza di pacchetti 41 include una sequenza di quattro pacchetti LP di risposta alla lettura, ognuno comprendente un pacchetto di intestazione, denominati rispettivamente HD1, HD2, HD3 e HD4, e due pacchetti di carico utile, denominati a coppie rispettivamente PL11 e PL12, PL21 e PL22, PL31 e PL32, per i primi tre pacchetti di carico utile e solo un pacchetto di carico utile PL4 per l’ultimo pacchetto da leggere. Per esempio, l’intestazione può portare informazioni sull’initiator, che sono utilizzate per la trasmissione sulla rete (Network-on-Chip).
Di nuovo, si assume che la rete Network-on-Chip abbia un ampio canale fisico a 72 bit, e di conseguenza, due flit di carico utile sono richiesti per trasmettere i 16 byte di un’operazione di lettura, in cui ogni flit di carico utile porta 8 byte.
Nella sequenza dell’operazione di lettura mostrata in figura 3a, il pacchetto di intestazione HD1 contiene in un campo operativo O’1, l’informazione che sono stati trasmessi 16 byte dell’operazione di lettura, e l’indirizzo 0x00 da cui i dati sono stati letti à ̈ specificato in un campo indirizzo A1. I pacchetti di intestazione HD2 e HD3 portano informazioni simili in cui cambia solo l’indirizzo. Viceversa, l’intestazione HD4 comprende il campo operativo O’4 che indica che solo 8 byte sono stati trasmessi.
In questo caso, il codice operativo à ̈ costante all’interno dei primi tre pacchetti di risposta LP mentre à ̈ diverso per il quarto pacchetto LP. Per quanto riguarda i campi indirizzi, gli indirizzi a cui si deve accedere quando viene richiesta la successiva lettura dei dati sono ricavati semplicemente aggiungendo all’indirizzo iniziale la dimensione del codice operativo successivo sulla base di una metodologia pacchetto per pacchetto.
Nella sequenza di esempio, si assume che lo stesso initiator abbia svolto la sequenza di accessi di lettura e di conseguenza l’identificativo dell’initiator à ̈ lo stesso per tutti i pacchetti. Di conseguenza, à ̈ possibile trasmettere le informazioni di intestazione solo una volta all’inizio delle operazioni di lettura per i primi tre pacchetti di risposta, mentre una nuova intestazione deve essere trasmessa per il quarto pacchetto siccome esso à ̈ caratterizzato da un diverso codice operativo.
La figura 3b mostra una sequenza di pacchetti 51 sul cammino di risposta ottimizzato con la tecnica di generazione dinamica dell’intestazione (DHG). Più in particolare, solo un singolo pacchetto di intestazione HD1 à ̈ necessario per i primi tre pacchetti LP di risposta alla lettura, mentre un’intestazione addizionale HD4 à ̈ richiesta, in quanto il suo campo operazione O’4 à ̈ diverso dai precedenti tre.
Una possibile realizzazione di questo meccanismo à ̈ illustrato in figura 4.
Il circuito di figura 4 Ã ̈ essenzialmente lo stesso del circuito di figura 2, tuttavia, gli ingressi cambiano.
Nello specifico, un segnale di memorizzazione/lettura, rappresentante sia una operazione di memorizzazione sia una operazione di lettura, può essere connesso al primo ingresso I1 del circuito di selezione 100. Tale segnale di memorizzazione/lettura può essere posto a “1†per le operazioni di memorizzazione e a “0†per le operazioni di lettura. Il segnale indirizzo di risposta può quindi essere connesso all’ingresso I2 e il segnale codice operativo di risposta à ̈ connesso al terzo ingresso I3.
Come per il cammino di richiesta, anche il circuito di selezione per il cammino di risposta ha una configurazione destinata a garantire che:
a) sia sempre generata l’intestazione di una operazione di risposta di lettura;
b) sia sempre generata l’intestazione del primo flit; c) le intestazioni successive di operazioni di risposta di lettura non siano generate se:
- il codice operativo rimane invariato, e
- l’indirizzo della prossima operazione à ̈ uguale al precedente indirizzo incrementato del numero di byte letti nella precedente istruzione.
Gli esperti del settore apprezzeranno che l’ingresso I1 può inoltre essere usato per indicare se i flit di risposta che arrivano in ingresso sono affetti da errori e di conseguenza viene forzata la trasmissione di una intestazione completa. È importante sottolineare che, a seconda del modo in cui gli errori sono codificati nel traffico di risposta, la modalità di trasferimento con generazione dinamica delle intestazioni DHG può essere applicata o meno.
Più in particolare, se l’informazione di errore caratterizza un intero pacchetto, ed à ̈ quindi codificata nell’intestazione, e se un nuovo pacchetto di risposta à ̈ affetto da errori, allora si genera un’intestazione anche se le condizioni per applicare la modalità di trasferimento con generazione dinamica delle intestazioni sono soddisfatte. D’altro canto, se l’informazione di errore à ̈ trasportata da un segnale apposito che caratterizza indipendentemente ogni flit, non c’à ̈ la necessità di generare una intestazione dedicata e la modalità di trasferimento con generazione dinamica delle intestazioni può sempre essere applicata.
Il procedimento appena descritto comporta notevoli vantaggi rispetto alle soluzioni convenzionali. Se comparato con le tipiche soluzioni per le applicazioni di rete Network-on-Chip, il procedimento qui proposto offre il vantaggio che il numero di flit di intestazione trasmessi per caratterizzare le differenti operazioni à ̈ ridotto al minimo. In termini di cifre quantitative, questo si traduce in una ridotta latenza di trasmissione, in un aumento dell’efficienza di trasmissione ed in un migliore utilizzo del collegamento fisico.
Le forme di realizzazione illustrate offrono inoltre alcuni vantaggi addizionali come ad esempio:
- un minimo sovraccarico di trasmissione legato alla trasmissione delle intestazioni attraverso la riduzione del numero di flit di intestazione;
- una massima efficienza di trasmissione, definita come il rapporto tra il numero totale di flit trasmessi ed il numero di flit che effettivamente trasportano dati utili;
- una minima latenza tra l’initiator e la destinazione per un determinato percorso di traffico; e
- una migliore utilizzazione del canale fisico di trasmissione.
Di conseguenza, fermo restando il principio dell’invenzione, i particolari di realizzazione e le forme di realizzazione potranno variare, anche in modo significativo, rispetto a quanto descritto ed illustrato, a puro titolo di esempio non limitativo, senza per questo uscire dall’ambito dell’invenzione, così come definita dalle rivendicazioni che seguono.

Claims (17)

  1. RIVENDICAZIONI 1. Procedimento per eseguire operazioni in reti di comunicazione in cui l’informazione à ̈ scambiata tra un initiator ed una destinazione, detta informazione essendo trasportata in pacchetti (SP, LP), detti pacchetti includendo almeno un pacchetto selezionato nel gruppo costituito da: - un pacchetto di richiesta di memorizzazione indicante che si devono trasmettere dati da detto initiator a detta destinazione, - un pacchetto di risposta di memorizzazione indicante che sono stati trasmessi dati da detto initiator a detta destinazione, - un pacchetto di richiesta di lettura indicante che si devono leggere dati da detta destinazione, o - un pacchetto di risposta di lettura indicante che sono stati letti dati da detta destinazione, ed in cui detti pacchetti comprendono: - un’intestazione (HD) che trasporta informazioni di controllo in uno o più campi (O, O’, A, A’) per identificare il tipo di detto pacchetto, e - uno o più carichi utili (PL) se detto pacchetto à ̈ un pacchetto di richiesta di memorizzazione o un pacchetto di risposta di lettura, detti carichi utili trasportando contenuto informativo, caratterizzato dal fatto che il procedimento prevede di omettere la trasmissione di detta intestazione (HD) quando detto uno o più campi (O, O’, A, A’) per identificare il tipo di detto pacchetto contiene valori suscettibili di essere ricostruiti dal valore di detti campi (O, O’, A, A’) nel pacchetto corrente e dal valore di detti campi (O, O’, A, A’) nel pacchetto precedente.
  2. 2. Procedimento secondo la rivendicazione 1, in cui detta intestazione (HD) che trasporta informazioni di controllo in uno o più campi (O, O’, A, A’) per identificare il tipo di detto pacchetto contiene un campo di codice operativo (O, O’) identificante il tipo di detto pacchetto ed un campo di indirizzo (A, A’) contenente un indirizzo di memoria di detta destinazione.
  3. 3. Procedimento secondo la rivendicazione 2, in cui detto pacchetto à ̈ un pacchetto di richiesta di memorizzazione indicante che detta informazione contenuta in detto carico utile (PL) deve essere trasmessa da detto initiator a detta destinazione ed in cui - detto campo di codice operativo (O, O’) contiene il numero di byte in detto carico utile, e - detto campo indirizzo (A, A’) contiene un indirizzo di memoria in cui detta informazione contenuta in detto carico utile (PL) deve essere scritta in detta destinazione.
  4. 4. Procedimento secondo la rivendicazione 3, comprendente le fasi di: - trasmettere detta intestazione per un primo pacchetto di richiesta di memorizzazione in una operazione; - trasmettere detta intestazione per i pacchetti seguenti: a) se il campo di codice operativo (O, O’) di detto pacchetto corrente à ̈ diverso dal campo di codice operativo (O, O’) di detto pacchetto precedente, oppure b) se l’indirizzo di detto pacchetto corrente à ̈ diverso dall’indirizzo di detto pacchetto precedente incrementato del numero di byte in detto carico utile.
  5. 5. Procedimento secondo la rivendicazione 2, in cui detto pacchetto à ̈ un pacchetto di risposta di memorizzazione indicante che i dati devono essere scritti in detta destinazione, ed in cui - detto campo di codice operativo (O, O’) contiene il numero di byte scritti in detta destinazione, e - detto campo di indirizzo (A, A’) contiene un indirizzo di memoria in cui i dati devono essere scritti in detta destinazione.
  6. 6. Procedimento secondo la rivendicazione 5, comprendente la fase di trasmettere detta intestazione per ogni pacchetto di risposta di memorizzazione.
  7. 7. Procedimento secondo la rivendicazione 2, in cui detto pacchetto à ̈ un pacchetto di richiesta di lettura indicante che dati devono essere letti da detta destinazione ed in cui: - detto campo codice operativo (O, O’) contiene il numero di byte che devono essere letti da detta destinazione, e - detto campo di indirizzo (A, A’) contiene un indirizzo di memoria per cui i dati devono essere letti in detta destinazione.
  8. 8. Procedimento secondo la rivendicazione 5, comprendente la fase di trasmettere detta intestazione per ogni pacchetto di richiesta di lettura.
  9. 9. Procedimento secondo la rivendicazione 2, in cui detto pacchetto à ̈ un pacchetto di risposta di lettura indicante che si devono trasmettere dati da detta destinazione a detto initiator ed in cui: - detto campo di codice operativo (O, O’) contiene il numero di byte di detto carico utile, e - detto campo di indirizzo (A, A’), contiene un indirizzo di memoria per cui i dati devono essere letti in detta destinazione.
  10. 10. Procedimento secondo la rivendicazione 7, comprendente le fasi di: - trasmettere detta intestazione per un primo pacchetto di risposta di lettura in una operazione, - trasmettere detta intestazione per i pacchetti successivi: a) se il campo codice operativo (O, O’) di detto pacchetto corrente à ̈ diverso dal campo di codice operativo (O, O’) di detto pacchetto precedente, o b) se l’indirizzo di detto pacchetto corrente à ̈ diverso dall’indirizzo di detto pacchetto precedente incrementato del numero di byte in detto carico utile.
  11. 11. Procedimento secondo una qualsiasi delle rivendicazioni 4 o 10, comprendente le fasi di: - verificare se il campo codice operativo (O, O’) di detto pacchetto corrente cambia rispetto al campo codice operativo (O, O’) di detto pacchetto precedente, o se l’indirizzo di detto pacchetto attuale à ̈ diverso dall’indirizzo di detto pacchetto precedente incrementato del numero di byte in detto carico utile, - memorizzare (31) detto campo di indirizzo corrente (A, A’), detto campo di indirizzo corrente memorizzato rappresentando il campo di indirizzi precedente, - incrementare (32) detto campo di indirizzo memorizzato del numero di byte in detto carico utile (PL), e - confrontare (33) detto campo indirizzo incrementato con detto campo indirizzo corrente (A, A’).
  12. 12. Procedimento secondo la rivendicazione 11, in cui incrementare (32) detto campo indirizzi memorizzato (A, A’) del numero di byte di detto carico utile (PL), include la fase di sommare (32) detto campo indirizzi memorizzato (A, A’) a detto campo codice operativo (O, O’).
  13. 13. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, comprendente le fasi di: - verificare se il campo codice operativo (O, O’) di detto pacchetto corrente cambia rispetto al campo codice operativo (O, O’) di detto pacchetto precedente, o se l’indirizzo di detto pacchetto corrente à ̈ diverso dall’indirizzo di detto pacchetto precedente incrementato del numero di byte in detto carico utile, e - trasmettere detta intestazione se un pacchetto di risposta di lettura o un pacchetto di risposta di memorizzazione à ̈ stato contrassegnato con un errore.
  14. 14. Una rete di comunicazione comprendente almeno un initiator ed almeno una destinazione configurati per eseguire operazioni in reti di comunicazione secondo il procedimento di ciascuna delle rivendicazioni 1 a 13.
  15. 15. Rete secondo la rivendicazione 14, in cui detta rete à ̈ una rete Network-on-Chip.
  16. 16. Rete secondo la rivendicazione 14 o 15, in cui detta rete usa un protocollo (STBus).
  17. 17. Prodotto informatico caricabile nella memoria di almeno un elaboratore e comprendente porzioni di codice per attuare il procedimento secondo una qualsiasi delle rivendicazioni 1 a 13.
ITTO2008A000719A 2008-10-01 2008-10-01 Procedimento per eseguire operazioni in reti di comunicazione, rete di comunicazione e prodotto informatico relativi IT1391040B1 (it)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ITTO2008A000719A IT1391040B1 (it) 2008-10-01 2008-10-01 Procedimento per eseguire operazioni in reti di comunicazione, rete di comunicazione e prodotto informatico relativi

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ITTO2008A000719A IT1391040B1 (it) 2008-10-01 2008-10-01 Procedimento per eseguire operazioni in reti di comunicazione, rete di comunicazione e prodotto informatico relativi

Publications (2)

Publication Number Publication Date
ITTO20080719A1 true ITTO20080719A1 (it) 2010-04-02
IT1391040B1 IT1391040B1 (it) 2011-10-27

Family

ID=40718996

Family Applications (1)

Application Number Title Priority Date Filing Date
ITTO2008A000719A IT1391040B1 (it) 2008-10-01 2008-10-01 Procedimento per eseguire operazioni in reti di comunicazione, rete di comunicazione e prodotto informatico relativi

Country Status (1)

Country Link
IT (1) IT1391040B1 (it)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050198113A1 (en) * 2003-12-31 2005-09-08 Microsoft Corporation Lightweight input/output protocol
US20060262788A1 (en) * 2005-05-23 2006-11-23 Broadcom Corporation Dynamic payload header suppression extensions for IPV6

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050198113A1 (en) * 2003-12-31 2005-09-08 Microsoft Corporation Lightweight input/output protocol
US20060262788A1 (en) * 2005-05-23 2006-11-23 Broadcom Corporation Dynamic payload header suppression extensions for IPV6

Also Published As

Publication number Publication date
IT1391040B1 (it) 2011-10-27

Similar Documents

Publication Publication Date Title
US7174427B2 (en) Device and method for handling MPLS labels
US7916632B1 (en) Systems and methods for handling packet fragmentation
US7283528B1 (en) On the fly header checksum processing using dedicated logic
US6847645B1 (en) Method and apparatus for controlling packet header buffer wrap around in a forwarding engine of an intermediate network node
US7782857B2 (en) Logical separation and accessing of descriptor memories
US9411775B2 (en) iWARP send with immediate data operations
US8085780B1 (en) Optimized buffer loading for packet header processing
US9854072B1 (en) Script-controlled egress packet modifier
JP2008510338A (ja) パケット交換制御用の集積回路及び方法
US7978693B2 (en) Integrated circuit and method for packet switching control
JP2005278175A (ja) 誤り検査方法及び誤り検査システム
US7272675B1 (en) First-in-first-out (FIFO) memory for buffering packet fragments through use of read and write pointers incremented by a unit access and a fraction of the unit access
US7239630B1 (en) Dedicated processing resources for packet header generation
EP2201740B1 (en) High speed packet processing in a wireless network
US7379467B1 (en) Scheduling store-forwarding of back-to-back multi-channel packet fragments
US7158520B1 (en) Mailbox registers for synchronizing header processing execution
US20130346837A1 (en) Communication device
US7180893B1 (en) Parallel layer 2 and layer 3 processing components in a network router
ITTO20080719A1 (it) "procedimento per eseguire operazioni in reti di comunicazione, rete di comunicazione e prodotto informatico relativi"
TW200404206A (en) Increasing memory access efficiency for packet applications
KR20220135562A (ko) 메모리 액세스를 위한 직렬 통신 방법 및 시스템
US20050044261A1 (en) Method of operating a network switch
US8868674B2 (en) Streaming and bulk data transfer transformation with context switching
JP2005303787A (ja) パケット生成装置
US9450890B2 (en) Pipelined egress packet modifier