ITTO20120851A1 - Sistema di debug, e relativo circuito integrato e procedimento - Google Patents

Description

“Sistema di debug, e relativo circuito integrato e procedimentoâ€

TESTO DELLA DESCRIZIONE

Campo dell’invenzione

La presente invenzione si riferisce ai sistemi e procedimenti di debug.

L’invenzione à ̈ stata sviluppata con particolare attenzione al suo possibile impiego per analizzare il funzionamento di un circuito integrato.

Descrizione della tecnica relativa

I sistemi all’interno di un circuito integrato (System-on-Chip o SoC) e i sistemi in un unico contenitore (System-in-Package o SiP) comprendono tipicamente una pluralità di circuiti che comunicano fra loro tramite un canale di comunicazione condiviso. Ad esempio tale canale di comunicazione può essere un bus o una rete di comunicazione, quale ad esempio una Network-On-Chip (NoC) o Network-in-Package (NiP), e viene spesso denominato rete d’interconnessione (Interconnection Network o ICN).

Ad esempio, tali SoC vengono spesso utilizzati per processori destinati ad applicazioni mobili o multimediali, quali ad esempio cellulari intelligenti, set-top boxes, o router per usi domestici.

Anche se ogni circuito di un SoC à ̈ stato verificato singolarmente, certi problemi possono nascere soltanto quando l’intero sistema opera insieme, ad esempio possono succedere interruzione, blocchi, o la qualità del video o audio può essere insufficiente.

Pertanto sono spesso previsti meccanismi che permettono di identificare l’origine dell’errore ed eventualmente trovare una soluzione. In generale, tali meccanismi di analisi o debug permettono di analizzare il comportamento del circuito a livello di silicio, ovvero direttamente all’interno del circuito integrato. Ad esempio, l’interfaccia di debug di un micro-controllore tipicamente permette di analizzare il contenuto dei registri e memorie del micro-controllore.

Ad esempio, all’interno di un complesso sistema integrato, un problema può nascere a livello di circuito stampato (Printed Circuit Board o PCB), a livello di circuiti integrati, ad esempio all’interno di un SoC, a livello di sistema operativo o a livello di applicazione. In questo caso, alcuni problemi possono comparire anche soltanto quando l’intera piattaforma à ̈ stata assemblata e programmata. Pertanto, un problema potrebbe essere risolto direttamente tramite una modifica a livello di software, ma in generale potrebbero anche essere necessaria una correzione a livello circuitale, ovvero a livello hardware.

Tuttavia, mentre i meccanismi di debug sono spesso adatti per analizzare il comportamento del software, questi meccanismi sono tipicamente insufficienti per verificare il corretto funzionamento di uno specifico circuito.

Scopo e sintesi dell’invenzione

Lo scopo dell’invenzione à ̈ quello di fornire un meccanismo di debug che supera gli inconvenienti sopra delineati.

Infatti, gli inventori hanno osservato che, per analizzare il comportamento di un circuito, sarebbe opportuno un meccanismo che permette non solo di monitorare i dati scambiati tra i vari circuiti, ma anche di generare profili di traffico in diversi punti del sistema integrato.

In vista di raggiungere il suddetto scopo, l’invenzione ha per oggetto un sistema di debug avente le caratteristiche specificate nella rivendicazione 1. L’invenzione riguarda anche un relativo circuito integrato e un relativo procedimento. Ulteriori caratteristiche vantaggiose dell’invenzione formano oggetto delle rivendicazioni dipendenti.

Le rivendicazioni formano parte integrante dell’insegnamento tecnico qui fornito in relazione all’invenzione.

In varie forme di attuazione, il circuito integrato comprendente un processore ed una pluralità di circuiti collegati attraverso una rete di interconnessione. Ad ciascun circuito à ̈ associato una rispettiva interfaccia di comunicazione configurata per scambiare dati tra il rispettivo circuito e la rete di interconnessione.

In varie forme di attuazione, un’unità di debug à ̈ associata ad ogni interfaccia di comunicazione.

In particolare, in varie forme di attuazione, tale unità di debug à ̈ configurabile come:

a) punto d’inserimento di dati, in cui l’unità di debug trasmette dati mediante la rispettiva interfaccia di comunicazione alla rete d’interconnessione, o

b) punto di ricezione di dati, in cui l’unità di debug riceve dati mediante la rispettiva interfaccia di comunicazione dalla rete d’interconnessione.

Ad esempio, in varie forme di attuazione l’unità di debug à ̈ configurabile mediante un registro di configurazione che può essere scritto e letto attraverso istruzioni software che vengono eseguite dal processore.

