I progettisti che utilizzano Fpga devono superare molti ostacoli prima di poter trasferire i loro dispositivi in produzione. Nella fase iniziale individuano il dispositivo più adatto per il loro progetto, quindi implementano il progetto utilizzando un linguaggio di descrizione dell’hardware, effettuano il fitting (ovvero l’assegnazione delle risorse disponibili ai vari blocchi circuitali) e quindi procedono al debug dell’intero Fpga prima di trasferire il progetto stesso in produzione. Per molti degli odierni progetti, in particolar modo quelli destinati ai mercati industriale o embedded, è previsto l’impiego di Fpga differenti. In numerosi casi, la scelta del produttore di Fpga è frutto delle esperienze fatte con il software di sviluppo. Sebbene quello appena menzionato sia un elemento da prendere in considerazione, è necessario valutare un altro aspetto che ha sicuramente una rilevanza maggiore, rappresentato dalle funzionalità di debug del software e dell’hardware dell’Fpga. Anche se oggi sono disponibili numerosi tool di debug, esiste una classe di tool di debug più intelligenti che i progettisti dovrebbero prendere in considerazione nel momento in cui procedono alla valutazione dell’Fpga da utilizzare in un progetto.
Le basi del debug: analizzatori logici
Ciascuno dei maggiori produttori di Fpga propone un analizzatore logico come tool di debug. Si tratta di una sezione di logica istanziata che utilizza elementi logici dell’Fpga interni e blocchi di memoria embedded per implementare il campionamento dei segnali. Un progettista può specificare quali segnali visualizzare e monitorare, oltre a predisporre un segnale di trigger che indichi all’analizzatore logico il momento in cui iniziare l’operazione di acquisizione dei dati. Una volta configurato l’analizzatore logico, un progettista deve ripetere le operazioni di sintesi e di place & route in modo da integrare questa funzione nel progetto. Una volta ricompilato e riprogrammato il progetto, il progettista può iniziare a osservare il segnali logici dell’analizzatore logico. A questo punto è importante sottolineare il fatto che poiché questi segnali devono essere campionati, non sono in grado di acquisire le prestazioni in tempo reale dei dati. L’analizzatore logico può girare solamente a velocità che gli consentono di campionare i dati e salvare i valori nella memoria interna. Uno dei limiti principali di questo tool di debug è rappresentato dal fatto che l’errore spesso sarà eliminato o mascherato durante la fase di ricompilazione del progetto e, sebbene l’errore possa scomparire, la mancanza di informazioni circa l’esatta natura del problema può comportare la rigenerazione dell’errore nel momento in cui viene effettuata una nuova operazione di place & route. Un altro svantaggio dell’analizzatore logico è dato dal fatto che il campionamento è più lento rispetto alla velocità di commutazione dei segnali, ragion per cui condizioni di trace ad alta velocità potrebbero non essere acquisite. Nonostante queste limitazioni, un analizzatore logico consente di osservare lo stato dei segnali in base a una condizione di trigger e ciò facilita il debug dei problemi di progettazione. L’utilizzo di un analizzatore di spettro è fondamentalmente un processo di natura iterativa - un progettista osserva per vedere quello che sta accadendo, effettua un aggiornamento e quindi procede alla ricompilazione del progetto. A questo punto il progettista procede a un riesame dei nuovi risultati e ripete il processo più volte finché non viene individuato l’errore. Il tempo richiesto per ciascuna iterazione e per ogni specifico errore è variabile, mentre non è possibile catturare tutti i problemi a causa della minore velocità di campionamento dell’analizzatore logico. A causa delle limitazioni degli analizzatori logici in fase di debug, sono stati realizzati nuovi tool di debug con l’obiettivo di accelerare la validazione dell’Fpga e della scheda. Synopsys, ad esempio, propone un tool, denominato Identify, che integra funzionalità proprie dell’analizzatore logico nel tool di sintesi Synplify per ridurre il numero di iterazioni richieste per l’individuazione dell’errore. Grazie all’integrazione dell’analizzatore logico, è possibile effettuare visualizzazioni a livello di netlist del progetto e semplificare il setup del trigger. Un progettista può anche apportare modifiche al progetto che vengono mappare automaticamente nel codice Rtl (Register transfer level). Al fine di risparmiare le risorse interne dell’Fpga, Identify è anche in grado di campionare gruppi di segnali ed eseguire la multiplazione, un operazione utile nelle fasi iniziale del processo di debug quando la causa effettiva del problema non è nota. Nonostante i miglioramenti che Identify è in grado di garantire nell’esecuzione del processo di debug, approcci di questo tipo sono tutti penalizzati dal fatto di dover eseguire la ri-compilazione, che influenza il progetto originale e richiede tempo per effettuare il re-fitting e dalla ridotta velocità di campionamento dei segnali.
Un analizzatore logico all’interno dell’Fpga
Oltre a un analizzatore logico integrato, un progettista potrebbe conseguire concreti vantaggi anche dalla disponibilità di un oscilloscopio, anch’esso integrato nel dispositivo programmabile. Questa funzionalità permette di ottenere finestre in tempo reale grazie alle quali è possibile osservare l’andamento effettivo dei segnali di un progetto. Essa sarebbe anche ideale per sondare i nodi all’interno dell’Fpga in tempo reale e forzare differenti valori sui segnali interni per osservare immediatamente il loro effetto sul progetto. Inoltre la possibilità di effettuare operazioni di lettura/scrittura sulle memorie interne, così come i probe point dei transceiver SerDes, potrebbero risultare molto utili. Un esempio di questo tipo di approccio è rappresentato dal tool SmartDebug integrato nella suite di progettazione Libero SoC di Microsemi utilizzata con gli Fpga delle famiglie PolarFire, SmartFusion2 e Igloo2. Questo toolset consente ai progettisti di effettuare il debug della struttura Fpga, dei blocchi di memoria e dei SerDes come se stessero utilizzando un oscilloscopio. Con SmartDebug è possibile utilizzare i probe point specifici e dedicati integrati all’interno della struttura dell’Fpga in modo da accelerare e semplificare il processo di debug. Esso permette anche di selezionare differenti probe point senza dover procedere alla ricompilazione del progetto. Le caratteristiche avanzate di debug integrate consentono l’accesso a qualsiasi elemento logico e danno ai progettisti la possibilità di verificare lo stato di ingressi e uscite in tempo reale. Le caratteristiche chiave che possono essere utilizzate senza dover effettuare il re-fitting del progetto sono di seguito sintetizzate.
- Live probes - Questa funzionalità consente a un massimo di due sonde dedicate che possono essere configurate di osservare qualsiasi nodo presente nella struttura dell’Fpga, come ad esempio qualunque ingresso o uscita di un elemento logico. I dati della sonda sono selezionati dal software, quindi viene inviato un comando attraverso un cavo ai pin Jtag e i segnali saranno immediatamente visibili su un oscilloscopio. Questi probe point sono di natura dinamico e real-time. Non è richiesta nessuna operazione di ricompilazione o riprogrammazione dell’Fpga e i probe point possono essere modificati “al volo” più volte e i relativi segnali saranno immediatamente visualizzati.
- Active probes - Questa caratteristica permette di effettuare operazioni di lettura o scrittura in modo asincrono su un flip flop o un probe point. Il progettista può scegliere i registri della struttura dell’Fpga o le locazioni del blocco di memoria. Questa funzionalità consente a un utilizzatore di osservare in tempi brevi l’uscita della logica internamente oppure verificare in che modo la logica verrà influenzata da un’operazione di scrittura in un probe point. È possibile forzare qualsiasi numero di segnali a valori specifici e, come nel caso di Live Probes, non è necessaria alcuna ricompilazione o riprogrammazione dell’Fpga. Le sonde di tipo attivo sono utili per forzare guasti in un progetto al fine di osservarne l’effetto.
Ridurre i tempi del debug
I progettisti di sistemi basati su Fpga spendono anche più del 30% del loro tempo per effettuare il debug del loro design. Questa percentuale può essere addirittura superiore in funzione delle dimensioni e dello stato del progetto. Nel caso di un Fpga di media densità, ad esempio, il completamento del debug può richiedere diverse settimane. Si tratta di un processo complesso e impegnativo che comporta l’esecuzione di parecchi cicli iterativi dove l’osservabilità e la controllabilità sono limitate, oltre alla necessità di effettuare frequenti operazioni di place and route, chiusura delle temporizzazioni e riprogrammazione. Grazie all’uso di tool intelligenti per il debug, i progettisti possono validare i loro design in un tempo inferiore rispetto a quello richiesto utilizzando un analizzatore logico integrato tradizionale. Nel caso di un Fpga con 300K LE della serie PolarFire è possibile utilizzare non solo un analizzatore logico, ma anche la funzionalità di oscilloscopio. Consentire a un progettista di osservare i segnali in tempo reale e di controllare gli stati del segnale dell’intero progetto permette di accelerare l’operazione di debug. La sostituzione dell’analizzatore logico interno con funzioni di debug intelligenti ha permesso di identificare un problema nel giro di poche ore (invece che di settimane come solitamente accadeva). Il problema che il progettista doveva risolvere è stato individuato in un modulo del progetto completamente diverso da quello su cui stava indagando con l’analizzatore logico. Il progetto in questione è stato ulteriormente migliorato forzando diversi valori mediante la funzionalità Active Probes e verificando la corretta risposta da parte del circuito.
