Debug FPGA in circuito Microsemi

Informazioni sul prodotto

Specifiche

• Tipo di dispositivo: Microsemi SmartFusion2 SoC FPGA
• Data di rilascio: maggio 2014
• Capacità di debug: debug FPGA in-circuit, analizzatore logico incorporato
• Frequenza massima di acquisizione dati: fino a 100 MHz

Astratto
Gli FPGA sono potenti elementi di progettazione nei sistemi embedded con molti vantaggi di progettazionetages, ma questi dispositivi possono avere progetti complessi con problemi di progettazione complessi che devono essere sottoposti a debug. Individuare problemi di progettazione come errori di definizione, problemi di interazione del sistema ed errori di temporizzazione del sistema può essere una sfida. L'inclusione di funzionalità di debug in-circuit in un FPGA può migliorare notevolmente il debug hardware ed evitare innumerevoli ore di frustrazione. Questo documento descrive diversi approcci al debug in-circuit per FPGA, identifica i compromessi chiave e, attraverso un exampLa progettazione, mirata per un dispositivo FPGA Microsemi SmartFusion®2 SoC, mostrerà come le nuove funzionalità possono essere utilizzate per velocizzare il debug e il test.

Introduzione

Gli FPGA sono elementi di progettazione pervasivi e potenti e ora si trovano praticamente in ogni sistema embedded. Con l'aumento della capacità, l'inclusione di complessi blocchi funzionali on-chip e interfacce seriali avanzate, questi dispositivi possono anche avere complessi problemi di progettazione che devono essere sottoposti a debug. Individuare problemi come errori di definizione funzionale (a livello di FPGA o di sistema), problemi di interazione funzionale del sistema, problemi di temporizzazione del sistema e problemi di fedeltà del segnale tra IC (come rumore, diafonia o riflessioni) diventano tutti molto più complessi quando si utilizzano FPGA avanzati. La simulazione è sicuramente un grande aiuto nell'identificazione di molti problemi di progettazione, ma molte interazioni del mondo reale non si presenteranno finché il progetto non sarà implementato nell'hardware. Sono state sviluppate diverse tecniche per il debug di complessi problemi di progettazione per semplificare il processo. Una comprensione attenta di ciascuna di queste tecniche chiave, inclusi i vari avantages e svantaggiotages, è utile quando si considera quale tecnica o combinazione di tecniche sia adatta per un particolare progetto.
un exampIl design FPGA, mirato per un dispositivo FPGA Microsemi SmartFusion2 SoC, può essere utilizzato per dimostrare alcuni dei vantaggitages e svantaggiotagdi queste tecniche standard, nonché le più recenti capacità di debug in-circuit. Questo esempio illustrativoampmostreremo come queste diverse tecniche possono essere utilizzate per accelerare l'identificazione e l'eliminazione dei problemi hardware durante il debug hardware.

Perché il debug FPGA è un aspetto fondamentale della progettazione e dello sviluppo dei sistemi?
Gli FPGA hanno due modelli di utilizzo principali che li differenziano dagli altri elementi di progettazione. Gli FPGA possono essere utilizzati nel prodotto di produzione o come veicolo di sviluppo per provare o prototipare un concetto di progettazione di produzione. Quando vengono utilizzati come veicolo di produzione, gli FPGA possono essere un obiettivo molto più flessibile rispetto ai veicoli di produzione basati su ASIC o CPU. Ciò è particolarmente importante per un nuovo design, uno che non è stato ancora implementato nell'hardware. I design con diverse opzioni architettoniche possono essere facilmente creati e testati in modo da identificare il design ottimale. Gli FPGA con processori on-chip (FPGA SoC) consentono anche di bilanciare l'elaborazione basata su CPU con funzioni di accelerazione basate su FPGA assistite da hardware. Questi vantaggitagPossono ridurre drasticamente i tempi necessari per la progettazione, la convalida, i test e l'analisi dei guasti nello sviluppo di nuovi prodotti.
Quando viene utilizzato per la prototipazione di un progetto, magari per un ASIC di produzione, la flessibilità FPGA è un vantaggio fondamentale. Una piattaforma hardware effettiva, anche se non funziona a piena velocità, rende molto più semplice ottenere metriche dettagliate sulle prestazioni del sistema, dati di analisi della produttività e risultati di proof-of-concept dell'architettura. Il supporto FPGA per implementazioni rafforzate di bus standard del settore (come PCIe®, Gigabit Ethernet, XAUI, USB, CAN e altri) semplifica i test associati a queste interfacce. Le più recenti famiglie di FPGA con processori ARM on-chip (FPGA SoC) semplificano la prototipazione di implementazioni con processori embedded. Il codice del processore sviluppato in precedenza può essere trasferito al prototipo e il nuovo codice creato parallelamente allo sforzo di progettazione hardware.

