¿Se puede romper una FPGA programándola mal?

Question

¿Puedes realmente romper una FPGA al programarla incorrectamente?

En realidad soy un tipo de software. No es ningún secreto que si el software es incorrecto, puede destruir todo tipo de datos importantes, y tal vez incluso estrellar toda la máquina. Pero es realmente difícil físicamente daños un ordenador con sólo programarlo.

(Hay un sinfín de rumores sobre una instrucción Halt-And-Catch-Fire, o sobre la posibilidad de reflashear el firmware del sistema para bloquear la placa base, o de programar valores incorrectos en la tarjeta gráfica para freír el monitor. Pero todo esto parece ser exactamente eso: rumores. Y todo sobre un hardware obsoleto desde hace mucho tiempo. Parece muy, muy difícil romper los equipos informáticos modernos con una mala programación).

Con una FPGA, estás (al menos nominalmente) conectando circuitos individuales. Parece completamente plausible que puedan producirse daños físicos en caso de error.

Por ejemplo, podrías escribir un VHDL solicitando que dos salidas se unan. Si salen niveles lógicos diferentes, me imagino que eso probablemente freiría algo. (Yo esperanza que tu herramienta de síntesis te gritaría que no lo hicieras... pero no sé si esas herramientas realmente implementan ese nivel de comprobación de errores).

También parece bastante posible elegir accidentalmente el modelo equivocado de FPGA en la herramienta de síntesis, y así terminar tratando de programar tu chip con un flujo de bits destinado a algún modelo totalmente diferente. No sé qué haría eso, pero sospecho que sería "malo".

En este sentido, no cabe duda de que podrías conectar el chip de la FPGA al resto del circuito de forma incorrecta. Por ejemplo, si te equivocas en los números de los pines, podrías acabar con la placa intentando manejar un pin de E/S que la propia FPGA también está intentando manejar. ¿Los pines de E/S suelen tener alguna "protección" contra ese error? ¿O el chip simplemente se freirá?

Answer 1

También parece bastante posible elegir accidentalmente el modelo equivocado de FPGA en la herramienta de síntesis, y así terminar tratando de programar su chip con un flujo de bits destinado a algún modelo totalmente diferente.

Por lo general, el software de programación consultará la pieza que se está programando por su número de pieza, y se negará a programar en un flujo de bits destinado a un modelo diferente de FPGA.

La propia pieza también se negará a arrancar si se programa con un flujo de bits que no tenga exactamente la longitud correcta (y es muy poco común que los flujos de bits de diferentes chips tengan la misma longitud).

definitivamente podrías conectar el chip FPGA al resto del circuito de forma incorrecta. Por ejemplo, si te equivocas en los números de los pines, podrías terminar con la placa tratando de manejar un pin de E/S que la propia FPGA también está tratando de manejar.

Esta es la forma más probable de dañar una FPGA con una programación incorrecta.

Otra forma podría ser programar un diseño muy intensivo en recursos y ejecutarlo a una alta frecuencia (para que se consuma una alta potencia), y luego ejecutarlo en una FPGA sin un disipador de calor adecuado.

¿Los pines de E/S suelen tener alguna "protección" contra un error de este tipo? ¿O el chip simplemente se freirá?

Los pines de salida "suelen" sobrevivir a una condición de cortocircuito durante unos segundos o incluso minutos. Pero nada está garantizado.

Answer 2

Salvo algunas excepciones, las herramientas no suelen dar acceso a las primitivas de silicio reales, por lo que es difícil que un ingeniero de usuario final cargue un diseño eléctricamente inválido* en una FPGA basada en SRAM, salvo que descubra inadvertidamente un error de la herramienta.

Las FPGAs basadas en Flash podrían ver dañada su reprogramación por ciertas cargas no válidas. Las FPGAs OTP están implícitamente "dañadas" incluso por una válido carga de configuración, ya que nunca se puede cambiar.

En última instancia, lo que más se acerca a lo que usted parece pedir, y a su ejemplo de HCF, sería una configuración que produjera una térmica estrés. El consumo de energía depende directamente de la velocidad del reloj y del volumen * de la actividad de la lógica utilizada, así que si puedes engañar a las herramientas para que conmuten inútilmente la mayoría de los flip flops del chip al reloj máximo (hay maneras...) entonces puedes producir un calentador bastante eficaz que superaría a la mayoría de los sistemas de refrigeración para un uso ordinario. Entonces es sólo cuestión de que algo lo apague de forma protectora antes de que se cocine. Y, por supuesto, hay modelos de estimación de potencia en las herramientas, que probablemente sean razonablemente predictivos si no les mientes sobre la señal de reloj proporcionada.

(* Hay una clase interesante de problema eléctrico que no es un bug y que puedes causar mintiendo a las herramientas, que no es necesariamente destructivo físicamente, pero sigue siendo sorprendente. Si alimentas un reloj diferente al que dijiste o simplemente inestable, puedes violar el tiempo de configuración de direcciones en las celdas de la RAM de bloque síncrona, y hacer algo parecido a un cortocircuito y corromper su contenido - así que puedes, por ejemplo, ver que el contenido de algo designado como una ROM en el diseño realmente cambia en tiempo de ejecución sólo por intentar leer con un reloj malo. Pero no creo que esto sea físicamente destructivo)

Answer 3

Lo más probable es que se infrinja el límite de corriente de los GPIO al conducir un pin que ya está siendo conducido. Algunas FPGAs tienen límites de corriente ajustables o controladores de salida cambiables, así que esto puede ayudarte o perjudicarte si no haces bien tu mapa de puertos. Deberías revisar tu lista de puertos antes de programar, ya que errores como el intercambio de pines puede llevar horas para resolverlos, es mejor adelantarse a los errores y saber exactamente lo que el firmware pretende hacer. (a menos que te guste la emoción de encontrar un error)

Los HDL por sí mismos no suelen dejar que conectes dos salidas al mismo cable y dejarán de sintetizar y te harán corregir tu error si tienes un código que hace eso.

Un lugar que podría causar problemas son los puertos bidireccionales, pero deberías tener resistencias limitadoras de corriente en ellos.

Answer 4

Al igual que con los microcontroladores, siempre se puede exceder la corriente total máxima por banco de E/S extrayendo una corriente máxima (o más) de cada pin. A menos que la FPGA tenga una protección incorporada contra tal situación, esto puede resultar en daños.

Otra posibilidad es hacer un bucle combinatorio que, o bien se vuelve metaestable periódicamente, o bien oscila a una frecuencia mucho más alta de la que la estructura de la FPGA está diseñada para manejar (varios GHz). Esto causaría un sobrecalentamiento muy localizado que podría causar daños físicos antes de que la protección térmica del chip entrara en acción. Es decir, suponiendo que exista dicha protección: si la sobretemperatura no conduce al apagado, puedes simplemente idear un circuito que consuma mucha energía y dejarlo funcionar con una refrigeración insuficiente.

La reconfiguración dinámica también puede sortear las protecciones contra la configuración no válida de las primitivas internas que pueden ser aplicadas por las herramientas de desarrollo en caso de una configuración estática. Por ejemplo, puedes configurar un PLL de forma que exceda su frecuencia interna máxima, o alimentar la misma línea de interconexión por dos fuentes a la vez, o forzar un pin de un banco de E/S de alto voltaje para usar su transceptor de bajo voltaje como LVDS.