In varie forme di attuazione, per ciascun’unità di debug à ̈ configurabile la destinazione per la trasmissione dei dati e/o la sorgente per la ricezione dei dati.

In varie forme di attuazione, il profilo di traffico che deve essere trasmesso dall’unità di debug à ̈ anche configurabile, e la trasmissione può anche essere ripetuta.

In varie forme di attuazione, l’unità di debug (DE) invia i dati ricevuti al processore.

In varie forme di attuazione l’unità di debug confronta i dati ricevuti con un dato profilo di traffico e segnala al processore soltanto il risultato del confronto.

Pertanto con le unità di debug qui descritte una prima unità di debug può essere configurata come punto d’inserimento di dati e una seconda unità di debug può essere configurata come punto di ricezione di dati.

In questo caso, il processore o eventualmente anche direttamente la seconda unità di debug configurata come punto di ricezione di dati possono confrontare i dati trasmessi dalla prima unità di debug con i dati ricevuti dalla seconda unità di debug.

Breve descrizione delle rappresentazioni annesse L’invenzione verrà ora descritta a puro titolo di esempio non limitativo con riferimento alle rappresentazioni annesse, in cui:

- le Figure 1 e 4 mostrano schemi a blocchi di possibile forme di attuazione di circuiti integrati che comprendono un’unità di debug secondo la presente descrizione;

- la Figure 2 mostra una generica interfaccia di comunicazione;

- le Figure 3 e 6 a 9 mostrano possibili forme di attuazione di interfaccia di comunicazione secondo la presente descrizione; e

- le Figure 5 e 10 mostrano diagrammi di flussi di procedimenti di debug che possono essere realizzati con alcune forme di attuazione della presente descrizione.

Descrizione particolareggiata di forme di attuazione Nella seguente descrizione sono illustrati vari dettagli specifici finalizzati ad un’approfondita comprensione delle forme di attuazione. Le forme di attuazione possono essere realizzate senza uno o più dei dettagli specifici, o con altri metodi, componenti, materiali ecc. In altri casi, strutture, materiali o operazioni noti non sono mostrati o descritti in dettaglio per evitare di rendere oscuri vari aspetti delle forme di attuazione.

Il riferimento ad “una forma di attuazione†nell’ambito di questa descrizione sta ad indicare che una particolare configurazione, struttura o caratteristica descritte in relazione alla forma di attuazione à ̈ compresa in almeno una forma di attuazione. Quindi, frasi come “in una forma di attuazione†, eventualmente presenti in diversi luoghi di questa descrizione, non sono necessariamente riferite alla stessa forma di attuazione. Inoltre, particolari conformazioni, strutture o caratteristiche possono essere combinati in un modo adeguato in una o più forme di attuazione.

I riferimenti qui utilizzati sono soltanto per comodità e non definiscono dunque l’ambito di tutela o la portata delle forme di attuazione.

Come menzionato in precedenza, lo scopo della presente descrizione à ̈ quello di realizzare un meccanismo di debug che permette di analizzare meglio il funzionamento di un sistema integrato.

La Figura 1 mostra una forma di attuazione di un tipico SoC 1.

Nella forma di attuazione considerata, il sistema comprende un processore 10 ed una o più memorie 20. Ad esempio, nella forma di attuazione considerata sono mostrati una piccola memoria interna 20a, quale ad esempio una memoria RAM (Random-Access Memory), una memoria non voltatile 20b, quale ad esempio una memoria flash, e un interfaccia di comunicazione 20c per una memoria esterna, quale ad esempio un’ulteriore memoria DDR.

Nella forma di attuazione considerata, il sistema comprende anche circuiti d’interfaccia 30, quale ad esempio porte di ingresso e uscita (I/O), un’interfaccia UART (Universal Asynchronous Receiver-Transmitter), un’interfaccia SPI (Serial Peripheral Interface), un’interfaccia USB (Universal Seria Bus), e/o altre interfacce di comunicazioni digitali e/o analogici.

Nella forma di attuazione considerata, il sistema comprende anche ulteriori periferiche 40, quali ad esempio comparatori, timer, convertitori analogici/digitali o digitali/analogici, etc.

Nella forma di attuazione considerata, tali moduli, ovvero i blocchi 10, 20 0 e 40, sono collegati insieme attraverso un canale di comunicazione 70, quale ad esempio un bus o preferibilmente una Network-On-Chip (NoC).