Questa combinazione di un processore standard con bus di interfaccia standard consente di sfruttare il vasto ecosistema di librerie di codice disponibili, driver, API funzionali, sistemi operativi in ​​tempo reale e persino sistemi operativi completi per creare molto più rapidamente un prototipo funzionante. Inoltre, una volta consolidato il progetto, il prototipo FPGA può essere utilizzato per acquisire set di test di simulazione estesi (sia per stimolo che per risposta) che riflettono i dati effettivi del sistema. Questi set di dati possono essere preziosi nella creazione delle simulazioni finali per un ASIC o un'altra implementazione di produzione. L'advantagL'utilizzo di un FPGA come prototipo di progettazione può ridurre drasticamente i tempi di progettazione, convalida, test e analisi dei guasti per l'implementazione del prodotto finale.
In entrambi questi modelli di utilizzo comuni dell'FPGA, la flessibilità dell'FPGA come obiettivo di progettazione è un vantaggio fondamentale.tage. Ciò significa che molte modifiche e iterazioni di progettazione sarebbero la norma e quindi la capacità di eseguire rapidamente il debug degli errori di progettazione sarebbe fondamentale per abilitare quante più opzioni di progettazione possibili. Senza una capacità di debug efficiente, gran parte del vantaggiotagLa flessibilità di progettazione FPGA sarà ridotta dal tempo di debug aggiuntivo richiesto. Fortunatamente, gli FPGA possono anche fornire funzionalità hardware aggiuntive che semplificano notevolmente il debug in tempo reale. Prima di esaminare queste capacità, diamo un'occhiata ai tipi più comuni di problemi che un progetto FPGA potrebbe dover affrontare, in modo da avere il background appropriato per valutare l'efficienza e i compromessi associati di vari strumenti di debug.

Problemi comuni durante il debug di progetti FPGA

Insieme alle capacità espanse che i moderni FPGA portano con sé, la maggiore complessità associata rende più difficile creare progetti privi di errori. Infatti, è stato stimato che il debug può occupare oltre il 50% del ciclo di progettazione del sistema embedded. Con le pressioni del time-to-market che continuano a comprimere il ciclo di sviluppo, il debug hardware del sistema iniziale viene relegato a un ripensamento, troppo spesso dando per scontato che la verifica (di per sé una grande percentualetage del programma di sviluppo), catturerà tutti i bug prima dell'avvio iniziale del sistema. Diamo un'occhiata solo ad alcuni tipi comuni di problemi di sistema per comprendere meglio le sfide che un tipico progetto dovrà affrontare durante l'avvio iniziale del sistema.

Gli errori di definizione funzionale possono essere doppiamente difficili da trovare poiché il progettista ha frainteso un requisito particolare, quindi l'errore può essere trascurato anche quando si esaminano attentamente i dettagli del progetto. Un exampun errore comune di definizione funzionale sarebbe quando una transizione di macchina a stati non finisce nello stato corretto. Gli errori possono anche presentarsi nelle interfacce di sistema come un problema di interazione. Latenza dell'interfaccia, ad esempioample, potrebbe essere specificato in modo errato, causando una condizione imprevista di buffer overflow o underflow.
I problemi di temporizzazione a livello di sistema sono un'altra fonte molto comune di errori di progettazione. Gli eventi asincroni, in particolare, sono una fonte comune di errori quando la sincronizzazione o gli effetti di incrocio del dominio di temporizzazione non vengono attentamente considerati. Quando si opera a velocità elevata, questi tipi di errori possono essere molto problematici e possono presentarsi molto raramente, forse solo quando si manifestano specifici modelli di dati. Molte violazioni di temporizzazione comuni rientrano in questa categoria e sono solitamente molto difficili, se non impossibili da simulare.

Le violazioni di temporizzazione possono anche essere il risultato di una bassa fedeltà del segnale tra circuiti integrati, in particolare in sistemi con più linee di alimentazione per ogni circuito. Una bassa fedeltà del segnale può causare rumore del segnale, diafonia, riflessioni, carico eccessivo e problemi di interferenza elettromagnetica (EMI) che spesso si presentano come violazioni di temporizzazione. Problemi di alimentazione, come transitori (in particolare durante l'avvio o l'arresto del sistema), variazioni di carico e stress di dissipazione di potenza elevata possono anche causare errori misteriosi, spesso non facilmente riconducibili a una fonte di alimentazione. Anche quando il design è completamente corretto, i problemi di fabbricazione della scheda possono causare errori. Giunti di saldatura difettosi e connettori collegati in modo improprio, ad esempioample, può essere la fonte di errori e può anche dipendere dalla temperatura o dalla posizione della scheda. L'uso di tecniche di packaging FPGA avanzate può rendere difficile sondare i segnali sulla scheda a circuito stampato, quindi anche solo ottenere l'accesso a un segnale desiderato può spesso essere problematico. Spesso molti problemi di progettazione non creano un errore immediato e devono propagarsi attraverso la progettazione fino a quando l'errore non si manifesta effettivamente. Risalire all'errore iniziale fino alla causa principale può spesso essere un compito frustrante, difficile e che richiede molto tempo.

Per esempioample, un singolo bit sbagliato in una tabella di traduzione potrebbe non causare un errore fino a molti cicli dopo. Alcuni degli strumenti di cui parleremo più avanti in questo documento, che utilizzano hardware di debug in-circuit dedicato, sono specificamente mirati a rendere queste "cacce ai bug" più rapide e facili. Prima di entrare nei dettagli di questi strumenti, diamo un'occhiata a una simulazione di una tecnica di debug basata su software popolare per comprendere meglio i vantaggitages e svantaggiotagdi utilizzo della simulazione per il debug.

