¿Por qué los FPGA no son ubicuos?

Leyendo sobre FPGAs, si entiendo correctamente, son básicamente circuitos de compuerta lógica totalmente configurables. Siendo esto, uno puede diseñar cualquier cosa con ellos. Uno puede diseñar todo de la manera más personalizada posible y, por lo tanto, cumplir con los mismos fines de una manera mucho más eficiente que se puede obtener utilizando un microcontrolador. Teniendo esto, parece que un FPGA supera a un microcontrolador en cualquier momento, cualquier día. Entonces, mi pregunta es, si los FPGA son realmente tan impresionantes, ¿qué les impide ser mucho más frecuentes que los microcontroladores? Desde este punto de vista, para mí parece que los FPGA deberían haber eliminado los microcontroladores hace mucho tiempo. Entonces, ¿por qué este no es el caso? ¿Es el costo, la dificultad de programar un FPGA o algo completamente diferente?

Estás ignorando muchos factores que intervienen en la elección del diseño:

1. Costo . Los FPGA son más caros que los micros por la misma complejidad de lógica.

2. Complejidad lógica . El código ejecutable puede implementar una lógica mucho más complicada que el mismo número de puertas en el micro utilizado directamente.

3. Facilidad de desarrollo . Es más fácil escribir código ejecutable que definir la lógica para todos los problemas, excepto los pequeños. Incluso los proyectos de microcontroladores modestos tienen miles de líneas de código. El desarrollo de definiciones lógicas equivalentes llevaría mucho más tiempo y sería mucho más difícil de depurar y verificar.

4. Consumo de energía . Dado que los FPGA están destinados a operaciones de alta velocidad que los micros no pueden manejar (de lo contrario usaría un micro), no están optimizados para baja potencia. Esto los hace inadecuados para algunas aplicaciones de baja potencia. Algunos micros tienen corrientes de sueño inferiores a 1 µA y pueden funcionar con solo unos µA a velocidades de reloj lentas. Intenta encontrar un FPGA que pueda hacer esto.

Las principales ventajas de los FPGA frente a los micros es que son más rápidos y pueden hacer más cosas en paralelo. Aparte de eso, prefieres usar un micro. Por lo tanto, en el proceso de diseño, generalmente comienza con un micro, luego de mala gana va a un FPGA cuando realmente necesita la velocidad y / o la operación simultánea de alta velocidad. Incluso entonces, implementa solo las partes críticas para la velocidad en un FPGA y deja las funciones de control de velocidad más bajas y similares en el micro.

Una distinción que no he visto aquí es que los FPGA se usan y se comportan de una manera completamente diferente a los procesadores.

Un FPGA es realmente bueno para hacer exactamente la misma tarea, una y otra vez. Por ejemplo, procesamiento de señales de video, audio o RF. O enrutamiento de paquetes Ethernet. O simulando el flujo de fluido. Cualquier situación en la que se le arroje una gran cantidad del mismo tipo de datos realmente rápido y desea tratarlos de la misma manera. O desea ejecutar el mismo algoritmo repetidamente. El FPGA realmente no tiene 'tareas' que comienzan y se detienen [1], todo su trabajo es hacer lo mismo con cualquier dato que obtenga, mientras esté encendido. No cambia de marcha, no hace nada más. Es el último trabajador de la línea de producción. Hará lo mismo repetidamente, tan rápido como pueda, para siempre.

Las CPU, por otro lado, son el epítome de la flexibilidad. Se pueden programar para hacer cualquier cosa, y se pueden programar para hacer varias cosas diferentes al mismo tiempo. Tienen tareas que comienzan y se detienen, cambian de marcha, realizan múltiples tareas, cambian constantemente y cambian funciones.

El FPGA y la CPU son opuestos completos. El producto básico de la CPU es el tiempo: debe hacer las cosas más rápido. Cuanto más rápido se ejecute su aplicación, mejor.

La mercancía del FPGA es el espacio. Su FPGA es tan grande y solo hay tantas puertas disponibles para realizar la tarea que desea. La mayoría de las veces, el problema es más tamaño que velocidad [2].

Es posible hacer que un FPGA actúe como una CPU. Puede poner un núcleo IP de CPU en un FPGA, sin embargo, es muy difícil de justificar debido a las razones que otros han descrito [3]. El FPGA y la CPU son opuestos, ambos tienen sus propias fortalezas y debilidades, y ambos tienen su propio lugar como resultado.

Notas:

1) Un FPGA podría diseñarse para realizar diferentes tareas, pero incluso entonces sería un número específico para el que fue prediseñado.

2) La velocidad también es una especificación de diseño FPGA. Es realmente una compensación entre velocidad y tamaño.