L’architettura generale descritta in precedenza viene spesso utilizzata per convenzionali micro-controllori, il che rende una descrizione dettagliata qui superflua. Sostanzialmente tale architettura permette di interfacciare il processore 10 con i vari blocchi 20, 30 e 40 tramite comandi software che vengono eseguiti mediante il processore 10.

I blocchi descritti in precedenza vengono spesso utilizzati in una pluralità di diversi SoC e sono tipicamente ben testati.

Invece, nei processori multimediali o mobili vengono aggiunti altri blocchi 50 a tale architetture generica, che in seguito verranno chiamati circuiti Intellectual Property (IP). Ad esempio, tali blocchi IP 50 possono comprendere un codificatore o decodificatore d’immagine o video 50a, un codificatore o decodificatore di segnali audio 50b, un interfaccia di comunicazione WiFi 50c, o in generale blocchi, la cui struttura hardware à ̈ ottimizzato per l’implementazione di funzioni che dipendono dall’applicazione del sistema. Tali blocchi possono anche essere autonomi e interfacciarsi direttamente con gli altri blocchi del sistema, ad esempio le memorie 20 e le altre periferiche 30 e 40.

Tipicamente a ciascun blocco IP 50 à ̈ associato una rispettiva interfaccia di comunicazione 80 configurata per scambiare dati tra il blocco IP 50 e il canale di comunicazione 70. Ad esempio, a tale scopo l’interfaccia 80 comprende tipicamente una o più memorie FIFO (First-In First-Out) e un circuito configurato per convertire il protocollo di comunicazione del rispettivo blocco IP 50 nel protocollo del canale di comunicazione 70.

Nella forma di attuazione considerata, il sistema comprende inoltre un’interfaccia di debug 60. Nei sistemi noti, tale interfaccia 60 permette di monitorare tipicamente i registri del processore 10, gli registri delle altre periferiche 30 e 40, che tipicamente vengono chiamati SFR (Special Function Registers), e di scaricare il contenute delle memorie 20. In alcuni casi, l’interfaccia di debug 60 permette anche di variare il contenute di tali registri e delle memoria 20.

In varie forme di attuazione, l’interfaccia di debug 60 può anche monitorare il canale di comunicazione 70, ovvero rilevare l’identificatore dell’iniziatore di una comunicazione, l’identificatore della destinazione della comunicazione e i dati scambiati.

Tuttavia, in generale non sono previsti meccanismi che permettono di monitorare direttamente il funzionamento dei blocchi IP 50. Spesso quest’analisi può essere effettuata soltanto indirettamente, ad esempio controllando il contenuto delle memorie 20 associati ad un certo blocco IP 50.

Pertanto in varie forme di attuazione, vengono aggiunti altri circuiti che permette di interagire anche direttamente con i singoli blocchi 50.

Nella forma di attuazione considerata, le interfacce di comunicazione 80 vengono modificati e viene aggiunta un’unità di debug DE che à ̈ configurabile.

Ad esempio, in una forma di attuazione preferita, ogni unità di debug DE comprende una pluralità di registri di configurazione che possono essere configurati, ovvero scritti e letti, tramite il processore 10. Ad esempio, in una forma di attuazione, tali registri di configurazione di ogni unità di debug DE possono essere configurati come i registri di configurazioni delle altre periferiche 30 e 40.

Ad esempio, nella forma di attuazione considerata, il processore 10 può eseguire operazioni di codice software che richiedono la configurazione di una specifica unità di debug DE. Tale commando di configurazione viene inviato al canale di comunicazione 70 e inoltrato al rispettivo interfaccia 80.

Ad esempio, in una forma di attuazione, ogni unità di debug DE permette di trasmettere profili di traffico. Preferibilmente, l’unità di debug DE sfrutta a tale scopo gli esistenti circuiti della rispettiva interfaccia 80. Ad esempio, in una forma di attuazione, l’unità di debug DE memorizza direttamente i dati nella memoria FIFO della rispettiva interfaccia 80, e pertanto l’unità di debug DE può avere una bassa complessità, ad esempio può anche non comprendere una memoria FIFO.

Pertanto, nella forma di attuazione considerata, l’utente può generare profili di traffico sfruttando l’esistente architettura del sistema, in particolare il processore 10, il canale di comunicazione 70, ed eventualmente la memoria 20.

Ad esempio, in una forma di attuazione, l’unità di debug DE supporta due modi di funzionamento.

