Desarrollando para un FPGA usando Impulse C

¿Ya tienes el código c para la función? Si es así, puede tener algún sentido ...

Para responder a sus preguntas específicas (descargo de responsabilidad: no he usado Impulse C, pero tengo "leer el libro ")

No tiene que usar el impulso para todo el proyecto, escupe una lista de redes que puede usar como un bloque dentro de un sistema más grande.

"más o menos propenso a errores" es complicado. Espero que sea más fácil realizar la prueba en C que en VHDL, por lo que una buena cobertura también debería ser más fácil de obtener.

Aquí hay otro pensamiento:

Para una función compleja, la mayor parte del tiempo lo dedicas a escribir el código de verificación, así que elige un idioma que facilite que y luego interpórtalo con tu código sintetizable de bajo nivel.

Una opción para esto es MyHDL: todavía escribe la parte de FPGA en el nivel de "RTL de comportamiento", pero sus pruebas pueden aprovechar toda la infraestructura de Python. Entonces:

• Obtiene la administración de pruebas de forma gratuita; solo use uno de los marcos de prueba existentes
• Ya tienes una biblioteca aleatoria para generar datos de prueba
• Si está creando una implementación de un algoritmo estándar (por ejemplo, SHA), puede generar las respuestas esperadas para sus datos de entrada aleatorios utilizando un código de biblioteca (supuesto) bueno, en lugar de averiguarlo usted mismo (posiblemente en papel)
• Si desea utilizar imágenes o audio como datos de entrada, puede llamar a las bibliotecas para hacerlo.
• ¿Tratar con paquetes de Ethernet? hay una biblioteca para crear esos también
• ... etc!

Usar C como su idioma de entrada, tiende a significar que usar C (o C ++) como su idioma de prueba: se pueden obtener beneficios similares, pero no están "simplemente", hay que instalar y administrar varias bibliotecas. / p>     

Todas las herramientas C-to-RTL que he usado tienden a construir mini-CPU para cada unidad de compilación. Cada operación secuencial en el código C se asigna a estados secuenciales en la máquina de estado generada que se repiten en serie, lo que generalmente es un desperdicio de área y tiempo. Ahora puede ser que su FPGA sea tan grande, y sus limitaciones de rendimiento sean tan amplias que esto sea satisfactorio, incluso a gran escala. Pero en algún momento, es posible que su diseño no se ajuste al dispositivo, y tendrá montones de procesos secuenciales acoplados en lugar de un flujo de datos real para optimizar.

Si diseña para FPGA a partir de una formación en ingeniería de software, entonces tal vez no aprecie (aún) lo que un verdadero ingeniero de hardware puede hacer que un FPGA haga de manera concisa y con un rendimiento tan alto. Generalmente no usan C-to-gates para lograr esto.

Por supuesto, hay personas que sostienen la opinión opuesta, y el tema está recibiendo atención en DeepChip: 'Nosotros tengo 46 proyectos activos y rentables de C-to-Silicon recientemente para ser utilizados en el diseño comercial.

En términos de "propensos a errores" probablemente sean equivalentes. Es probable que sea menos fácil utilizar los visores de forma de onda para depurar la salida C-to-gates a medida que los nombres y funciones de los registros se confunden. Aunque si las herramientas funcionan, no debería necesitar trabajar a este nivel.