Um FPGA é viável para esse projeto?

Atualmente, estou trabalhando no Super OSD - um projeto de exibição na tela. http://code.google.com/p/super-osd possui todos os detalhes.

No momento, estou usando um dsPIC MCU para fazer o trabalho. Este é um DSP muito poderoso (40 MIPS a 80 MHz, operações de ciclo único de três registros e uma unidade MAC) e, mais importante, ele vem em um pacote DIP (porque estou usando uma placa de ensaio para prototipá-lo.) estou realmente obtendo todo o desempenho da execução do OSD - o chip tem cerca de 200ns ou 10 ciclos por pixel no estágio de saída, portanto o código precisa ser muito otimizado nesta parte (por esse motivo, ele sempre será escrito em montagem.)

Agora eu estava pensando em usar um FPGA para isso porque, devido à arquitetura paralela de um chip, é possível ter um programa lógico simples executando o OSD. Coisas como desenhar linhas e código algorítmico seriam tratadas por um MCU, mas a saída real seria feita com um FPGA. E algumas coisas simples, como definir pixels ou desenhar linhas horizontais e verticais que eu gostaria de integrar ao FPGA, para melhorar a velocidade.

Eu tenho algumas questões:

1. Custará significativamente mais? Os FPGA mais baratos que encontrei foram ~ 5 libras cada e o dsPIC é 3 libras cada. Então, vai custar mais, mas por quanto?
2. O dsPIC se encaixa em um pacote SO28. Eu não gostaria de ir além do SO28 ou TQFP44. A maioria dos FPGAs que vi vêm em pacotes BGA ou TQFP> 100, que não são uma opção no momento, devido ao tamanho do cisalhamento e à dificuldade de soldá-los.
3. Quanta corrente é usada por um FPGA? Atualmente, a solução dsPIC consome cerca de 55mA +/- 10mA, o que está bom no momento. Um FPGA consumiria mais ou menos? É variável ou é praticamente estática, como o dsPIC?
4. Preciso de pelo menos 12 KB de memória gráfica para armazenar os gráficos OSD. Os FPGAs têm esse tipo de memória disponível no chip ou está disponível apenas com chips externos?

Em princípio, este é um bom candidato para o design baseado em FPGA. Em relação aos seus requisitos:

anúncio 1. O FPGA provavelmente será mais caro, dependendo de quanto isso depende do dispositivo que você escolher. À primeira vista, o menor Spartan 3 da Xilinx (XC3S50AN) será mais do que suficiente para esta tarefa (~ 10 libras da Farnell). Eu acho que você pode assumir que esse é o limite superior do custo (ele tem 56kB de RAM por dentro, então é mais do que você precisa). Você pode encontrar um dispositivo mais barato da oferta da Xilinx ou de seus concorrentes Altera e Lattice.

anúncio 2. O pacote é uma questão difícil, também não vi o FPGA com menos espaço. No entanto, talvez você possa usar o dispositivo CPLD (por uma questão de argumento, os CPLDs são pequenos FPGAs) que podem estar em pacotes menores (PLCC ou QFN). No lado positivo, eles serão mais baratos (mesmo um único dólar) no lado negativo, provavelmente não terão RAM dentro. Com o CPLD, provavelmente você precisaria de um chip SRAM externo.

ad 3. O consumo atual de FPGAs e CPLD é altamente dependente do design programado. No entanto, há boas chances de que o design do FPGA e, principalmente, do CPLD consumam menos do que sua solução atual.

ad 4. O FPGA possui esse tipo de memória, o CPLD certamente não. Isso pode ser resolvido pelo chip sram externo (ou dois). Por exemplo:

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

Nesse arranjo, enquanto o uC estiver gravando na SRAM 1, o CPLD exibirá dados da SRAM 2. O CPLD deve ser capaz de lidar com ambas as tarefas simultaneamente.

Claro que você também pode resolver isso de outras maneiras:
1) use o uController mais rápido (ARM, por exemplo)
2) use o dispositivo com alguma malha programável e o uC dentro (por exemplo, FPSLIC da Atmel, no entanto, nunca usei esses dispositivos e sei muito bem pouco sobre isso)

Isenção de responsabilidade padrão -> como os projetos são problemas abertos, com muitas restrições e possíveis soluções, o que eu escrevi acima pode não ser verdadeiro para o seu caso. Eu acredito que vale a pena conferir essas opções, no entanto.