3) Colocar una CPU en un FPGA se realiza con relativa frecuencia, sin embargo, se realiza caso por caso, dependiendo de las aplicaciones específicas. Por ejemplo, si necesita un microcontrolador realmente pequeño y tiene espacio FPGA adicional.

Y finalmente: esta respuesta es una gran simplificación: los FPGA se usan de formas muy variadas y complejas y esta es una breve descripción general de la forma en que se usan en general.

Como dice Olin, algo como un micro es más eficiente para muchas tareas, y casi siempre encontrará un micro usado donde aparezca un FPGA. La superficie de silicio utilizada (que se traduce en costo de forma no lineal) y el consumo de energía son mucho menores. Por esa razón, no es raro implementar un MCU 'suave' en un FPGA, pero el costo y el rendimiento de un micro de este tipo es decepcionante.

Algunos FPGA modernos contienen uno o más núcleos "duros", como la omnipresente serie ARM. Además, pueden contener bloques de memoria dedicados, ya que es realmente ineficiente hacer memoria con compuertas. Un micro núcleo de 32 bits ocupa una pequeña parte del área de silicio en un FPGA típico, lo que le da una idea de los costos relativos.

El desarrollo es significativamente más difícil, y el IP tiende a no estar disponible de forma tan gratuita como para micros y soluciones SOC dedicadas, por ejemplo, controladores LCD, interfaces PCI, MAC Ethernet. La razón es en parte que al revelar las descripciones lógicas de HDL están transfiriendo el diseño, no solo la instanciación del diseño. Otra razón es que el rendimiento depende del diseño de la lógica en la FPGA, que requiere mucho esfuerzo durante el desarrollo.

Una complicación adicional es que los FPGA más complejos están basados ​​en RAM para la configuración y los costos del proceso son tales que se requiere memoria externa no volátil para almacenar la configuración y la memoria de programa para cualquier MCU a bordo. Esta memoria debe cargarse en la RAM al momento del encendido.

Los FPGA son herramientas extremadamente útiles en la caja de herramientas, pero no van a reemplazar MCU o ASIC universalmente en el corto plazo.

El mejor uso de silicio para un trabajo es un ASIC, no se desperdicia nada, pero tienen una gran curva de aprendizaje, NRE e inflexibilidad.

Hay dos formas de incorporar flexibilidad en un chip. a) Tenga una ALU con espacio optimizado y úsela una y otra vez en los datos almacenados. Esto se llama MCU y requiere una gran área de silicio que 'no está haciendo nada', la memoria del programa, los buses anchos que se ejecutan de una unidad a otra y los interruptores de acceso al bus. b) Tener una lógica de grano fino, con algunas partes opcionales de espacio optimizado como multiplicadores, pequeñas RAM y CPU simples. Esto se llama FPGA y requiere una gran área de silicio que 'no está haciendo nada', interruptores programables y líneas de conexión.

Obviamente, con esas estructuras, las MCU funcionan mejor para tareas que se pueden dividir en fragmentos en serie, y los FPGA funcionan mejor para tareas que necesitan operación en paralelo de alta velocidad. Cuando la aplicación es pesada y el costo está dominado por el costo del silicio, así es como se usarán los dos tipos de forma natural.

Cuando la aplicación es ligera pero de alto volumen, el costo está dominado por el empaque en lugar del silicio, y cualquier tipo es viable. Altera tiene algunos FPGA muy pequeños de muy baja potencia para competir con MCU de un dólar por puñado.

Para aplicaciones de bajo volumen, el costo de desarrollo tiende a dominar, y los MCU ganan, suponiendo que tengan la velocidad

En términos de consumo de energía y utilización de silicio, un FPGA es muy pobre en comparación con un microprocesador.

Un FPGA consume gran parte de su área de silicio en el circuito de configuración lógica, algo que no se aplica a un micro. Tiene que haber muchas más interconexiones disponibles de las que serían necesarias en una implementación dedicada de un microprocesador.

El FPGA consume más energía que un ASIC dedicado, como un microprocesador, ya que la lógica no se implementa de manera tan eficiente.

Cualquier función que se pueda implementar en un FPGA se puede hacer de manera más eficiente, más barata, con un menor consumo de energía, un espacio de placa más pequeño, etc. en un ASIC dedicado. Esto supone que los volúmenes son lo suficientemente grandes como para compensar la NRE.