Nel primo modo di funzionamento, l’utente può inserire attraverso l’unità di debug DE profili di traffico personalizzati. Ad esempio, questo modo può essere utilizzato per inserire nella memoria FIFO della rispettiva interfaccia 80 dati che successivamente vengono trasmessi attraverso il canale di comunicazione 70 ad un altro circuito del sistema, ad esempio ad una memoria 20 o un’interfaccia 80 di un ulteriore blocco IP 50.

In una forma di attuazione, tale modo di funzionamento supporta anche un modo di ripetizione, in cui lo stesso profilo di traffico personalizzato viene trasmesso una pluralità di volte.

Nel secondo modo di funzionamento, l’unità di debug DE genera autonomamente profili di traffico predefiniti. Ad esempio, l’utente potrebbe selezionare e/o configurare (mediante un’opportuna programmazione dei registri di configurazione) certi profili di traffico predefiniti.

In una forma di attuazione, l’unità di debug DE permette in questo caso anche di verificare direttamente l’integrità dei dati. Ad esempio, questo modo di funzionamento può essere utilizzato per generare profili di traffico predefiniti che vengono trasmessi attraverso il canale di comunicazione 70 ad una altra interfaccia 80 la cui unità di debug DE verifica autonomamente l’integrità dei dati.

In seguito verrà ora descritto una possibile forma di attuazione dell’interfaccia di comunicazione 80 e della rispettiva unità di debug DE.

La Figura 2 mostra uno schema a blocchi di una generica interfaccia di comunicazione 80.

Nella forma di attuazione considerata, l’interfaccia di comunicazione 80 comprende tre blocchi distinti:

- una memoria 802 per il salvataggio temporaneo di dati in ingresso e/o uscita, ovvero dei dati proveniente dal rispettivo blocco IP 50 e/o dal canale di comunicazione 70, quale ad esempio una memorie FIFO di ricezione e una memorie FIFO di trasmissione,

- un’interfaccia 804 per scambiare dati tra la memoria 802 e il canale di comunicazione 70, ad esempio per inviare i dati salvati nella memorie FIFO di trasmissione al canale di comunicazione 70 e salvare i dati ricevuti dal canale di comunicazione 70 nella memorie FIFO di ricezione, e

- un circuito di controllo 806 che, ad esempio, controlla il flusso di dati tra il blocco IP 50 e il canale di comunicazione 70, monitora lo stato della memoria 802 e genera i segnali di controllo per il blocco IP 50.

Nella forma di attuazione considerata non à ̈ mostrata nessuna interfaccia per lo scambio di dati tra il blocco IP 50 e la memoria 804, perché tipicamente il blocco IP 50 à ̈ in grado di scambiare i dati direttamente con la memoria 802, ad esempio sfruttando i segnali di controllo generati dal circuito di controllo 806. Ad esempio, tipicamente l’accesso alla memoria 802 à ̈ un accesso DMA (Direct Memory Access).

Invece la Figura 3 mostra uno schema a blocchi di un’interfaccia di comunicazione 80 modificata.

Nella forma di attuazione considerata, l’interfaccia 80 comprende inoltre:

- un registro di configurazione 808 che può essere scritto e/o letto attraverso il processore 10 del sistema, e

- un’unità di debug DE che può scambiare dati con la memoria 802, ad esempio scrivere dati nella memoria FIFO di trasmissione o ricevere dati dalla memoria FIFO di ricezione.

In varie forme di attuazione, il registro di configurazione 808 può essere scritto e letto come gli registri di configurazioni delle altre periferiche 30 e 40, ad esempio assegnando al registro di configurazione 808 uno specifico indirizzo o intervallo di indirizzi, tenendo conto che alle varie interfacce di comunicazione 80 vengono assegnati preferibilmente diversi indirizzi o intervalli di indirizzi per permettere una configurazione individuale di ogni registro di configurazione 808. Ad esempio, nel caso in cui si utilizzasse una NoC, ciascun’interfaccia di comunicazione 80 avrebbe già un diverso indirizzo di rete. In questo caso, tutti i registri di configurazione 808 potrebbero avere anche lo stesso indirizzo di memoria locale.

In varie forme di attuazione, il registro di configurazione 808 permette di attivare l’unità di debug DE. Ad esempio, nella forma di attuazione considerata, tramite la programmazione di un flag nel registro di configurazioni 808 si può decidere se lo scambio di dati avviene con il blocco IP 50 o con l’unità di debug DE.

Ad esempio nella forma di attuazione considerata, l’interfaccia 80 comprende un multiplexer/demultiplexer 810 che collega selettivamente l’unità di controllo 806 e le memoria 802 al blocco IP 50 o all’unità di debug DE, in cui la selezione viene controllato in base ai valori memorizzati nel registro di configurazione 808.