Você pode usar um CPLD em vez de um FPGA, como uma das partes do Altera MAX II. Eles estão disponíveis nos pacotes QFP44, diferentemente dos FPGAs. Na verdade, eles são pequenos FPGAs, mas Altera minimiza esse aspecto. Os CPLDs têm uma vantagem sobre a maioria dos FPGAs, pois possuem memória de configuração no chip, geralmente os FPGAs exigem um chip flash externo. Existem outros CPLDs, é claro, mas eu gosto do MAX II.

É impossível dizer qual será o consumo atual, pois depende da velocidade do relógio e da quantidade de lógica que está em uso.

Os FPGAs geralmente possuem uma quantidade limitada de memória no chip que você pode usar, mas precisará de memória externa com um CPLD.

Outra opção seria um chip XMOS , mas o menor (o XS1-L1) está em um pacote QFP64. Possui bastante RAM no chip - 64k.

1) Sim, o FPGA será mais caro. Além de o chip ser mais caro, você também precisará de memória Flash para armazenar a programação. FPGA + Flash é provavelmente 3x o custo de apenas o dsPIC ... cerca de US $ 10 para um FPGA pequeno e US $ 3 para um Flash pequeno.

2) Eles podem existir, mas não tenho conhecimento de nenhum FPGA que não seja montado em superfície. A maioria deles é provavelmente QFP ou BGA.

3) O FPGA provavelmente consumirá cerca de 3x a corrente que o dsPIC faz, mas isso pode aumentar ou diminuir, dependendo dos recursos que você usa. Os FPGAs têm muitos recursos que podem aumentar o consumo de energia. Mas espere pelo menos 150 mA.

4) Os FPGAs geralmente têm RAM de bloco dentro deles. Todos, exceto os menores FPGAs, devem ter tanta memória.

Outros mencionam CPLDs. Se você particionar cuidadosamente seu design, provavelmente poderá mover algumas operações pequenas, porém caras, para o CPLD. Seria como um mini coprocessador.

A solução mais barata com a menor curva de aprendizado seria mudar para um processador de maior potência, provavelmente o ARM.

Programar um FPGA / CPLD em VHDL / Verilog é uma curva de aprendizado bastante acentuada, vinda de C para muitas pessoas. Eles também não são peças muito baratas.

Usando um braço decentemente capaz, talvez um LPC1769? (córtex-M3), você provavelmente também poderá substituir o PIC18 em seu design.

Quanto à questão do furo passante, contanto que você possa obter o SoC em um pacote do tipo QFP de pino exposto, basta pegar alguns desses adaptadores para obter o pino necessário para a sua prototipagem.

Minha inclinação seria usar algo para amortecer o tempo entre o processador e a tela. Ter um hardware que possa mostrar um quadro inteiro de vídeo sem a intervenção do processador pode ser bom, mas talvez exagere. Eu sugeriria que o melhor compromisso entre a complexidade do hardware e do software seria provavelmente fazer algo com dois ou três registros de deslocamento de 1024 bits independentes (dois bits por pixel, para permitir preto, branco, cinza ou transparente) e um meio de alternar entre eles. Faça com que o PIC carregue um registro de turno e, em seguida, o hardware comece a mudar esse registro enquanto define um sinalizador para que o PIC possa carregar o próximo. Com dois registros de turno, o PIC teria 64us entre o horário em que um registro de turno está disponível e o tempo em que todos os dados precisam ser trocados. Com três registros de turno,

Observe que, embora um FIFO de 1024 bits seja tão bom quanto dois registradores de turnos de 1024 bits, e em um CPLD, um FIFO custa apenas uma macrocélula por bit, além de alguma lógica de controle, na maioria dos outros tipos de lógica, dois bits do registrador de turnos será mais barato que um pouco de FIFO.

Uma abordagem alternativa seria conectar um CPLD a uma SRAM e criar um subsistema de vídeo simples com isso. Esteticamente, eu gosto da geração de vídeos on-the-fly, e se alguém fez bons chips de 1024 bits com registro de deslocamento barato, é a abordagem que eu preferiria, mas usar uma SRAM externa pode ser mais barato do que usar um FPGA com recursos suficientes para faça vários registros de deslocamento de 1024 bits. Para sua resolução de saída, será necessário fazer o clock dos dados em 12M pixels / s, ou 3 MBytes / s. Deve ser possível organizar coisas para permitir que os dados sejam sincronizados a uma taxa de até 10mbps sem muita dificuldade, intercalando os ciclos de memória; o maior truque seria impedir a corrupção de dados se um pulso de sincronização não surgisse no momento exato esperado.