Un FPGA est-il viable pour un tel projet?

Je travaille actuellement sur Super OSD - un projet d'affichage à l'écran. http://code.google.com/p/super-osd a tous les détails.

Pour le moment, j'utilise un MCU dsPIC pour faire le travail. Il s'agit d'un DSP très puissant (40 MIPS @ 80 MHz, opérations à un cycle à trois registres et une unité MAC) et, surtout, il est livré dans un package DIP (parce que j'utilise une maquette pour le prototyper.) Je tire vraiment le maximum de ses performances en exécutant l'OSD - la puce a environ 200 ns ou 10 cycles par pixel sur l'étage de sortie, donc le code doit être très optimisé dans cette partie (pour cette raison, il sera toujours écrit en Assemblée.)

Maintenant, j'envisageais d'utiliser un FPGA pour cela, car en raison de l'architecture parallèle d'une telle puce, il est possible d'avoir un programme logique simple exécutant l'OSD. Des choses comme tracer des lignes et du code algorithmique seraient gérées par un MCU, mais la sortie réelle se ferait avec un FPGA. Et des choses simples comme la définition de pixels ou le dessin de lignes horizontales et verticales que je voudrais intégrer sur le FPGA, pour améliorer la vitesse.

J'ai quelques questions:

1. Cela coûtera-t-il beaucoup plus cher? Les FPGA les moins chers que j'ai trouvés étaient ~ 5 £ chacun et le dsPIC est de 3 £ chacun. Cela coûtera donc plus cher, mais de combien?
2. Le dsPIC tient dans un package SO28. Je ne voudrais pas aller plus loin que SO28 ou TQFP44. La plupart des FPGA que j'ai vus sont livrés en boîtiers BGA ou TQFP> 100, ce qui n'est pas une option pour le moment, en raison de la taille du cisaillement et de la difficulté de les souder moi-même.
3. Quelle quantité de courant est utilisée par un FPGA? La solution dsPIC consomme actuellement environ 55mA +/- 10mA, ce qui est correct pour le moment. Un FPGA consommerait-il plus ou moins? Est-il variable, ou est-il à peu près statique, comme le dsPIC?
4. J'ai besoin d'au moins 12 Ko de mémoire graphique pour stocker les graphiques OSD. Les FPGA ont-ils ce type de mémoire disponible sur la puce ou est-ce uniquement disponible avec des puces externes?

En principe, c'est un bon candidat pour la conception basée sur FPGA. Concernant vos besoins:

ad 1. Le FPGA sera probablement plus cher, selon le montant qui dépend de l'appareil que vous choisissez. À première vue, le plus petit Spartan 3 de Xilinx (XC3S50AN) sera plus que suffisant pour cette tâche (~ 10 £ de Farnell). Je pense que vous pouvez supposer que c'est la limite supérieure du coût (il a 56 Ko de RAM à l'intérieur, donc c'est plus que ce dont vous avez besoin). Vous pouvez trouver un appareil moins cher, soit de l'offre Xilinx, soit de leurs concurrents Altera et Lattice.

ad 2. Le paquet est le problème difficile, je n'ai pas vu de FPGA avec une empreinte plus petite non plus. Cependant, vous pouvez peut-être utiliser un périphérique CPLD (pour des raisons d'argument, les CPLD sont de petits FPGA) qui peuvent être dans un boîtier plus petit (PLCC ou QFN). Du côté positif, ils seront moins chers (même un seul $) du côté négatif, ils n'auront probablement pas de RAM à l'intérieur. Avec CPLD, vous auriez probablement besoin d'une puce SRAM externe.

ad 3. La consommation de courant des FPGA et CPLD dépend fortement de la conception programmée. Cependant, il y a de fortes chances que le FPGA et en particulier la conception CPLD consomment moins que votre solution actuelle.

ad 4. FPGA a ce genre de mémoire à l'intérieur, CPLD très certainement pas. Cela peut être résolu par une puce sram externe (ou deux). Par exemple:

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

Dans un tel arrangement pendant que l'UC écrit dans SRAM 1, le CPLD affichera les données de SRAM 2. Le CPLD devrait être capable de gérer les deux tâches simultanément.

Bien sûr, vous pouvez également résoudre ce problème par d'autres moyens:
1) utiliser un uController plus rapide (ARM par exemple)
2) utiliser un appareil avec un tissu programmable et uC à l'intérieur (par exemple FPSLIC d'Atmel, cependant je n'ai jamais utilisé de tels appareils et je sais très bien peu sur ceux-là)

Clause de non-responsabilité standard -> car les conceptions sont des problèmes ouverts, avec de nombreuses contraintes et solutions possibles, tout ce que j'ai écrit ci-dessus peut ne pas être vrai pour votre cas. Je pense que cela vaut la peine de vérifier ces options.