Come menzionato in precedenza, in varie forme di attuazione, il registro di configurazione 808 permette di controllare inoltre il funzionamento dell’unità di debug DE.

Ad esempio, in una forma di attuazione, l’unità di debug DE può essere configurata come punto di inserimento di dati o come punto di ricezione di dati.

Quando l’unità di debug DE à ̈ configurata come punto di inserimento di dati, l’unità di debug DE genera certi profili di traffico, che come descritto in precedenza possono essere personalizzati e/o preimpostati. Ad esempio, in una forma di attuazione, à ̈ possibile impostare attraverso il registro di configurazione 808 la destinazione della comunicazione. Ad esempio, in una forma di attuazione, un indirizzo d’inizio all’interno della o delle memorie 20 può essere specificato e l’unità di debug DE invia successivamente i dati ai rispettivi indirizzi in tale memoria 20, ad esempio incrementando automaticamente l’indirizzo dopo ogni operazione di scrittura.

Invece, quando l’unità di debug DE à ̈ configurata come punto di ricezione di dati, l’unità di debug DE permette la ricezione di dati. Ad esempio, in una forma di attuazione, l’unità di debug DE monitora i dati ricevuti nella memoria 802.

Inoltre, in varie forme di attuazione, quando l’unità di debug DE à ̈ configurata come punto di ricezione di dati, l’unità di debug DE può anche richiedere autonomamente dati da una destinazione. Ad esempio, in una forma di attuazione, un indirizzo d’inizio all’interno della o delle memorie 20 può essere specificato e l’unità di debug DE legge successivamente i dati salvati ai rispettivi indirizzi in tale memoria, ad esempio incrementando automaticamente l’indirizzo dopo ogni operazione di lettura.

Ad esempio, la Figura 4 mostra una forma di attuazione di un SoC, in cui due unità di debug DEae DEbsono attivate, in cui la prima unità di debug DEadell’interfaccia 80a à ̈ configurato come punto di inserimento di dati e la seconda unità di debug DEbdell’interfaccia 80b à ̈ configurato come punto di ricezione di dati.

Ad esempio, in questo modo, l’unità di debug DEapotrebbe scrivere dati in una memoria 20 e l’unità di debug DEbpotrebbe leggere i dati di nuovo dalla stessa memoria 20.

Pertanto, controllando i dati letti dalla memoria 20, à ̈ possibile verificare l’integrità dei dati. Ad esempio, tale operazione può essere effettuata tramite il processore 10 che scarica i dati letti dall’unità di debug DEb. Tuttavia, in generale, anche l’unità di debug DE potrebbe verificare direttamente l’integrità dei dati. Ad esempio, a tale scopo lo stesso profilo di traffico potrebbe essere configurato sia nel punto di inserimento di dati DEasia nel punto di ricezione di dati DEb. In questo caso, il punto di ricezione di dati DEbpotrebbe verificare autonomamente se i dati ricevuti, ad esempio letti dalla memoria 20, corrispondono al profilo di traffico configurato precedentemente.

Ad esempio, la Figura 5 mostra un diagramma di flusso di una forma di attuazione, in cui il processore 10 Ã ̈ programmato per controllare tutte le fasi della verifica.

Dopo un passo d’inizio 1000, il processore 10 configura ad un passo 1002 l’unità di debug DEadell’interfaccia 80a come punto di inserimento di dati, ad esempio configurando la memoria di destinazione 20 e l’indirizzo di memoria di inizio e l’indirizzo di memoria di fine.

Ad un passo 1004, il processore 10 carica un profilo di traffico personalizzato nell’unità di debug DEa.

Successivamente, il processore 10 aspetta ad un passo 1006 fino a quando lo scambio di dati tra l’unità di debug DEae la memoria di destinazione 20 à ̈ completato.

Ad un passo 1008, il processore 10 configura l’unità di debug DEbdell’interfaccia 80b come punto di ricezione di dati, ad esempio configurando la stessa memoria di destinazione 20 e gli stessi indirizzi di memoria di inizio e di fine.

Pertanto, il processore 10 può accedere attraverso l’unità di debug DEballa memoria di destinazione 20.

Successivamente, il processore 10 può scaricare ad un passo 1010 i dati letti dall’unità di debug DEbe verificare ad un passo 1012 la correttezza dei dati ricevuti.

