Un FPGA è praticabile per un tale progetto?

Attualmente sto lavorando a Super OSD - un progetto di visualizzazione su schermo. http://code.google.com/p/super-osd ha tutti i dettagli.

Al momento sto usando un MCU dsPIC per fare il lavoro. Questo è un DSP molto potente (40 MIPS a 80 MHz, operazioni a ciclo singolo a tre registri e un'unità MAC) e, soprattutto, viene fornito in un pacchetto DIP (perché sto usando una breadboard per prototiparlo.) I ' Sto davvero ottenendo ogni minimo risultato dalle sue prestazioni eseguendo l'OSD - il chip ha circa 200 ns o 10 cicli per pixel sullo stadio di output, quindi il codice deve essere molto ottimizzato in questa parte (per questo motivo sarà sempre scritto in montaggio.)

Ora stavo considerando di utilizzare un FPGA per questo perché a causa dell'architettura parallela di un tale chip è possibile avere un semplice programma logico che esegue l'OSD. Cose come disegnare linee e codice algoritmico sarebbero gestite da un MCU, ma l'output effettivo sarebbe fatto con un FPGA. E alcune cose semplici come l'impostazione di pixel o il disegno di linee orizzontali e verticali che vorrei integrare nell'FPGA, per migliorare la velocità.

Ho alcune domande:

1. Costerà molto di più? I FPGA più economici che ho trovato erano ~ £ 5 ciascuno e il dsPIC è £ 3 ciascuno. Quindi costerà di più, ma di quanto?
2. Il dsPIC si inserisce in un pacchetto SO28. Non vorrei andare più grande di SO28 o TQFP44. La maggior parte degli FPGA che ho visto sono disponibili in pacchetti BGA o TQFP> 100, che al momento non sono un'opzione, a causa delle dimensioni di taglio e della difficoltà di saldarli da soli.
3. Quanta corrente viene utilizzata da un FPGA? La soluzione dsPIC attualmente consuma circa 55mA +/- 10mA, che al momento va bene. Un FPGA consumerebbe più o meno? È variabile o è praticamente statico, come il dsPIC?
4. Ho bisogno di almeno 12 KB di memoria grafica per memorizzare la grafica OSD. Gli FPGA hanno questo tipo di memoria disponibile sul chip o è disponibile solo con chip esterni?

In linea di principio, questo è un buon candidato per la progettazione basata su FPGA. Per quanto riguarda le vostre esigenze:

annuncio 1. L'FPGA molto probabilmente sarà più costoso, in base a quanto dipende dal dispositivo scelto. A prima vista il più piccolo Spartan 3 di Xilinx (XC3S50AN) sarà più che sufficiente per questo compito (~ 10 £ da Farnell). Penso che si possa presumere che questo sia il limite superiore per il costo (ha 56kB di RAM all'interno, quindi è più di quanto sia necessario). Puoi trovare dispositivi più economici dall'offerta Xilinx o dai loro concorrenti Altera e Lattice.

ad 2. Il pacchetto è un problema difficile, non ho visto nemmeno FPGA con ingombro ridotto. Tuttavia, forse puoi usare il dispositivo CPLD (per ragioni di argomento, i CPLD sono piccoli FPGA) che potrebbero essere in un pacchetto più piccolo (PLCC o QFN). Sul lato positivo saranno più economici (anche solo $) sul lato negativo molto probabilmente non avranno RAM all'interno. Con CPLD probabilmente avresti bisogno di un chip SRAM esterno.

ad 3. Il consumo di corrente FPGA e CPLD dipende fortemente dalla progettazione programmata. Tuttavia, ci sono buone probabilità che FPGA e in particolare il design CPLD consumino meno della soluzione attuale.

ad 4. FPGA ha quel tipo di memoria all'interno, CPLD sicuramente no. Questo può essere risolto da un chip sram esterno (o due). Per esempio:

| SRAM 1 | <--> | CPLD | <--> | uC |
| SRAM 2 | <->

In tale accordo mentre l'UC sta scrivendo su SRAM 1, il CPLD visualizzerà i dati da SRAM 2. Il CPLD dovrebbe essere in grado di gestire entrambi i compiti contemporaneamente.

Ovviamente puoi risolverlo anche in altri modi:
1) usa uController più veloce (ARM per esempio)
2) usa un dispositivo con un tessuto programmabile e uC all'interno (per esempio FPSLIC di Atmel, tuttavia non ho mai usato tali dispositivi e lo so molto poco su quelli)

Dichiarazione di non responsabilità standard -> poiché i progetti sono problemi aperti, con molti vincoli e possibili soluzioni qualsiasi cosa abbia scritto sopra potrebbe non essere vera per il tuo caso. Credo che valga la pena selezionare questa opzione, però.

