Si se trata de un diseño de "caja blanca", es decir, ya conoce el diseño de hardware (esquemas / netlist, o ecuaciones de diseño booleano), entonces puede comenzar por traducir el diseño de hardware directamente al lenguaje de descripción de hardware de Verilog o VHDL. (Ambos idiomas HDL son estándares de código abierto, y para la mayoría de los propósitos, cualquiera de los dos estará bien).
Si el hardware es un diseño de "caja negra", es decir, solo conoce su comportamiento externo y no sabe cómo se implementa, es más difícil porque debe crear un diseño de hardware equivalente en Verilog o VHDL.
En esta etapa, también construirá un dispositivo de prueba HDL para simular las interacciones aplicadas entre el software existente y el nuevo hardware de reemplazo. Además, tendrá que validar el dispositivo de prueba para asegurarse de que hace esencialmente las mismas cosas que hace el programa de controlador existente, de la misma manera, y también verificar que el dispositivo de prueba pueda detectar correctamente los resultados de falla de prueba.
De cualquier manera, el siguiente paso es ejecutar la simulación del código HDL para validar que la descripción del diseño puede funcionar en condiciones ideales. Si la simulación falla, definitivamente hay un problema con el diseño, pero si la simulación no falla, todavía podría haber problemas. El hardware real tiene retrasos de propagación que dependen del enrutamiento interno, y si su diseño tiene condiciones de carrera, puede encontrar que el diseño funciona en simulación pero no en el FPGA real.
Finalmente, después de validar el dispositivo de prueba y verificar los resultados de la simulación, comienza la síntesis y recorre todos los informes generados. Recomiendo encarecidamente la verificación del esquema RTL (lógica de transferencia de registros) para asegurarse de que las herramientas de síntesis sintetizan realmente todo el código HDL solicitado. No todo el código HDL se puede sintetizar en hardware FPGA, y estos pueden ser "fallas silenciosas" que no se muestran claramente a menos que lea con cuidado todos los informes generados por las herramientas de síntesis.
Si el sistema es muy sensible al cronometraje, también debe retroceder y ejecutar Simulación de síntesis posterior , que tiene en cuenta la ubicación física exacta en el chip de cada flip-flop y cada ruta retrasos de propagación, para producir una simulación más precisa de la sincronización del FPGA real. Si el diseño es robusto, esto debería dar los mismos resultados de simulación que la simulación ideal.
Use una placa FPGA COTS (comercial, lista para usar) para el desarrollo inicial. Esto le ahorrará una gran cantidad de tiempo y esfuerzo al intentar que su primera placa FPGA funcione. Hay suficientes cosas que pueden funcionar. mal al desarrollar la configuración de FPGA (flujo de bits), no debería preocuparse por si los reguladores LDO de su fuente de alimentación pueden suministrar suficiente corriente o si la derivación es suficiente, o si el paquete BGA de FPGA está soldado de manera confiable a la placa. He pasado por eso yo mismo ... Si fuera un cliente de gran volumen, ya estaría hablando con las ventas técnicas de Xilinx o Altera de todos modos, tal vez haga que diseñen su tablero ... Pero para nosotros, chiquillos, COTS Es la única manera práctica de ir.