Cómo obtener un diseño FPGA que definitivamente funcione en el hardware real

En un lugar donde trabajaba había dos campos de diseñadores de FPGA. Un campo al que llamé simular, simular, simular o cubos. El otro campamento fue todo sobre diseño.

Los chicos en cubos usaron un simulador como modelsim, ellos desarrollarían un diseño inicial a través de métodos de codificación y / o bloques en la suite de diseño. Luego lo simularían y encontrarían las cosas que no funcionarían, luego cambiarían el código. Este proceso se repitió varias veces hasta que crearon un diseño que funcionó.

El campo de diseño (que preferí) diseñaría la forma de onda en papel (o papel digital como visio), exactamente lo que se requería. Luego sube con un diagrama lógico. Este es un proceso de auto-documentación. Luego el diagrama se tradujo al código (el código y el diagrama eran 1: 1 si había algo en el diagrama, había un proceso para ello en el código). Luego se simuló y la forma de onda de simulación se comparó con la forma de onda diseñada en el papel, y se esperaba que fuera la misma.

Terminé haciendo ambas cosas, a veces me metía en el modo de cubos, y no era muy divertido. Descubrí que a veces perdía de vista mi objetivo. Por ejemplo, cambiaría un estado en una máquina de estado, y el cambio se trasladaría al siguiente estado, luego tendría que arreglarlo. Terminé pasando más tiempo que pensando en ello.

¿En qué campamento prefieres estar? Creo que debe haber un diseño riguroso, hacer lo que funcione para usted, pero creo que cuanto más detallado y riguroso sea su diseño, menos problemas tendrá a la larga. Di algunos ejemplos de lo que es posible, es posible que no se ajusten a la estructura organizativa de su lugar de trabajo. La razón por la que los detalles de diseño y la planificación cuidadosa son tan útiles es porque te obliga a pensar qué estás haciendo. Facilita la depuración. Desarrollar un flujo de trabajo de diseño que permita que esto suceda. Además, familiarícese realmente con las herramientas de simulación y escriba buenos bancos de pruebas que probarán todas las condiciones que podría experimentar el dispositivo simulado. Esto, por supuesto, necesita ser equilibrado con el tiempo. Por ejemplo, escriba el código ADC HDL que simulará el dispositivo en sus simulaciones.

La herramienta más valiosa para tener en el diseño de FPGA (en mi opinión) es un buen procedimiento de prueba que le permitirá probar completamente su diseño y ejecutarlo a través de sus pasos. No se puede esperar que un diseño de FPGA "solo funcione" requiere un esfuerzo para asegurarse de que todas las piezas funcionen. Si detecta errores, vuelva a la simulación y el diseño y aprenda cuáles son las diferencias entre un FPGA simulado y una RTL. Esto se debe principalmente a la experiencia, pero si el diseño funciona en simulación pero no en hardware, debe averiguar por qué hay una diferencia.