È possibile utilizzare un CPLD anziché un FPGA, ad esempio una delle parti Altera MAX II. Sono disponibili in pacchetti QFP44, a differenza degli FPGA. In realtà sono piccoli FPGA, ma Altera minimizza quell'aspetto. I CPLD hanno un vantaggio rispetto alla maggior parte degli FPGA in quanto hanno una memoria di configurazione su chip, in genere gli FPGA richiedono un chip flash esterno. Ci sono altri CPLD, ovviamente, ma mi piace il MAX II.

È impossibile dire quale sarà il consumo attuale, poiché dipende dalle velocità di clock e dalla quantità di logica attualmente in uso.

Gli FPGA di solito hanno una quantità limitata di memoria su chip che puoi usare, ma avrai bisogno di memoria esterna con un CPLD.

Un'altra opzione sarebbe un chip XMOS , ma il più piccolo (XS1-L1) è in un pacchetto QFP64. Ha un sacco di RAM su chip - 64k.

1) Sì, l'FPGA sarà più costoso. Non solo il chip stesso è più costoso, ma sarà anche necessaria la memoria Flash per memorizzare la programmazione. FPGA + Flash è probabilmente 3 volte il costo del solo dsPIC ... circa $ 10 per un piccolo FPGA e $ 3 per un piccolo Flash.

2) Potrebbero esistere, ma non sono a conoscenza di alcun FPGA che non sia montato in superficie. Molti di questi sono probabilmente QFP o BGA.

3) L'FPGA probabilmente trarrà circa 3 volte la corrente di dsPIC, ma ciò può aumentare o diminuire a seconda delle funzionalità utilizzate. Gli FPGA hanno molte caratteristiche che possono aumentare l'assorbimento di potenza. Ma aspettati almeno 150 mA.

4) Gli FPGA di solito hanno al loro interno RAM di blocco. Tutti gli FPGA tranne i più piccoli dovrebbero avere tanta memoria.

Altri citano CPLD. Se partizionate con cura il vostro progetto, probabilmente potreste spostare alcune piccole ma costose operazioni nel CPLD. Sarebbe come un mini coprocessore.

La soluzione più economica con la curva di apprendimento più bassa sarebbe quella di passare a un processore più potente, ARM molto probabilmente.

La programmazione di un FPGA / CPLD in VHDL / Verilog è una curva di apprendimento piuttosto ripida proveniente da C per molte persone. Inoltre non sono parti eccessivamente economiche.

Usi un ARM decentemente capace forse un LPC1769? (cortex-M3) potresti anche essere in grado di sostituire il PIC18 nel tuo progetto.

Per quanto riguarda il problema del foro passante, fino a quando è possibile ottenere il SoC in un pacchetto di tipo QFP pin esposto, basta prendere alcuni di questi adattatori per il pin necessario per la prototipazione.

La mia inclinazione sarebbe quella di utilizzare qualcosa per bufferizzare i tempi tra il processore e il display. Avere hardware in grado di mostrare un intero fotogramma video senza l'intervento del processore può essere bello, ma forse eccessivo. Suggerirei che il miglior compromesso tra la complessità hardware e software sarebbe probabilmente quello di fare qualcosa con due o tre registri di spostamento indipendenti a 1024 bit (due bit per pixel, per consentire nero, bianco, grigio o trasparente) e un mezzo di passare da uno all'altro. Chiedi al PIC di caricare un registro a scorrimento, quindi fai in modo che l'hardware inizi a spostare quello fuori mentre imposta un flag in modo che il PIC possa caricare il successivo. Con due registri a scorrimento, il PIC avrebbe 64us tra il momento in cui viene detto che un registro a scorrimento è disponibile e il tempo in cui tutti i dati devono essere spostati. Con tre registri a scorrimento,

Si noti che mentre un FIFO a 1024 bit sarebbe buono quanto due registri a scorrimento a 1024 bit, e in un CPLD un FIFO costa solo una macrocellula per bit, più un po 'di logica di controllo, nella maggior parte degli altri tipi di logica due bit di registro a scorrimento sarà più economico di un bit di FIFO.

Un approccio alternativo sarebbe quello di collegare un CPLD a una SRAM e creare un semplice sottosistema video con quello. Esteticamente, mi piace la generazione di video al volo, e se qualcuno realizzasse dei buoni chip a registro a scorrimento a 1024 bit economici è l'approccio che preferirei, ma l'uso di una SRAM esterna può essere più economico rispetto all'utilizzo di un FPGA con risorse sufficienti per crea più registri a scorrimento a 1024 bit. Per la risoluzione dell'output sarà necessario sincronizzare i dati a 12 M pixel / sec o 3 MByte / sec. Dovrebbe essere possibile organizzare le cose in modo da consentire il clock dei dati a una velocità massima di 10 Mbps senza troppe difficoltà intercalando i cicli di memoria; il trucco più grande sarebbe prevenire la corruzione dei dati se un impulso di sincronizzazione non arriva nel momento esatto previsto.