Vous pouvez utiliser un CPLD plutôt qu'un FPGA, comme l'une des pièces Altera MAX II. Ils sont disponibles dans des boîtiers QFP44, contrairement aux FPGA. Ce sont en fait de petits FPGA, mais Altera minimise cet aspect. Les CPLD ont un avantage sur la plupart des FPGA en ce qu'ils ont une mémoire de configuration sur puce, les FPGA nécessitent généralement une puce flash externe. Il y a bien sûr d'autres CPLD, mais j'aime bien le MAX II.

Il est impossible de dire quelle sera la consommation actuelle, car elle dépend des vitesses d'horloge et de la quantité de logique réellement utilisée.

Les FPGA ont généralement une quantité limitée de mémoire sur puce que vous pouvez utiliser, mais vous aurez besoin d'une mémoire externe avec un CPLD.

Une autre option serait une puce XMOS , mais la plus petite (la XS1-L1) se trouve dans un boîtier QFP64. Il a beaucoup de RAM sur puce - 64k.

1) Oui, le FPGA sera plus cher. Non seulement la puce elle-même est plus chère, mais vous aurez également besoin de mémoire Flash pour stocker la programmation. FPGA + Flash est probablement 3 fois plus cher que le dsPIC ... environ 10 $ pour un petit FPGA et 3 $ pour un petit Flash.

2) Ils peuvent exister, mais je ne connais pas vraiment de FPGA qui ne soit pas monté en surface. La plupart d'entre eux sont probablement QFP ou BGA.

3) Le FPGA tirera probablement environ 3 fois le courant que fait le dsPIC, mais cela peut augmenter ou diminuer selon les fonctionnalités que vous utilisez. Les FPGA ont de nombreuses fonctionnalités qui peuvent augmenter la consommation d'énergie. Mais attendez au moins 150 mA.

4) Les FPGA ont généralement une RAM de bloc à l'intérieur. Tous les FPGA, sauf les plus petits, devraient avoir autant de mémoire.

D'autres mentionnent les CPLD. Si vous partitionnez soigneusement votre conception, vous pourriez probablement déplacer des opérations petites mais coûteuses dans le CPLD. Ce serait comme un mini coprocesseur.

La solution la moins chère avec la courbe d'apprentissage la plus faible serait de passer à un processeur plus puissant, ARM très probablement.

La programmation d'un FPGA / CPLD en VHDL / Verilog est une courbe d'apprentissage assez raide venant de C pour beaucoup de gens. Ce ne sont pas non plus des pièces trop bon marché.

À l'aide d'un ARM décemment capable peut-être un LPC1769? (cortex-M3), vous pourriez également remplacer le PIC18 dans votre conception.

En ce qui concerne le problème des trous traversants, tant que vous pouvez obtenir le SoC dans un package de type QFP à broches exposées, saisissez simplement certains de ces adaptateurs pour la broche nécessaire pour votre prototypage.

Mon inclination serait d'utiliser quelque chose pour tamponner le timing entre le processeur et l'écran. Avoir du matériel qui peut montrer une image entière de vidéo sans intervention du processeur peut être bien, mais peut-être exagéré. Je suggérerais que le meilleur compromis entre la complexité matérielle et logicielle serait probablement de créer quelque chose avec deux ou trois registres à décalage 1024 bits indépendants (deux bits par pixel, pour permettre le noir, le blanc, le gris ou le transparent), et un moyen de basculer entre eux. Demandez au PIC de charger un registre à décalage, puis au matériel de commencer à décaler celui-ci pendant qu'il définit un indicateur afin que le PIC puisse charger le suivant. Avec deux registres à décalage, le PIC aurait eu 64us entre le moment où il est dit qu'un registre à décalage est disponible et le moment où toutes les données doivent être décalées. Avec trois registres à décalage,

Notez que même si une FIFO 1024 bits serait aussi bonne que deux registres à décalage 1024 bits, et dans un CPLD, une FIFO ne coûte qu'une macrocellule par bit, plus une logique de contrôle, dans la plupart des autres types de logique, deux bits de registre à décalage sera moins cher qu'un bit de FIFO.

Une autre approche consisterait à connecter un CPLD à une SRAM et à créer un sous-système vidéo simple avec cela. Esthétiquement, j'aime la génération de vidéo à la volée, et si quelqu'un a fait de belles puces de registre à décalage 1024 bits, c'est l'approche que je privilégierais, mais utiliser une SRAM externe peut être moins cher que d'utiliser un FPGA avec suffisamment de ressources pour créer plusieurs registres à décalage de 1024 bits. Pour votre résolution de sortie, il sera nécessaire de synchroniser les données à 12 millions de pixels / s ou 3 Mo / s. Il devrait être possible d'arranger les choses pour permettre aux données d'être synchronisées à un taux allant jusqu'à 10 Mbps sans trop de difficulté en entrelaçant les cycles de mémoire; la plus grande astuce serait d'empêcher la corruption des données si une impulsion de synchronisation ne vient pas au moment précis prévu.