Infine, il processore 10 può inviare ad un passo 1014 il risultato della verifica all’utente, ad esempio utilizzando una delle interfacce di comunicazione 30 del sistema 1, e la procedura termina ad un passo di fine 1016.

La Figura 6 mostra una possibile forma di attuazione dell’unità di debug DE quando essa à ̈ configurata come punto di inserimento di dati, in particolare nel modo di funzionamento con profili di traffico personalizzati.

Nella forma di attuazione considerata, l’unità di debug DE comprende un modulo CP responsabile per la generazione dei dati da inviare alla memoria 802 dell’interfaccia 80.

Nella forma di attuazione considerata, tale modulo CP può essere configurato attraverso il processore 10, ad esempio tramite un commando che scrive il profilo di traffico ad un dato indirizzo di memoria associata al modulo CP.

Nella forma di attuazione considerata, l’unità di debug DE comprende inoltre un circuito di controllo 812 che gestisce la trasmissione dei dati forniti dal modulo CP alla memoria 802. Ad esempio, nella forma di attuazione considerata, il circuito di controllo 812 invia i dati alla memoria FIFO di trasmissione.

Nella forma di attuazione, il circuito di controllo 812 può essere configurato per generare un interrupt INT quando la trasmissione dei dati à ̈ terminata. Questo interrupt INT può essere un interrupt hardware, ovvero collegato direttamente al processore 10, e/o software, ovvero mediante un flag all’interno del registro di configurazione 808.

Nella forma di attuazione, l’unità di debug DE può anche essere configurata per ripetere la trasmissione del profilo di traffico. Ad esempio, nella forma di attuazione considerata, l’uscita della memoria di trasmissione viene anche collegata al modulo CP, in modo tale che i dati trasmessi vengono reinseriti tramite il modulo CP nella memoria di trasmissione. Ad esempio, nella forma di attuazione considerata à ̈ mostrato un multiplexer 816 che permette di selezionare se il modulo CP riceve i dati dalla memoria di trasmissione 802 o dal processore 10.

Come menzionato in precedenza, in varie forme di attuazione, l’unità di debug DE può essere configurata per generare profili di traffico preimpostati.

Ad esempio, la Figura 7 mostra una possibile forma di attuazione dall’unità di debug DE quando essa à ̈ configurata come punto di inserimento di dati, che supporta un modo di funzionamento con profili di traffico personalizzati e un modo di funzionamento con profili di traffico preimpostati.

Sostanzialmente, la forma di attuazione à ̈ basata sulla forma di attuazione mostrata nella Figura 6, con l’aggiunta di un modulo PP configurato per generare profili di traffico preimpostati.

Ad esempio, nella forma di attuazione considerata, sia il modulo CP che generare profili di traffico personalizzati sia il modulo PP che generare profili di traffico preimpostati sono collegati al circuito di controllo 812 che seleziona, ad esempio in base alla configurazione memorizzata nel registro di configurazione 808, quali dati devono essere trasmessi mediante l’interfaccia di comunicazione 80.

Tipicamente, il modulo PP supporta diversi profili di traffico C che possono essere scelti, ad esempio tramite un’opportuna configurazione del registro di configurazione 808. Inoltre, anche il profilo di traffico C se stesso potrebbe essere configurabile.

La Figura 8 mostra una possibile forma di attuazione dell’unità di debug DE quando essa à ̈ configurata come punto di ricezione di dati.

Nella forma di attuazione considerata, l’unità di debug DE comprende un modulo CP che:

a) richiede mediante l’interfaccia 80 la lettura di dati da una data destinazione, e

b) invia i dati letti al processore 10.

Anche in questo caso, il modulo CP può essere configurato attraverso il processore 10, ad esempio tramite un commando che scrive un indirizzo di memoria d’inizio e/o di fine nel registro di configurazione 808.

Nella forma di attuazione considerata, l’unità di debug DE comprende inoltre un circuito di controllo 810 che gestisce la richiesta dei dati dagli indirizzi di memoria configurati e inoltra i dati al modulo CP.

Anche in questo caso può essere previsto che il circuito di controllo 810 generare uno interrupt quando la ricezione dei dati à ̈ terminata. Tuttavia, in generale, l’unità di debug DE potrebbe anche scaricare soltanto dati, quando il processore richiede la lettura di dati da un certo indirizzo di memoria associato al modulo CP, ovvero con ogni operazione di lettura dal indirizzo associato al modulo CP viene scaricato attraverso l’interfaccia 80 un dato dalla memoria di destinazione.

Come menzionato in precedenza, l’unità di debug DE potrebbe verificare anche autonomamente l’integrità dei dati.

