Howto Debug un SoC multi-core

Howto Debug un SoC multi-core. Prima di determinare il sistema on chip multi-core appropriato per il debugging è però importante capire le esigenze dell'utente. Questo articolo presenta come fare il debug di un SoC (system-spanning on-chip) multi-core.

Howto Debug un SoC multi-core

Lo sviluppo di sistemi complessi utilizzando hardware molto potente e applicazioni ambiziose trae notevole vantaggio da un supporto per il debugging del tipo system-spanning on-chip (SoC). Siamo certi di parlare a un pubblico di addetti ai lavori, o quasi, quindi non sarebbe necessario, ma aggiungiamo che il debugging è una delle fasi critiche della progettazione di software ed è la fase in cui si ricercano le porzioni di codice affette da errori con il software in esecuzione.

In un SoC complesso, la sola osservazione e controllo di un single-core può diventare insufficiente. Al contrario, l'interazione di multi-core, bus dati, e periferiche varie di cui il SoC fa utilizzo consente a chi effettua il debugging di trovare, tracciare ed eliminare con maggiore efficacia i problemi dei quali il software è affetto o di delineare il comportamento del software per l'ottimizzazione delle prestazioni.

Ciascun core e ciascun bus deve essere osservabile? Sì. Perché riuscire a vedere e ricostruire il program flow di ogni livello di core indipendentemente dal flusso dati nei bus di sistema è uno dei fattori critici per ottimizzare e gestire l'accesso al bus e le performance in altre modalità di funzionamento.

È cruciale per l'analisi del sistema una ricognizione degli eventi che provengono dall'interazione tra tra più livelli di core e i bus di sistema? Sì. Perché le operazioni single-core sono molto spesso insufficienti. A tal fine possono essere utilizzati dei cross trigger che mettono insieme eventi provenienti da sorgenti differenti e li rendono disponibili al sistema.

Un sistema di debug con un apparato di cross triggering complesso è pesante per un solo utente da gestire. L'interfaccia utente di debugging per sistemi hardware di debug complessi deve supportare l'utente nel suo lavoro per trovare errori o rallentamenti delle prestazioni. Dovrebbe, in ultima analisi, nascondere la complessità che proviene dal debugging di un sistema multi-core. Lo scopo ultimo del debugging è trovare le falle nel sistema software, non fronteggiare il sistema hardware complesso di debugging. Quello è solo un mezzo.

Un sistema di debug di questo tipo è stato sviluppato dalla Infineon per il suo microcontroller Tri-core e nel seguito è di questo sistema, chiamato MCDS, che parleremo molto brevemente.

L'OCP-IP Debug Working Group (DWG) si è formato nel 2005. Tre anni dopo, nel gennaio del 2008, il frutto del lavoro di questo team è stato rilasciato sotto forma di protocollo: l'Open Core Protocol Debug Specification 0. Le specifiche pubblicate non mirano a definire o specificare blocchi di debug per ogni core o bus, ma sono piuttosto delle linee-guida dei principi di debug e dei modelli dei segnali che si riferiscono a sistemi di debug basati su sistema OCP che vanno dai più semplici ai più complessi. Sulla base di queste linee-guida, i produttori possono progettare i loro blocchi di debug IP. L'MCDS della Infineon è un valido esempio di una soluzione completa di debugging on-chip per sistemi multi-core.

Il socket del sistema di debug OCP implementa una interfaccia opzionale di debug che è possibile aggiungere ai singoli core e ai blocchi IP che supportano o necessitano di un accesso di debug. L'interfaccia di debug fornisce anche i set di segnali base per il debug. Questi segnali base possono essere distinti in quattro categorie:

  • Controllo di debug: definisce i segnali di reset e di avvio del debug
  • Interfaccia JTAG: definisce i segnali del protoccolo JTAG
  • Interfaccia del debugger: definisce un set di interfacce di debugging per settare il controllo operativo del livello di debug e gli strumenti di debug
  • Interfaccia di Cross-trigger: definisce i segnali per la distribuzione degli eventi di debug e il livello di controllo di sistema per il sistema SoC multi-core

Oltre queste quattro categorie fondamentali, sono molti altri i tipi di segnale che possono essere implementati per specifici core IP. Inoltre, funzionalità specifiche progettate all'interno di un ben determinato obiettivo possono supportare caratteristiche particolari in termini di isole di potenza, sotto-sistemi o fornire feature avanzate di debug da usare nell'analisi basata sui blocchi IP, per il monitoraggio delle performance, eccetera.

Per determinare le caratteristiche di controllo di un sistema di debug multi-core è richiesto che il socket OCP definisca una interfaccia socket di cross-triggering che può essere implementata da tutti i blocchi OCP appartenenti all'ambiente di debug di un SoC multi-core. La distribuzione dei cross-trigger tra tutti i blocchi di debug è gestita da un blocco dedicato di cross-trigger. Le condizioni sono monitorate e poi valutate per generare trigger in real time implementati in un cross-trigger manager all'interno del blocco. Questi trigger possono essere usati per controllare eventi come la configurazione, break-point e raccolta di tracce e specifici punti nel sistema. Una implementazione più complessa può essere programmata agendo su specifici valori o sequenze del trigger come le regioni di indirizzamento e i tipi di lettura dati o i cicli di scrittura.

Le caratteristiche del sistema di debug OCP non definiscono interfacce esterne di debug tra un ambiente OCP on-chip e componenti esterni (sonde e debugger per esempio). Bensì, queste sono fornite da operatori terzi come JTAG, NEXUS o MIPI.

Leggi anche: Howto Debug un SoC multi-core 2/2

Repost del 21 novembre 2008

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend