Pmc riconfigurabili – La sfida Cots.

Dalla rivista:
Automazione e Strumentazione

Pubblicato il 10 giugno 2002

Considerazioni di architettura di base

L’ultima generazione di Fpga è così potente che un solo dispositivo, montato su un Pmc provvisto di condensatori di disaccoppiamento, Prom di boot, un pannello frontale terminale per I/O, consentirebbe di realizzare un Pmc riconfigurabile di prestazioni di tutto rispetto. In pratica, comunque, questo approccio ad un Pmc riconfigurabile, non è applicato. Uno dei problemi causato dal fatto che mentre i nuovi Fpga basati su Sram hanno un elevatissimo numero di gate e sono, paradossalmente, inefficienti per implementare memoria di massa. Prevedendola esternamente, come mostrato in figura 1, si consentirebbe di realizzare un primo livello di Pmc riconfigurabile reale. Questa architettura minima, elegante nella sua semplicità e potenzialmente utilizzabile in alcune applicazioni, è relativamente poco flessibile e difficile da utilizzare. Mettere l’interfaccia del bus Pci nell’Fpga può volere dire consumare una quantità considerevole di risorse valide, sia in termine di pin di I/O che di numero di gate logici. Considerando la dimensione di alcune delle Fpga correntemente disponibili, questo potrebbe essere un problema in alcune applicazioni, ma richiede anche che l’utilizzatore “si sporchi le mani” nei dettagli dell’interfaccia e nei driver software a basso livello. Un’altra difficoltà dell’approccio illustrato in figura 1 è la configurazione stessa o, meglio la riconfigurazione del Pmc. Gli Fpga basati su Sram richiedono un flusso di dati di configurazione per il boot. Questo si può realizzare in vari modi, anche utilizzando porte Jtag, tipicamente utilizzate solo per sviluppo o debugging, o la porta dell’host. Il modo più diretto, comunque, consiste nel memorizzare la configurazione in una Prom seriale. L’Fpga fornisce il clock alla Prom all’accensione e si autoconfigura. Sfortunatamente, la riconfigurazione richiede la riprogrammazione o la sostituzione della Prom. La Prom potrebbe potenzialmente essere riprogrammata attraverso l’interfaccia bus Pci implementata dall’Fpga stesso, ma non è così semplice. Per tutti gli impieghi pratici, la riconfigurazione dinamica non è una opzione garantita da una struttura minima.

Variazioni di interfacce e architetturali

Una possibile soluzione alle limitazioni viste nell’architettura minima descritta precedentemente consiste nell’aggiungere un’interfaccia per il bus Pci esterna, come mostrato dallo schema generico di figura 2. Questo trucco rimuove un potenziale problema dall’Fpga, consentendo di utilizzare software di basso livello e driver disponibili sul mercato. Inoltre, può consentire più facilmente la riconfigurazione, sia connettendo l’host port dell’Fpga che abilitando la riprogrammazione della Prom attraverso il bus locale. Un’altra area di incertezza è quella dell’I/O front-end per impieghi particolari. Molte interfacce infatti, richiedono segnali che non possono essere generati o ricevuti direttamente dagli Fpga, come per esempio line driver, segnali analogici o segnali in fibra ottica. In questi casi, può essere conveniente avere tali interfacce integrate sul Pmc. Sebbene questo possa limitare la flessibilità, i progettisti trovano questo approccio preferibile anziché avere una scheda di interfaccia segnali o un modulo addizionale. Questo tipo di Pmc “pseudo-riconfigurabile” è un prodotto comune a molti costruttori di Pmc. Un esempio di Pmc riconfigurabile può essere visto nel nuovo modulo Reef della Bitt- Ware, in figura 3. L’architettura implementata predilige, al posto del front-end per impieghi speciali, ad esempio Rs422/ 485, un blocco di processing per impieghi speciali. L’Adsp- 21160 Hammerhead della Analog Devices è stato aggiunto all’architettura generica per consentire facilità di sviluppo e movimento dati. Qualora il Pmc in oggetto venga montato su una sche-da Pci o cPci carrier, il Reef diventa un’estensione I/O del sistema multiprocessing Dsp. Sebbene il Reef abbia un processore a bordo, non può essere definito un PrPmc come quelli della Sbs Technologies. Il Reef utilizza le estensioni Pmc+ sui pin definiti dall’utilizzatore del connettore J4 per implementare flag, interrupt, I2C, una porta seriale Tdm e link di comunicazione interprocessore. Qualora quindi, si monti un Pmc Reef su una Pmc carrier, esso diventa un subsistema Dsp completo con I/O. L’Fpga Virtex II può essere utilizzato per I/O, processing o entrambi, con il Dsp addetto al processing programmabile ad alte prestazioni. La riconfigurazione dinamica è supportata dalla capacità dell’Asic di comunicazione SharcFin della BittWare di riprogrammare la Prom e di fare reboot dell’Fpga dinamicamente. Il connettore Jtag facilita lo sviluppo e il debugging dell’Fpga e del Dsp. L’interfaccia segnali di front-end consente connessioni dirette all’Fpga, ma può essere configurato per vari tipi di schemi di terminazione, incluso il single-ended o l’Lvds.

Tematiche inerenti lo sviluppo

Un problema comune a tutti i Pmc riconfigurabili consiste nella difficoltà di sviluppo dell’attuale configurazione. Teoricamente, questo potrebbe semplicemente coinvolgere alcuni codici ad alto livello Vhdl o Verilog, compilando tramite l’uso dei tool dell’Fpga e quindi caricando. In realtà, questo potrebbe essere un processo difficoltoso e spesso è l’ostacolo primario all’utilità di un Pmc riconfigurabile. Gran parte del problema risiede nella stessa complessità dell’Fpga. L’accesso a milioni di gate riconfigurabili dà una potenza e flessibilità impressionanti, ma mettere tutti in condizione di riuscire a fare quanto desiderato al momento giusto non è automatico. Mentre i tool stanno continuamente migliorando e il processo diventa o diventerà più semplice, il coding ad alto livello e la sintesi di progetti complessi richiedono generalmente una grossa mole di interventi manuali, di debugging ed esperienza. Un’altra sorgente di complicazione per il progettista sono le condizioni create dalle architetture e dall’ hardware dei fornitori. Anche con il core Fpga pienamente implementato e debuggato, esso deve essere interfacciato ai front e back/ end del Pmc, altra operazione non automatica. Perciò, i fornitori di Pmc riconfigurabili devono provvedere dettagli per semplificare al massimo questo lavoro. Lo scopo viene raggiunto provvedendo core Fpga, o macro, che implementano pienamente le interfacce necessarie. L’integratore di sistema inserirà il core/macro nel suo sviluppo. Alternativamente, al fornitore di Pmc potrebbe venire richiesto di implementare e debuggare pienamente l’integrazione. Molti fornitori hanno fatto un salto in avanti e producono interfacce Pmc per impieghi speciali utilizzanti Fpga senza rendere disponibile la riconfigurabilità all’utente finale. Questo è il caso spesso di funzioni con interfacce proprietarie o complesse che potrebbe essere estremamente difficile documentare e supportare. Infatti, ci sono molti Pmc che non sono venduti sul mercato come riconfigurabili, sebbene lo siano per il costruttore. Per un numero sempre più crescente di sistemi, la flessibilità e la adattabilità rese possibili dai Pmc riconfigurabili superano le potenziali difficoltà incontrate nell’implementazione e nell’integrazione. Dal momento che i tool di sviluppo continuano a migliorare e i Pmc stessi diventano più flessibili e maturi, questo approccio sarà sempre più facile da usare. In tabella è presentato un elenco dei produttori dei moduli Pmc, classificati per funzione, distribuiti dalla Eurolink Systems.