Algunas cosas clave que aprendí:
1) Desinfecte sus entradas, el reloj y los circuitos de reinicio deben estar limpios o puede obtener metastablity propagándose a través de su sistema. Saber qué es un sincronizador de doble rango. Hay muchas topologías diferentes para los circuitos de reinicio, sé cómo usarlos (hay un gran artículo en la web, aunque no lo tengo a mano). 2) Obtenga los requisitos del diseño por adelantado y luego diseñe alrededor de ellos. Si las personas que te rodean no te dan requisitos definidos, entonces crea algunos por tu cuenta.
3) La caja de herramientas de punto fijo de Matlab es excelente para simular sistemas de control y aplicaciones DSP, pero es posible que no tenga acceso a eso. Es una excelente manera de probar un diseño antes de codificar.
4) El diseño es lo primero, luego la codificación, luego la simulación.
5) Escrito con firmeza, también mantenga los nombres de las señales consistentes en el esquema de PCB y HDL. (esta es también la razón por la que prefiero VHDL en lugar de verilog.

Las cosas principales son:

• Codificación cuidadosa para evitar estructuras no sintetizables
• Minimice los niveles lógicos para un mejor rendimiento de tiempo (haga que la lógica entre registros sea lo más simple posible)
• prueba, prueba, prueba para asegurar la corrección funcional y verifica cosas como registros sin inicializar y cables desconectados
• los registros de síntesis y verificación de síntesis para advertencias, asegúrese de que las advertencias no indiquen problemas (es decir, la advertencia de registro eliminado puede ser intencional (no usó una salida del módulo) o involuntaria (se olvidó de conectar la salida del módulo / typo / etc.) )
• mapeo y verifique el informe del mapa para las cifras de utilización, asegúrese de que el FPGA no esté demasiado lleno
• análisis de ubicación, ruta y tiempo, asegúrese de que su diseño se ejecutará a la velocidad de reloj requerida

He hecho que varios diseños bastante complejos funcionen correctamente (o al menos en su mayoría correctamente) en la primera prueba en un FPGA real siguiendo lo anterior. No es necesario revisar el esquema de RTL, eso es extremadamente engorroso y una completa pérdida de tiempo para diseños grandes. Una simulación posterior a la síntesis sería mucho más útil.

Todo su código sintetizable debe expresarse como:

• LUTs
• Chanclas
• Primitivas específicas del proveedor

Las primitivas específicas del proveedor se crean de forma explícita, o se generan mediante el asistente del proveedor, o se deducen mediante patrones de codificación muy específicos, por lo que no debería haber ambigüedad alguna.

En VHDL, por ejemplo, no puede usar wait for en código sintetizable. Para entender por qué, intente expresar de manera determinista wait for 100 ns usando LUTs o flip-flops. Usted no puede

Eso no significa que no pueda implementarlo al configurar un contador con una frecuencia de reloj conocida (con un período que puede dividir 100 ns) y usar su conteo para saber cuándo se acaba el tiempo. Pero el motor de síntesis no creará este esquema automáticamente, debe ser explícito acerca de la arquitectura en términos de lógica combinacional (puertas / LUT) y registros.

Por lo tanto, lo más importante a tener en cuenta para generar código sintetizable es tener una imagen relativamente clara de cómo su código se convierte en puertas lógicas y chanclas. Eso es realmente.

El primer paso más obvio es verificar las advertencias.

Las herramientas Xilinx producen archivos de registro que advierten sobre cualquier cosa que podría no ser lo que pretendía el codificador. A veces esto es molesto, cuando tiene una gran cantidad de advertencias sobre señales no utilizadas que saben perfectamente que no se usan. Pero a veces atrapa errores genuinos. Si eres un novato, las posibilidades de ustedes cometiendo un error son significativamente mayores.

Entonces necesitas configurar restricciones de tiempo. ¿Qué tan rápido después de un flanco ascendente en el reloj A es necesario configurar la línea de datos B? O ¿por cuánto tiempo debe mantenerse la línea de datos B antes de que caiga un flanco en el reloj A? Las restricciones de tiempo le permitirán especificar todo esto. Si no tiene restricciones de tiempo, el compilador puede asumir que no le importa especialmente y que podría dirigir sus señales a cualquier lugar. Si tiene restricciones de tiempo, el compilador trabajará para asegurarse de que sus señales cumplan con esas restricciones moviendo la ubicación. Y si no puede cumplir con las restricciones de tiempo, pondrá una advertencia.

Si su problema es que las salidas no están haciendo lo que espera, mire en detalle los bloques de E / S. Cada pin de E / S tiene un poco de lógica asociada y un flip-flop. Es posible que el orden en el que especifique su lógica y las variables de estado en su código no permita que su código se ajuste a esta arquitectura, por lo que obtiene un retraso adicional de donde quiera que se coloque. Las advertencias sobre las restricciones de tiempo le indicarán si esto sucede (suponiendo que haya configurado sus restricciones de tiempo), pero para solucionarlo, debe comprender el hardware y cómo su diseño se asignará al hardware. En general, esto es solo un problema cuando empiezas a alcanzar altas velocidades de reloj, pero vale la pena mencionarlo.