¿Puedes realmente romper un FPGA programándolo mal?

¿Puedes realmente romper un FPGA programándolo incorrectamente?

Soy un chico de software realmente. No es ningún secreto que si su software está equivocado, podría destruir todo tipo de datos importantes y quizás incluso bloquear toda la máquina. Pero es realmente difícil dañar físicamente una computadora con solo programarla.

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

Con un FPGA, está (al menos nominalmente) conectando circuitos individuales juntos. Parece completamente plausible que pueda producirse daño físico en caso de error.

Por ejemplo, podría escribir algunos VHDL solicitando que dos salidas se unan. Si producen diferentes niveles lógicos, imagino que probablemente freiría algo. ( Espero que su herramienta de síntesis le grite que no haga esto ... pero no sé si tales herramientas realmente implementan ese nivel de verificación de errores).

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

Para el caso, definitivamente podría conectar el chip FPGA al resto del circuito de forma incorrecta. Por ejemplo, si confunde los números de pin, podría terminar con la placa tratando de manejar un pin de E / S que el propio FPGA también está tratando de manejar. ¿Los pines de E / S suelen tener alguna "protección" contra tal error? ¿O el chip simplemente se freirá?

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

Normalmente, el software de programación consultará la parte que se está programando para su número de parte, y se negará a programar en un flujo de bits destinado a un modelo diferente de FPGA.

La parte en sí también generalmente se negará a iniciarse si se programa con un flujo de bits que no sea exactamente la longitud correcta (y es muy poco común que los flujos de bits para diferentes chips tengan la misma longitud).

definitivamente podría conectar el chip FPGA al resto del circuito incorrectamente. Por ejemplo, si confunde los números de pin, podría terminar con la placa tratando de manejar un pin de E / S que el propio FPGA también está tratando de manejar.

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

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

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

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

Con algunas excepciones notables, las herramientas generalmente no le dan acceso a las primitivas de silicio reales, por lo que es difícil para un ingeniero de usuario final cargar un diseño eléctricamente inválido * en un FPGA basado en SRAM, excepto quizás descubriendo una herramienta inadvertidamente error.

Los FPGA basados ​​en flash posiblemente podrían tener su reprogramabilidad dañada por ciertas cargas no válidas. Los FPGA de OTP están "dañados" implícitamente incluso por una carga de configuración válida , ya que nunca se puede cambiar.

En última instancia, lo que más se acerca a lo que parece preguntar, y a su ejemplo de HCF, sería una configuración que produjera un estrés térmico intolerable . El consumo de energía es impulsado directamente por la velocidad del reloj y la actividad de volumen * de la lógica utilizada, por lo que si puede engañar a las herramientas para que cambien inútilmente la mayoría de las chanclas en el chip al reloj máximo (hay formas ...), entonces puede producir un calentador bastante efectivo que excedería la mayoría de los sistemas de enfriamiento para uso normal. Entonces es solo una pregunta si algo lo apaga protectoramente antes de cocinar. Y, por supuesto, hay modelos de estimación de potencia en las herramientas, que probablemente sean razonablemente predictivos si no les está mintiendo acerca de la señal de reloj proporcionada.

(* Hay una clase interesante de problema eléctrico que no es un error que puede causar mintiendo a las herramientas, que no es necesariamente destructivo físicamente, pero aún sorprendente. Si alimenta un reloj diferente al que dijo que lo haría o simplemente inestable, puede violar el tiempo de configuración de la dirección en las celdas RAM del bloque síncrono y hacer algo en el sentido de acortarlas y corromper su contenido, por lo que puede ver, por ejemplo, que el contenido de algo designado como ROM en el diseño realmente cambia en tiempo de ejecución simplemente intentando a leer con un mal día. Pero no creo que esto es físicamente destructiva)

Lo más probable es violar la clasificación actual en GPIO al conducir un pin que ya se está manejando. Algunos FPGA tienen límites de corriente configurables o controladores de salida modificables, por lo que esto puede ayudarlo / perjudicarlo si no realiza su mapa de puertos correctamente. De todos modos, debe verificar dos veces su lista de puertos antes de programar, ya que los errores como el intercambio de pines pueden tardar horas en resolverse, es mejor adelantarse a los errores y saber exactamente lo que el firmware estaba destinado a hacer. (a menos que te guste la emoción de encontrar un error)

Los HDL por sí solos generalmente no le permiten conectar dos salidas al mismo cable y dejarán de sintetizar y corregirán su error si tienen un código que lo haga.

Un lugar que podría causar problemas son los puertos bidireccionales, pero debe tener resistencias limitantes de corriente en esos.

Al igual que con los microcontroladores, siempre 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 el FPGA tenga protección incorporada contra tal situación, esto puede provocar daños.

Otra posibilidad es hacer un bucle combinatorio que periódicamente se vuelve metaestable u oscila a una frecuencia mucho más alta que la que está diseñada para manejar el tejido FPGA (varios GHz). Eso provocará un sobrecalentamiento muy localizado que puede causar daños físicos antes de que entre en funcionamiento la protección térmica de todo el chip. Es decir, suponiendo que exista tal protección: si la sobretemperatura no conduce al apagado, simplemente puede llegar a un circuito muy hambriento de energía y déjelo funcionar con enfriamiento insuficiente.

La reconfiguración dinámica también puede evitar protecciones contra configuraciones inválidas de primitivas internas que pueden ser aplicadas por las herramientas de desarrollo en caso de una configuración estática. Por ejemplo, puede configurar un PLL de una manera 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 .