Ad esempio la Figura 9 mostra una possibile forma di attuazione dell’unità di debug DE quando essa à ̈ configurata come punto di ricezione di dati, che supporta un modo di funzionamento in cui i dati ricevuti possono essere verificati.

Sostanzialmente, la forma di attuazione à ̈ basata sulla forma di attuazione mostrata nella Figura 8, con l’aggiunta di un modulo PP che permette di verificare profili di traffico preimpostati.

Ad esempio, nella forma di attuazione considerata tale modulo PP corrisponde sostanzialmente al modulo PP descritto con riferimento alla Figure 7. Pertanto anche tale modulo PP può essere configurato per generare profili di traffico preimpostati C. Ad esempio, tipicamente lo stesso profilo di traffico viene configurato per un punto di trasmissione e per un punto di ricezione. In questo caso, i dati generati dal modulo PP del punto di ricezione dovrebbero essere identici a quelli ricevuti.

Pertanto nella forma di attuazione considerata, i dati ricevuti mediante il circuito di controllo 812 e i dati generati dal modulo PP vengono confrontati ad un comparatore 814, e nel caso in cui i dati non corrispondessero può essere generato un segnale di errore, quale ad esempio un interrupt hardware e/o software.

Ad esempio, la Figura 10 mostra un diagramma di flusso di una forma di attuazione, in cui il processore 10 configura due unità di debug DEae DEbper eseguire autonomamente una verifica di integrità dei dati (vedere la Figura 3 per uan possibile forma d’attuazione dell’architettura hardware del sistema).

Dopo un passo d’inizio 2000, il processore 10 configura ad un passo 2002 l’unità di debug DEadell’interfaccia 80a come punto di inserimento di dati, ad esempio configurando la memoria di destinazione 20 e l’indirizzo di memoria di inizio e l’indirizzo di memoria di fine.

Ad un passo 2004, il processore 10 configura il profilo di traffico preimpostato che il modulo PP dell’unità di debug DEadeve generare.

Successivamente, il processore 10 aspetta ad un passo 2006 fino a quando lo scambio di dati tra l’unità di debug DEae la memoria di destinazione 20 à ̈ completato.

Ad un passo 2008, il processore 10 configura l’unità di debug DEbdell’interfaccia 80b come punto di ricezione di dati, ad esempio configurando la stessa memoria di destinazione 20 e gli stessi indirizzi di memoria di inizio e di fine.

Ad un passo 2010, il processore 10 configura il profilo di traffico C che il modulo PP dell’unità di debug DEbdeve generare, in cui tale profilo di traffico corrisponde al profilo di traffico configurato al passo Successivamente, il processore 10 può verificare ad un passo 2012 soltanto il risultato della comparazione fornito dal comparatore 814 dell’unità di debug DEb.

Infine, il processore 10 può inviare ad un passo 2014 il risultato della verifica all’utente, ad esempio utilizzando una delle interfacce di comunicazione 30 del sistema 1, e la procedura termina ad un passo di fine 2016.

Pertanto, grazie alle soluzioni qui descritte, il funzionamento del sistema 1 può essere monitorato in diversi punti del sistema. Infatti, le unità di debug DE descritte qui permettono di tramettere e ricevere dati in diversi punti del sistema. Pertanto, à ̈ possibile monitorare, ad esempio, il funzionamento del canale di comunicazione 70, delle memorie 20, o anche di singoli blocchi IP 50 inviando profili di traffico che emulano il funzionamento di altri componenti del sistema.

Infine, la complessità dei circuiti addizionali à ̈ minima, perché vengono riutilizzati componenti già esistenti, in particolare la parte di ricezione e trasmissione delle interfacce di comunicazione 70.

Naturalmente, fermo restando il principio dell’invenzione, i particolari di costruzione e le forme di realizzazione potranno essere ampiamente variati rispetto a quanto descritto ed illustrato a puro titolo di esempio, senza per questo uscire dall'ambito della presente invenzione, così come definito dalle rivendicazioni che seguono.

Claims (11)