Los sistemas ds basados ​​en microprocesadores y, posteriormente, los microcontroladores, han sido capaces de lograr un enorme grado de funcionalidad gracias a su capacidad de utilizar muchas de las piezas de circuitos individuales para realizar muchas tareas diferentes en diferentes momentos. Creo que es instructivo comparar la máquina arcade Tank, diseñada en 1976, con el juego Combat que se ejecuta en la segunda máquina de juego controlada por microprocesador del mundo, la Atari 2600. Si bien hay algunas diferencias en el juego, el hardware Atari 2600 fue diseñado esencialmente implementar juegos como Tank a un costo mínimo; El hecho de que se pudiera jugar diferentes juegos insertando diferentes cartuchos ROM fue una buena ventaja.

El juego Tank permite a dos jugadores conducir tanques alrededor de la pantalla y dispararse unos a otros. Tiene contadores de "deslizamiento" para la posición X e Y de cada tanque, la posición X e Y de los disparos de cada jugador, el contador arriba / abajo para el ángulo de cada jugador y el ángulo de disparo de cada jugador, un contador para el puntaje de cada jugador, el haz de trama X e Y -los contadores de posición y muchos circuitos de control encima de esas cosas. Tiene hardware para obtener datos del campo de juego desde la ROM y mostrarlos, así como hardware para obtener formas para los tanques y puntajes de los dos jugadores desde la ROM y mostrarlos.

El Atari 2600 tiene un contador de deslizamiento para las posiciones horizontales de cada uno de los objetos de dos jugadores, cada uno de los dos objetos de misil y un objeto adicional llamado "bola" que no se usa en Combate pero se usa en otros juegos. Para cada uno de los objetos del reproductor, tiene hardware para generar un patrón almacenado en un pestillo de 8 bits, así como un pestillo "retrasado" de ocho bits para cada jugador que se copia en el pestillo primario de 8 bits cada vez que el otro jugador La forma se actualiza. También tiene un contador de posición de haz horizontal y un pestillo en forma de campo de juego de 20 bits que se emite a la pantalla dos veces por línea de exploración, con la copia del lado derecho como una repetición o un reflejo de la izquierda. Tiene hardware para detectar colisiones, pero no para hacer nada como consecuencia de ellas. Lo hace no no tiene ningún hardware para las posiciones verticales de ningún objeto, ni la posición vertical del rayo de trama (!), ni tiene ningún hardware asociado con el mantenimiento de puntajes, la visualización de puntajes, la duración del juego, etc.

Todas las funciones para las cuales el 2600 omite hardware son manejadas por software en el cartucho. Solo es necesario verificar la posición vertical de cada objeto contra la posición del haz de trama una vez por línea de exploración, solo es necesario actualizar el puntaje del jugador y el tiempo restante del juego como máximo uno por cuadro, los puntajes de los jugadores se almacenan en líneas de exploración sobre el campo de juego y por lo tanto puede compartir el mismo hardware que se usa para el campo de juego, etc.

El enfoque normal para implementar un juego como "Tank" en un FPGA sería usar circuitos separados para diferentes funciones de la misma manera que lo hizo la máquina arcade de 1976. Tal enfoque funcionaría, pero usa una cantidad sustancial de hardware. Un enfoque basado en un microprocesador podría eliminar más de la mitad de ese hardware a cambio de agregar un microprocesador, que probablemente contendría menos circuitos que el hardware que reemplazó (el 2600 podría implementar juegos mucho más sofisticados que Tank, lo que requeriría mucho más hardware si no usaran un microprocesador).

Los FPGA son excelentes en los casos en que uno necesita un dispositivo que pueda realizar muchas tareas simples simultáneamente . Sin embargo, los sistemas basados ​​en microprocesadores (o basados ​​en microcontroladores) son generalmente mejores en los casos en que hay muchas tareas que deben realizarse, pero no necesitan procesarse simultáneamente, ya que facilitan el uso de una pequeña cantidad de circuitos para lograr una gran cantidad de propósitos distintos.

Es completamente el costo. Cuando un micro puede ser tan bajo como 30 centavos, un FPGA barato está en el territorio de $ 5. El costo puede no parecer tan alto, pero cuando ganas un millón de juguetes novedosos para vender a $ 10, entonces el precio del FPGA mata tus ganancias.

Solo para agregar a las otras muy buenas respuestas, creo que la adopción de FPGA también es una cuestión de dominio: por ejemplo, para dispositivos neuromórficos, las placas FPGA se están volviendo bastante ubicuas porque existe una gran necesidad de paralelismo, lo cual es un punto fuerte de FPGA.

Si extrapola la tendencia que vemos para los dispositivos neuromórficos, uno puede imaginar que otros campos que se basan, o requieren críticamente, el paralelismo probablemente adoptarán FPGA mucho más. Entonces, tal vez FPGA no se vuelva omnipresente para productos de grado de consumo, pero puede ser para dominios específicos, ya que parece que actualmente está sucediendo para dispositivos neuromórficos.