Utilizzo della simulazione per il debug
In genere, in una simulazione di progettazione, tutti i componenti reali all'interno e all'esterno della progettazione vengono modellati matematicamente come processi software che vengono eseguiti in sequenza su una CPU standard. L'applicazione di un'ampia gamma di stimoli alla progettazione e il controllo dell'output previsto rispetto all'output della progettazione simulata rappresentano un modo semplice per individuare gli errori di progettazione più evidenti. Una finestra che mostra una tipica esecuzione di simulazione è riportata nella Figura 1 di seguito. Il chiaro vantaggiotage della simulazione rispetto al debug basato su hardware, è che la simulazione può essere eseguita nel software, senza bisogno di progettazione e testbench basati su hardware effettivi. La simulazione può rilevare rapidamente molti errori di progettazione, in particolare quelli associati a specifiche errate, incomprensione dei requisiti di interfaccia, errori di funzione e molti altri tipi di errori "grossolani" che vengono prontamente rilevati tramite semplici vettori di stimolo.

La simulazione è particolarmente efficace quando il progettista ha a disposizione ampie combinazioni di stimoli e gli output risultanti sono ben noti. In questi casi, la simulazione può effettuare un test quasi esaustivo di un progetto. Sfortunatamente, la maggior parte dei progetti non ha facile accesso a suite di test estese e il processo di creazione può richiedere molto tempo. Creare una suite di test che copra il 100% del progetto è praticamente impossibile per grandi progetti basati su FPGA e devono essere utilizzate scorciatoie per provare a coprire gli elementi chiave del progetto. Un'altra difficoltà con la simulazione è che non è un'implementazione del "mondo reale" e non può catturare eventi asincroni, interazioni di sistema a velocità elevata o violazioni di temporizzazione. Infine, il processo di simulazione può essere molto lento e se sono necessarie molte iterazioni, la simulazione diventa rapidamente la parte più dispendiosa in termini di tempo e spesso la più costosa del processo di sviluppo.

Come alternativa (o forse meglio, come aggiunta alla simulazione), i progettisti di FPGA hanno scoperto che potevano aggiungere hardware di debug nel progetto FPGA per osservare e controllare i segnali chiave all'interno del dispositivo. Queste tecniche si sono sviluppate originariamente come approcci ad hoc, ma si sono gradualmente sviluppate in una strategia di debug hardware standard. Questo utilizzo di capacità di debug in-circuit offre notevoli vantaggitagper progetti basati su FPGA e la prossima sezione esplorerà le tre strategie più comuni e i loro vari vantaggitages e svantaggiotages.

Approcci comuni di debug in-circuit per FPGA
Le tecniche più comuni per implementare le capacità di debug in-circuit negli FPGA utilizzano un analizzatore logico incorporato, un'apparecchiatura di test esterna o un hardware di sonda di segnale dedicato incorporato nel fabric FPGA. L'analizzatore logico incorporato è in genere implementato utilizzando il fabric FPGA ed è inserito nel design. Il JTAG porta viene utilizzata per accedere all'analizzatore e i dati acquisiti possono essere visualizzati su un PC. Quando si utilizza un'apparecchiatura di test esterna, il design FPGA in fase di test viene modificato in modo che i segnali FPGA interni selezionati vengano instradati verso pin di uscita. Questi pin possono quindi essere osservati tramite l'apparecchiatura di test esterna. Quando si utilizza un hardware di sonda di segnale dedicato, è possibile leggere in tempo reale un'ampia selezione di segnali interni. Alcune implementazioni di sonda possono persino essere utilizzate per scrivere in posizioni di registro o memoria, migliorando ulteriormente le capacità di debug. Diamo un'occhiata più in dettaglio ai vantaggitages e svantaggiotagdi ciascuna di queste tecniche e poi guarda un esempioampla progettazione per vedere come questi diversi approcci possono influire sul tempo complessivo di debug.

Analizzatore logico incorporato per debug FPGA in-circuit
Il concetto di analizzatore logico incorporato è stato un risultato diretto delle capacità di debugging in-circuit ad hoc implementate dai progettisti quando sono stati utilizzati per la prima volta gli FPGA. Gli analizzatori logici incorporati hanno aggiunto nuove capacità ed eliminato la necessità per il progettista di sviluppare il proprio analizzatore. La maggior parte degli FPGA offre queste capacità e terze parti offrono analizzatori standard (Identify®, di Synopsys, è un esempio popolare).ample) che può facilmente interfacciarsi con strumenti di livello superiore per migliorare ulteriormente la produttività.

La funzionalità dell'analizzatore logico è inserita nel design, utilizzando la struttura FPGA e i blocchi di memoria incorporati come buffer di traccia, come illustrato nella Figura 2. Vengono inoltre create risorse di attivazione in modo che le interazioni complesse dei segnali possano essere facilmente selezionate e catturate. L'accesso all'analizzatore per il controllo e il trasferimento dei dati avviene in genere tramite lo standard JTAG porta per semplificare i requisiti dell'interfaccia. I dati acquisiti possono essere visualizzati su un PC utilizzando comuni viewsoftware di ing e in genere rispecchia un'uscita di forma d'onda del simulatore logico viewstile di ing.