1. RIVENDICAZIONI 1. Un sistema comprendente un processore (10) ed una pluralità di circuiti (50) collegati attraverso una rete di interconnessione (70), in cui ad ciascun circuito (50) à ̈ associato una rispettiva interfaccia di comunicazione (80) configurata per scambiare dati tra il rispettivo circuito (50) e detta rete di interconnessione (70), caratterizzato dal fatto che un’unità di debug (DE) à ̈ associata ad ogni interfaccia di comunicazione (80), in cui ogni unità di debug (DE) à ̈ configurabile come: a) punto d’inserimento di dati, in cui detta unità di debug (DE) trasmette dati mediante la rispettiva interfaccia di comunicazione (80) a detta rete d’interconnessione (70), o b) punto di ricezione di dati, in cui detta unità di debug (DE) riceve dati mediante la rispettiva interfaccia di comunicazione (80) da detta rete d’interconnessione (70).
2. 2. Sistema secondo la rivendicazione 1, in cui detta unità di debug (DE) comprende un registro di configurazione configurabile attraverso istruzioni software eseguite da detto processore (10).
3. 3. Sistema secondo la rivendicazione 1 o la rivendicazione 2, in cui la destinazione per la trasmissione di detti dati e/o la sorgente per la ricezione di detti à ̈ configurabile.
4. 4. Sistema secondo una delle precedenti rivendicazioni, in cui detta unità di debug (DE) à ̈ configurata per generare uno interrupt hardware e/o software quando la trasmissione e/o la ricezione di detti dati à ̈ completata.
5. 5. Sistema secondo una delle precedenti rivendicazioni, in cui detta unità di debug (DE) comprende: a) un primo modulo di trasmissione (CP) configurato per: - ricevere da detto processore (10) un profilo di traffico personalizzato, e - trasmettere (812, 810) detto profilo di traffico personalizzato mediante la rispettiva interfaccia di comunicazione (80) a detta rete d’interconnessione (70), e/o b) un secondo modulo di trasmissione (PP) configurato per: - ricevere da detto processore (10) una richiesta di selezione e/o configurazione di un profilo di traffico preimpostato (C), e - trasmettere (812, 810) detto profilo di traffico preimpostato (C) mediante la rispettiva interfaccia di comunicazione (80) a detta rete d’interconnessione (70).
6. 6. Sistema secondo la rivendicazione 5, in cui detta unità di debug à ̈ configurato (816) per ripetere la trasmissione di detto profilo di traffico personalizzato e/o preimpostato (C).
7. 7. Sistema secondo una delle precedenti rivendicazioni, in cui detta unità di debug (DE) comprende: a) un primo modulo di ricezione (CP) configurato per: - ricevere dalla rispettiva interfaccia di comunicazione (80) un profilo di traffico, e - trasmettere detto profilo di traffico a detto processore (10), e/o b) un secondo modulo di ricezione (PP, 814) configurato per: - ricevere da detto processore (10) una richiesta di selezione e/o configurazione di un profilo di traffico preimpostato (C), - generare (PP) detto profilo di traffico preimpostato (C), - ricevere dalla rispettiva interfaccia di comunicazione (80) un profilo di traffico, - comparare (814) detto profilo di traffico ricevuto con detto profilo di traffico preimpostato (C), e - inviare a detto processore (10) un segnale identificativo del risultato di detta comparazione di detto profilo di traffico ricevuto con detto profilo di traffico preimpostato (C).
8. 8. Sistema secondo una delle precedenti rivendicazioni, in cui ogni interfaccia di comunicazione (80) comprende: - una memoria (802) di trasmissione e di ricezione, - un’interfaccia (804) per inviare i dati in detta memoria di trasmissione a detta reta d’interconnessione (70) e per salvare i dati ricevuti da detta reta d’interconnessione (70) in detta memoria di ricezione, e - un circuito di controllo (806) configurato per gestire la comunicazione tra il circuito (50) associato all’interfaccia di comunicazione (80) e detta memoria (802) di trasmissione e di ricezione.
9. 9. Sistema secondo la rivendicazione 8, comprendente un circuiti di selezione (810) configurato per selezionare se lo scambio di dati con detta memoria (802) di trasmissione e di ricezione avviene con il circuito (50) associato a detta interfaccia di comunicazione (80) o con detta unità di debug (DE) associata a detta interfaccia di comunicazione (80).
10. 10. Un circuito integrato, comprendente un sistema secondo una delle precedenti rivendicazioni.
11. 11. Procedimento per analizzare il funzionamento di un circuito integrato secondo la rivendicazione 10, comprendente le fasi di: - configurare (1002, 1004; 2002, 2004) una prima unità di debug (DEa) come punto d’inserimento di dati, - configurare (1008, 1010; 2008, 2010) una seconda unità di debug (DEb) come punto di ricezione di dati, e - confrontare (1012; 2012) i dati trasmessi da detta prima unità di debug (DEa) con i dati ricevuti da detta seconda unità di debug (DEb).