Recreación exacta de binarios FPGA de Xilinx desde el control de origen

3

Soy desarrollador de software en una pequeña tienda donde solo ha habido un responsable de EE para una serie de diseños de FPGA durante una década, casi todos los cuales se dirigen a la línea Spartan, específicamente al XC3S5000.

Estoy buscando la opinión de la comunidad sobre algunas de las afirmaciones de los tipos de EE que me resultan difíciles de creer:

1.) Muchas compilaciones deben crearse y probarse (sin cambiar los archivos de entrada) porque un binario en particular a menudo falla las pruebas debido a "problemas de tiempo". (literalmente)

  

Yo: ¿Se espera la falla frecuente de un diseño de FPGA y este proceso increíblemente lento se considera normal? No puedo imaginarme repetidamente compilando el mismo lenguaje de desarrollo de software tradicional y esperando que la salida sea la correcta * esta vez *. El HDL parece subespecificado si este es el caso.

2.) Debido a que el proceso de creación está sujeto a algoritmos "aleatorios" (supongo que esto es la colocación y el enrutamiento) es "muy difícil" recrear el binario solo desde la entrada HDL.

  

Yo: Seguramente hay una semilla inicial proporcionada a este algoritmo pseudoaleatorio que se puede consultar después de una compilación exitosa. El binario bueno exacto podría luego ser recreado usando la semilla más tarde. Esta semilla se puede registrar opcionalmente en el control de origen.

3.) Debido a que las herramientas provistas por Xilinx pueden cambiar (ser actualizadas, etc.) incluso si una recreación exacta es posible a partir de una buena semilla conocida y las herramientas antiguas, un nuevo conjunto de herramientas puede crear un binario que no prueba. . El tipo de EE no ve ningún uso en la investigación de cómo encontrar la semilla aleatoria utilizada para una compilación y cómo proporcionarla para una reconstrucción.

  

Yo: ¿Qué tan probable es que una compilación se rompa con la introducción de nuevas herramientas?

4.) El proceso de compilación binaria no permite ninguna manipulación posterior a la compilación de los bytes del binario debido a la suma de comprobación y la imposibilidad de escribir en un binario a un desplazamiento conocido.

  

Yo: ¿No puede incrustar información en un binario existente?

5.) Insiste en verificar tanto el producto final como los archivos NGC.

  

Yo: ¿Hay alguna razón para almacenar archivos NGC?

Notas :

* Los binarios de FPGA se almacenarán en un lugar diferente, pero definitivamente no en un sistema de control de versión centrado en texto.

* Utilizamos un esquema de versión frágil para consultar qué FPGA se está ejecutando actualmente en nuestro sistema. Es útil que el software solucione los errores de hardware al verificar si el FPGA es de una versión determinada. Podemos leer un número monótonamente de 16 bits y una fecha de compilación del FPGA, pero estos números no se sincronizan directamente con el sistema de control de versiones en el que se registra el binario.

* Ya he revisado las siguientes preguntas: Qué archivos / directorios se necesitan para recrear un proyecto de Xilinx PlanAhead?

Lista de sufijos de archivos Xilinx (para ISE)

    
pregunta Cat Zimmermann

3 respuestas

4

Solía trabajar en un trabajo que tenía un requisito de contrato para que pudiéramos reconstruir nuestros diseños y simulaciones de circuitos integrados por veinte años . Esa fue una batalla que peleamos una y otra vez, así que he tenido algo de experiencia con el doloroso proceso de "archivar" un diseño complejo.

1) Si el diseño tiene restricciones de tiempo estrictas, entonces puede ser necesario sintetizar / optimizar varias veces antes de que todos los problemas de tiempo se descubran y las restricciones de tiempo se "especifiquen de manera completa y correcta" como lo indica Dave Tweed. Esto es particularmente cierto si incorpora alguna IP de terceros, o si la persona que realiza la síntesis no es el autor del HDL.

2) Si bien el proceso de síntesis es determinista, también está sujeto a un gran número de variables. Algunos de estos están ocultos al usuario. Si bien diría que debería poder obtener el mismo binario si ejecuta exactamente las mismas herramientas en la misma computadora en el mismo HDL con las mismas restricciones el mismo día, no me atrevería a garantizar que cualquier binario dado podría reproducirse exactamente la próxima semana.

3) Esto es ciertamente cierto. Las nuevas versiones de las herramientas de diseño rompen rutinariamente los diseños existentes. No se trata de una semilla para un generador de números aleatorios, se trata de cambios en los algoritmos de optimización y cambios en los datos de caracterización de la parte física. Debido a que estos cambios son información patentada, están en gran parte ocultos al usuario y pueden aparecer para tener una naturaleza aleatoria.

4) Esto es típicamente cierto. El flujo de bits binario es el resultado final de todo el proceso de síntesis y optimización. La mayoría de los proveedores ocultan el formato de estos datos e incluso pueden cifrarlos, por lo que no puede encontrar herramientas de diseño de FPGA de código abierto que lleguen hasta el chip.

5) ¿Hay alguna razón para almacenar el NGC? Lo cambiaré: ¿puede justificar que no hay información alguna en el NGC que no pueda obtenerse de lo que esté llamando el "diseño final"?

    
respondido por el Joe Hass
3

Parece que su "tipo EE" no ha especificado adecuadamente las restricciones de tiempo para las herramientas de diseño (en el archivo .UCF), si algunas ejecuciones cumplen con el tiempo y otras no. Todas sus afirmaciones que usted cita parecen ser soluciones para esta situación.

Cuando las restricciones de tiempo se especifican completa y correctamente, las herramientas de Xilinx trabajarán tan duro como sea necesario para asegurarse de que se cumplan (incluidos los márgenes para tener en cuenta las variaciones debidas a proceso, voltaje y temperatura ). Sí, las ejecuciones sucesivas serán diferentes en detalles menores debido a la aleatoriedad utilizada en el proceso de optimización, pero cada ejecución que se complete cumplirá con el tiempo, o las herramientas le dirán explícitamente dónde hubo un problema.

    
respondido por el Dave Tweed
2

Estaría de acuerdo en que el problema # 1 podría ser un uso incompleto de las restricciones de tiempo, aunque quizás solo si sus requisitos son razonables para el hardware, en comparación con los casos afortunados.

El problema # 4 puede o no ser cierto, dependiendo de las necesidades y circunstancias precisas no especificadas. Xilinx proporciona la herramienta Data2MEM que puede cambiar el contenido de la ROM en bloque de un flujo de bits compilado, algo que a menudo es útil para actualizar el software de un procesador integrado, o tablas / claves. Sin embargo, no es compatible con las opciones de cifrado y compresión. Y no sirve para nada que no sea una memoria de bloque. (La última vez que verifiqué, que fue hace unos años, Altera no tenía un equivalente, lo que significa que realmente tuvo que reconstruir esos diseños para cambiar los contenidos de la memoria del bloque)

Para la mayoría de los otros problemas (irreproducibilidad de binarios precisos al menos en entornos de compilación y cambios en la versión de la cadena de herramientas, problemas de compatibilidad de la versión de la cadena de herramientas), es probable que su ingeniero tenga un punto válido. Puede que le resulte muy informativo probar algunos proyectos FPGA simples para tener una idea de lo diferente que es desarrollarlo para una computadora con programa almacenado, especialmente si está acostumbrado a abrir cadenas de herramientas de código fuente.

    
respondido por el Chris Stratton

Lea otras preguntas en las etiquetas