Il vantaggiotagI vantaggi di questo approccio sono che non vengono utilizzati pin I/O FPGA aggiuntivi, solo i pin J standardTAG segnali. I core IP dell'analizzatore logico incorporato sono solitamente relativamente poco costosi e in alcuni casi possono essere un'opzione per la sintesi FPGA esistente o per gli strumenti di simulazione. In alcuni casi, l'analizzatore logico incorporato può anche fornire output aggiuntivi su I/O inutilizzati, se è più conveniente. Uno degli svantaggitagUn altro problema di questo approccio è che sono necessarie grandi quantità di risorse FPGA. In particolare, se vengono utilizzati buffer di traccia, ciò ridurrà il numero di memorie a blocchi disponibili. Se è necessario un buffer ampio, ciò rappresenterà anche un compromesso con la profondità di memoria (poiché l'uso di una memoria più ampia comporta una profondità di memoria inferiore), un grande svantaggiotage quando si utilizzano dispositivi più piccoli. Forse il più grande svantaggio di questa tecnica è che ogni volta che si apporta una modifica al posizionamento della sonda, è necessario ricompilare e riprogrammare il progetto. Quando si utilizza un dispositivo di grandi dimensioni, questo processo può richiedere una notevole quantità di tempo. A causa del modo in cui le sonde del segnale sono posizionate nel progetto, può essere difficile correlare le relazioni di temporizzazione del segnale. Inoltre, i ritardi tra le sonde del segnale non sono coerenti e quindi le relazioni di temporizzazione sono difficili da confrontare. Questa è una difficoltà particolare quando si confrontano segnali asincroni o segnali provenienti da diversi domini temporali.

Debug FPGA in circuito – Apparecchiature di prova esterne
L'uso del codice di debug in-circuit insieme a apparecchiature di test esterne è stato uno sviluppo naturale quando un analizzatore logico esterno era già disponibile per i test di sistema. Creando un semplice codice di debug per identificare e selezionare segnali di test interni e applicarli agli I/O FPGA, come mostrato nella Figura 3, è stato possibile sfruttare le capacità avanzate degli analizzatori (come grandi buffer di traccia, sequenze di trigger complesse e più viewopzioni di attivazione) per creare ambienti di debug semplici ma potenti. Funzionalità in-circuit più complesse per opzioni di attivazione avanzate possono ridurre al minimo il numero di output necessari. Ad esempioampAd esempio, selezionare indirizzi specifici su un bus ampio potrebbe essere proibitivo se fossero necessari pin esterni.
L'utilizzo della logica FPGA interna riduce drasticamente i requisiti di I/O e può persino cercare specifici modelli di indirizzo (forse una sequenza di chiamata e ritorno) per il debug di problemi più complessi. Se è disponibile un'interfaccia utente comune, questo può semplificare la curva di apprendimento e migliorare la produttività.

Il vantaggiotages di questo approccio è che sfrutta il costo dell'attrezzatura di prova esterna e quindi non vi è alcun costo aggiuntivo per gli strumenti. Alcuni core IP del circuito di debug sono disponibili presso i produttori di apparecchiature o i produttori di FPGA e possono essere molto economici o addirittura gratuiti. La quantità di risorse FPGA richieste per implementare la logica di selezione del segnale è molto ridotta e poiché la funzione di traccia viene eseguita utilizzando l'analizzatore logico esterno, non sono necessarie memorie a blocchi. Poiché la logica di selezione è poco costosa, è possibile supportare anche un gran numero di canali con trigger ampio. L'analizzatore logico può funzionare sia in modalità Timing che in modalità State, il che aiuta a isolare alcuni problemi di timing.
Lo svantaggiotagGli svantaggi di questo approccio possono includere la necessità di acquistare un analizzatore logico, se non ne è già stato assegnato uno al progetto. Questo svantaggiotage potrebbe essere sufficiente a scoraggiare questo approccio in molti casi. Si noti tuttavia che stanno diventando disponibili alcune opzioni di analizzatori logici a basso costo che utilizzano il PC o un tablet per la visualizzazione, rendendo questa opzione molto più conveniente per semplici requisiti di debug.
Un altro svantaggio può essere il numero di pin FPGA consumatitage se devono essere osservati bus ampi, è necessaria una pianificazione significativa per il layout della scheda e l'aggiunta di connettori di debug. Questo requisito è il più delle volte difficile da prevedere all'inizio della fase di progettazione e un'altra complessità indesiderata. Similmente all'approccio dell'analizzatore logico incorporato, la strategia di test esterna richiede la ricompilazione e la riprogrammazione di un progetto, quando è necessario ogni nuovo esperimento.

Lo svantaggio comunetages di queste due tecniche, l'uso di risorse on-chip (che possono anche avere un impatto sulle prestazioni di temporizzazione del progetto e creare requisiti di debug aggiuntivi), la necessità di ricompilare e riprogrammare il progetto (che può aggiungere ore o persino giorni alla pianificazione del debug), la pianificazione anticipata richiesta per identificare probabili scenari di test e l'uso di risorse I/O aggiuntive del chip hanno creato la necessità di un approccio privo di questi inconvenienti. Una risposta è stata l'aggiunta di una logica di debug dedicata nel fabric FPGA su alcuni dispositivi. Il risultato è stato il debug in-circuit tramite sonde hardware.

Debug FPGA in circuito – Sonde hardware
L'uso di sonde hardware semplifica notevolmente le tecniche di debug in-circuit per FPGA. Questa tecnica implementata come funzionalità Live Probe su dispositivi SmartFusion2®SoC FPGA e IGLOO®2 FPGA, aggiunge linee di sonda dedicate al fabric FPGA per osservare l'output di qualsiasi bit di registro dell'elemento logico. Come mostrato nel diagramma a blocchi in Figura 4, le sonde hardware sono disponibili in due canali di sonda A e B.

Le uscite di registro selezionate (punti di sonda), come quella originata nella parte inferiore della figura, vengono instradate sopra i due canali di sonda e, se selezionate, possono essere applicate al canale A o B. Questi segnali di canale in tempo reale possono quindi essere inviati ai pin dedicati Probe A e Probe B sul dispositivo. I segnali Probe A e Probe B possono anche essere instradati internamente a un analizzatore logico incorporato.

Si noti che le caratteristiche di temporizzazione dei pin di sonda sono regolari e hanno una deviazione trascurabile da un punto di sonda all'altro, rendendo molto più semplice confrontare le caratteristiche di temporizzazione dei segnali in tempo reale. I dati possono essere catturati fino a 100 MHz, rendendoli adatti alla maggior parte dei progetti target.
Forse la cosa più importante sono le posizioni dei punti di sonda, poiché non sono selezionate come parte del progetto implementato (sono selezionate tramite hardware dedicato mentre il progetto è in esecuzione sull'FPGA), possono essere rapidamente modificate semplicemente inviando i dati di selezione al dispositivo. Non è necessaria alcuna ricompilazione e riprogrammazione del progetto.
Per semplificare ulteriormente l'uso della funzionalità Live Probe, lo strumento software di debug associato ha accesso a tutte le posizioni del segnale della sonda tramite un debug generato automaticamente fileCome mostrato nella Figura 5, il nome del segnale può essere selezionato dall'elenco dei segnali e applicato al canale desiderato. Ciò può essere fatto anche mentre il progetto è in esecuzione, in modo che l'attività di sondaggio all'interno del progetto sia fluida e molto efficiente.

In molti casi, la funzionalità di sonda hardware, come Live Probe, può essere utilizzata insieme all'analizzatore logico incorporato descritto in precedenza e alle tecniche di test esterne.

Come mostrato nella Figura 6, la capacità di Live Probe di selezionare i segnali "al volo" consente di modificare rapidamente e facilmente i segnali sotto osservazione senza dover ricompilare il progetto. Un analizzatore logico o un oscilloscopio esterno può facilmente osservare i segnali sondati, come illustrato nella parte in alto a destra della figura sui pin di uscita della sonda dedicati. In alternativa (o forse anche in aggiunta a) l'analizzatore logico interno (il blocco ILA Identify, mostrato nella figura) può essere utilizzato per osservare i pin della sonda. I segnali della sonda possono essere catturati dall'ILA e osservati sulla finestra della forma d'onda. Le posizioni della sonda possono essere modificate senza dover ricompilare il progetto di destinazione.
Si noti che le funzionalità aggiuntive di attivazione e tracciamento possono essere utilizzate per migliorare la funzionalità della sonda, facilitando l'individuazione anche di problemi di progettazione complessi.

Sono disponibili anche funzionalità di debug hardware aggiuntive sui dispositivi SmartFusion2 SoC FPGA e IGLOO2 FPGA. Una di queste funzionalità, denominata Active Probe, può leggere o scrivere in modo dinamico e asincrono su qualsiasi bit di registro di elemento logico. Un valore scritto persiste per un singolo ciclo di clock, quindi il normale funzionamento può continuare, rendendolo uno strumento di debug molto prezioso. Active Probe è di particolare interesse se si desidera un'osservazione rapida di un segnale interno (forse semplicemente per verificare che sia attivo o nello stato desiderato, come un segnale di reset), o se è necessario testare rapidamente una funzione logica scrivendo su un punto di sonda
(forse per avviare una transizione della macchina a stati impostando rapidamente un valore di input per isolare un problema di flusso di controllo).

Un'altra capacità di debug fornita da Microsemi è Memory Debug. Questa funzionalità consente al progettista di leggere o scrivere in modo dinamico e asincrono su un blocco SRAM FPGA fabric selezionato. Come illustrato nello screenshot del Debug Tool (Figura 7), quando si seleziona la scheda Memory Blocks, l'utente può selezionare la memoria desiderata da leggere, eseguire un'acquisizione snapshot della memoria, modificare i valori della memoria e quindi riscrivere i valori sul dispositivo. Ciò può essere particolarmente utile per controllare o impostare buffer di dati utilizzati nelle porte di comunicazione per scratch-pad orientato al calcolo o persino per codice eseguito da una CPU incorporata. Il debug di errori complessi dipendenti dai dati è significativamente più rapido e semplice quando le memorie possono essere osservate e controllate così rapidamente.

Una volta eseguito il debug di un progetto, potrebbe essere opportuno disattivare le capacità di debug dell'hardware per proteggere le informazioni sensibili. Un aggressore potrebbe utilizzare queste stesse capacità per leggere informazioni critiche o modificare le impostazioni di sistema che potrebbero consentire un facile accesso a parti sensibili del sistema. Microsemi ha aggiunto funzionalità per consentire al progettista di proteggere il dispositivo dopo il completamento del debug. Ad esempioample, l'accesso a Live Probe e Active Probe può essere bloccato per disabilitare completamente la funzione come possibile mezzo di attacco (elimina persino la possibilità che l'attività della sonda crei qualsiasi schema nella corrente di alimentazione che potrebbe essere utilizzato per provare a osservare indirettamente i dati della sonda). In alternativa, l'accesso a porzioni selezionate del progetto può essere bloccato per impedire l'accesso solo a quelle sezioni. Ciò può essere comodo se solo una porzione del progetto deve essere protetta, rendendo il resto del progetto ancora accessibile per test sul campo o analisi degli errori.

Tabella di confronto del debug in-circuit
Ora che un resoconto dettagliatoview delle tre principali tecniche di debug hardware in-circuit sono state descritte, è stato creato un grafico riassuntivo, come mostrato nella Figura 8, che descrive in dettaglio i vari vantaggitages e svantaggiotages di ogni metodo. Ricordando che alcune tecniche possono essere utilizzate insieme (Live Probe e Internal Logic Analyzer (ILA), come Synopsys Identify, ad esempioample), possiamo vedere i punti di forza e di debolezza principali di ogni tecnica. La raccolta di funzionalità di debug hardware in-circuit (Live Probe, Active Probe e Memory Debug, collettivamente denominate SmartDebug), sono più deboli rispetto alle altre tecniche quando si tratta del numero totale di sonde disponibili (un cerchio rosso) e sono più deboli delle migliori (cerchio giallo) quando si considera la velocità di cattura (le apparecchiature di test esterne possono essere più veloci).
Le tecniche basate su ILA, come Synopsys Identify, sono più deboli se confrontate con altre tecniche e quando vengono considerati i requisiti di risorse FPGA. Le tecniche basate su apparecchiature di test esterne sono più deboli per una serie di considerazioni, con costi, impatto sui tempi di progettazione e overhead di movimento della sonda (dovuto alla necessità di ricompilare la progettazione) i più onerosi. Forse la soluzione ottimale è una combinazione di SmartDebug e una delle altre tecniche, in modo che la debolezza del numero di canali di SmartDebug possa essere mitigata e lo svantaggio del movimento del punto di sondataganche le altre tecniche sono state ridotte.

Classificazioni del segnale
Si può fare una distinzione utile tra alcuni dei tipi più comuni di segnali e questo può aiutare quando si pianifica un approccio di debugging. Ad esempioample, i segnali che non cambiano se non durante l'avvio del sistema, come il reset del sistema, il reset del blocco o i registri di inizializzazione possono essere classificati come segnali statici. Questi tipi di segnali sono più efficacemente accessibili tramite una struttura che può facilmente osservare e controllare il segnale, senza bisogno di un lungo ciclo di ricompilazione. Active Probe è un'eccellente struttura per il debug dei segnali statici. Allo stesso modo, i segnali che cambiano più frequentemente ma sono ancora statici per la maggior parte del tempo, possono essere classificati come pseudo-statici e sono anche più efficacemente debuggati utilizzando Active Probe. I segnali che cambiano frequentemente, come i segnali di clock, possono essere classificati come dinamici e non sono facilmente accessibili tramite Active Probe. Live Probe è una scelta migliore per osservare questi segnali.

Caso d'uso di debug semplice

Ora che abbiamo una migliore comprensione delle varie opzioni di debug in-circuit, diamo un'occhiata a un semplice esempio di progettazioneample per vedere come funzionano queste tecniche. La Figura 9 mostra un semplice design FPGA in un dispositivo FPGA SmartFusion2 SoC. Il sottosistema del microcontrollore (MSS) viene ripristinato dal blocco CoreSF2Reset Soft IP. Gli input di questo blocco sono Power On Reset, User Fabric Reset e External Reset. Gli output sono un reset su User Fabric, un reset MSS e un reset M3. I sintomi dell'errore sono che non c'è attività sugli I/O anche se il dispositivo esce correttamente dallo stato POR. Le tre diverse opzioni per il debug di questo errore sono illustrate anche nella figura: la casella blu (etichettata ETE) è per il metodo External Test Equipment; la casella verde (etichettata ILA) è per il metodo Internal Logic Analyzer; e la casella arancione (etichettata AP) è per il metodo Active Probe. Supporremo che le potenziali cause principali dell'errore siano input di reset affermati in modo improprio al blocco CoreSF2Reset Soft IP.

Diamo ora un'occhiata al processo di debug per tre dei metodi in-circuit descritti in precedenza.

Attrezzatura di prova esterna
Utilizzando questo metodo, si presume che l'attrezzatura di prova sia disponibile e non utilizzata da un progetto con priorità più alta. Inoltre, è importante aver pianificato in anticipo in modo che alcuni I/O FPGA siano disponibili e possano essere facilmente collegati all'attrezzatura di prova. Avere un header sul PCB, ad esempioample, sarebbe molto utile e ridurrebbe al minimo il tempo impiegato nel tentativo di identificare e connettersi a un "probabile sospetto" o al potenziale cortocircuito dei pin durante il sondaggio. Il progetto dovrà essere ricompilato per selezionare i segnali che vogliamo analizzare. Speriamo di non dover "sbucciare la cipolla" e dover selezionare segnali aggiuntivi per ulteriori indagini, poiché spesso la nostra indagine iniziale si traduce solo in più domande. In ogni caso, il processo di ricompilazione e riprogrammazione può richiedere una notevole quantità di tempo e, se si traduce in violazioni di temporizzazione, è necessaria una riprogettazione (sappiamo tutti quanto possa essere frustrante cercare di risolvere i problemi di chiusura di temporizzazione, in particolare quando si apportano modifiche al progetto per trovare un bug di progettazione: l'intero processo può richiedere da minuti a ore)! È anche importante ricordare che se il progetto non ha I/O utente liberi, questo metodo non può essere implementato. Inoltre, questo metodo è strutturalmente intrusivo per il progetto e i bug relativi alla temporizzazione potrebbero scomparire o riapparire tra le iterazioni.

Analizzatore logico interno
Utilizzando questo metodo, l'ILA deve essere inserito nel design utilizzando risorse fabric, e quindi deve essere ricompilato. Si noti che se l'ILA è già stato istanziato, i segnali che vogliamo analizzare potrebbero non essere stati strumentati, il che richiederebbe anche una ricompilazione. Questo processo rischia di modificare il design originale e violare i vincoli di temporizzazione. Se i vincoli di temporizzazione vengono rispettati, il design deve essere riprogrammato e reinizializzato. L'intero processo può richiedere diversi minuti o persino ore se i tempi di ricompilazione sono lunghi e sono necessari più passaggi. Questo approccio è strutturalmente intrusivo e può causare problemi simili a quelli descritti quando si utilizza il metodo sopra.

Sonda attiva
Utilizzando questo metodo, l'Active Probe può essere indirizzato alla sorgente dei vari segnali di reset, tutti provenienti da output di registro (come è comune in qualsiasi buona pratica di progettazione digitale). I segnali vengono selezionati uno alla volta, da un menu Active Probe mostrato nella Figura 10 di seguito. I valori del segnale selezionati possono essere letti e visualizzati nella finestra dati Active Probe. Eventuali asserzioni errate vengono facilmente identificate. Questo test può essere eseguito immediatamente senza la necessità di ricompilare e riprogrammare il dispositivo e non è intrusivo a livello strutturale o procedurale. L'intero processo richiede solo pochi secondi. Questo metodo può anche creare controllabilità (modifica dei valori in modo asincrono) che gli altri due metodi non consentiranno. In questo particolare esempioampAd esempio, il segnale di reset generato da un registro può essere facilmente analizzato e scoperto che è mantenuto in stato attivo.

L'attivazione momentanea del segnale di reset può essere ottenuta manipolando in modo asincrono il registro che genera i segnali di riposo.

Caso di utilizzo di debug più complesso
Il progetto sopra riportato era molto semplice ed è utile come introduzione all'utilizzo delle tecniche di progettazione descritte, ma un esempio più complessoamppotrebbe essere ancora più esemplificativo. Molte volte il segnale di interesse non è un segnale statico come nel nostro semplice esempioample ma è dinamico. Un segnale dinamico comune è un clock intermedio, forse utilizzato per cronometrare un handshake per un'interfaccia seriale. La Figura 11 mostra un tale progetto con il core Soft IP dell'utente, in questo caso un'interfaccia seriale personalizzata connessa al bus APB di sistema. I sintomi di errore sono che non c'è attività sull'interfaccia seriale personalizzata dell'utente e che quando un master del bus APB emette una transazione per accedere all'interfaccia seriale entra in una condizione di eccezione che indica un handshake non corretto. Queste condizioni sembrano escludere una causa statica, come un segnale di reset non corretto, poiché la macchina a stati della transazione sembra non funzionare alla velocità prevista e quindi causa l'eccezione. Si pensa che la causa principale sia il generatore di frequenza di clock all'interno del core IP dell'utente.

Se non funziona alla frequenza corretta, si verificheranno gli errori descritti.

In questa situazione è probabilmente una strategia migliore sostituire l'approccio Active Probe con Live Probe. Ciò è illustrato nella figura soprastante dalla casella LP di colore arancione, utilizzando JTAG segnale per la selezione della sorgente della sonda.

Attrezzatura di prova esterna
Per questo caso, la metodologia è molto simile al semplice esempio precedentemente descrittoample. Il segnale di clock utente viene portato al punto di test (si spera su un header) ed è necessaria una ricompilazione che richiede molto tempo. Potrebbe anche essere utile portare fuori un segnale di riferimento, forse un clock di sistema che viene utilizzato per cronometrare l'IP degli utenti come segnale di confronto. Saremo nuovamente sottoposti alla necessità di ricompilare e riprogrammare, quindi l'intero processo potrebbe richiedere una notevole quantità di tempo.

Analizzatore logico interno
Questo caso è molto simile al semplice esempioample. L'ILA deve essere inserito, o il segnale desiderato definito, e un ciclo di ricompilazione e riprogrammazione eseguito. Tutti i problemi descritti in precedenza comportano comunque un tempo di ciclo di debug significativo. C'è tuttavia una complessità aggiuntiva. Il clock che guida l'ILA deve essere sincrono, e idealmente molto più veloce rispetto al clock da osservare dal core Soft IP dell'utente. Se questi clock sono asincroni, o non hanno le relazioni di temporizzazione corrette, l'acquisizione dei dati sarà imprevedibile e una possibile fonte di confusione per il processo di debug.
Si noti che se il clock Soft IP dell'utente non viene generato sul chip (forse viene recuperato dall'interfaccia seriale), il progettista potrebbe dover aggiungere un modulo clock per generare un clock ILA più veloce utilizzando risorse aggiuntive e creando eventualmente una violazione di temporizzazione.

Sonda in tempo reale
Utilizzando questo metodo, Live Probe può essere rapidamente indirizzato alla sorgente dell'orologio utente e a qualsiasi altra sorgente di orologio da un registro per rintracciare la causa principale dell'errore. Live Probe mostrerà le uscite del segnale selezionate in tempo reale e qualsiasi relazione temporale tra i segnali sarà quindi molto più facile da determinare. L'intero processo richiede solo pochi secondi.

Altre funzionalità di debug per interfacce seriali
È anche importante sottolineare che ci sono molte funzionalità di debug aggiuntive nei dispositivi SmartFusion2 SoC FPGA e IGLOO2 FPGA che possono essere utilizzate su interfacce seriali, come quella nell'esempio precedenteampil design in cui gli errori sono ancora più complicati. SERDES Debug, ad esempioample, fornisce specifiche capacità di debug per le interfacce seriali ad alta velocità dedicate. Alcune delle funzionalità di debug SERDES includono il supporto per test PMA (come la generazione di pattern PRBS e il test loopback), supporto per più configurazioni di test SERDES con riconfigurazione a livello di registro per evitare l'uso del flusso di progettazione completo per apportare modifiche alla configurazione e report di testo che mostrano protocolli configurati, registri di configurazione SERDES e registri di configurazione Lane. Queste funzionalità rendono il debug SERDES molto più semplice e possono essere utilizzate insieme a Live Probe e Active Probe per velocizzare ulteriormente il debug di circuiti complessi.
Lo strumento Memory Debug precedentemente descritto può anche essere utilizzato insieme a SERDES Debug per velocizzare i test. Poiché i buffer di memoria possono essere rapidamente e facilmente ispezionati e modificati con Memory Debug, è possibile creare rapidamente "pacchetti di test" e osservare i risultati di loopback o di comunicazioni inter-sistema. Il progettista può sfruttare queste capacità e quindi ridurre al minimo la necessità di "test harness" specializzati che consumano ulteriore fabric FPGA e che potrebbero avere un impatto sulla temporizzazione del chip.

Conclusione
Questo documento ha descritto in dettaglio diversi approcci per implementare il debug in-circuit per FPGA e SoC FPGA: l'uso di un Integrated Logic Analyzer, l'uso di apparecchiature di test esterne e l'uso di circuiti di sonda dedicati integrati nel fabric FPGA. L'aggiunta di circuiti di sonda specializzati e dedicati, come Active Probe e Live Probe offerti da Microsemi su dispositivi SmartFusion2 SoC FPGA e IGLOO2 FPGA, ha dimostrato di velocizzare e semplificare notevolmente il processo di debug. La capacità di modificare rapidamente la selezione dei segnali interni (senza la necessità di eseguire un ciclo di ricompilazione e riprogrammazione molto dispendioso in termini di tempo) e la capacità di sondare i segnali interni (senza la necessità di utilizzare il fabric FPGA e potenzialmente introdurre violazioni di temporizzazione) hanno dimostrato di essere importanti vantaggitages quando si esegue il debug di progetti FPGA. Inoltre, è stato descritto l'uso di metodologie multiple, che possono funzionare insieme per fornire una capacità di debug ancora più completa. Infine, due exampSono stati forniti casi d'uso di debug per illustrare i compromessi tra i metodi descritti.

Per saperne di più

1. FPGA IGLOO2
2. FPGA SoC SmartFusion2

Microsemi Corporation (Nasdaq: MSCC) offre un portafoglio completo di semiconduttori e soluzioni di sistema per i mercati delle comunicazioni, della difesa e della sicurezza, aerospaziale e industriale. I prodotti includono circuiti integrati analogici a segnale misto, FPGA, SoC e ASIC ad alte prestazioni e resistenti alle radiazioni; prodotti per la gestione dell'energia; dispositivi di temporizzazione e sincronizzazione e soluzioni temporali precise, che stabiliscono lo standard mondiale per il tempo; dispositivi di elaborazione vocale; Soluzioni RF; componenti discreti; tecnologie di sicurezza e scalabili anti-tamper; IC Power-over-Ethernet e midspan; nonché capacità e servizi di progettazione personalizzati. Microsemi ha sede ad Aliso Viejo, California, e ha circa 3,400 dipendenti in tutto il mondo. Scopri di più su www.microsemi.com.

© 2014 Microsemi Corporation. Tutti i diritti riservati. Microsemi e il logo Microsemi sono marchi di Microsemi Corporation. Tutti gli altri marchi e marchi di servizio sono di proprietà dei rispettivi proprietari.

Sede aziendale Microsemi

• Uno Enterprise, Aliso Viejo CA 92656 USA
• Entro gli Stati Uniti: +1 Numero di telefono: 800-713-4113
• Al di fuori gli Stati Uniti: +1 Numero di telefono: 949-380-6100
• Saldi: +1 Numero di telefono: 949-380-6136
• Fax: +1 Numero di telefono: 949-215-4996
• E-mail: sales.support@microsemi.com

Domande frequenti

• D: Qual è la frequenza massima di acquisizione dati del dispositivo?
  R: Il dispositivo supporta l'acquisizione di dati fino a 100 MHz, adatta alla maggior parte dei progetti target.
• D: Devo ricompilare il progetto quando utilizzo i circuiti sonda per il debug?
  R: No, le posizioni dei punti di prova possono essere modificate rapidamente senza dover ricompilare o riprogrammare il progetto.

Documenti / Risorse

Debug FPGA in circuito Microsemi [pdf] Istruzioni Debug FPGA in circuito, Debug FPGA, Debug

Riferimenti

• Manuale d'uso