2011-12-19 7 views
5

Soy consciente de la necesidad de sincronizar todas las entradas a un FPGA antes de usar esas entradas para evitar la metaestabilidad. También soy consciente de la necesidad de sincronizar señales que cruzan dominios de reloj dentro de un solo FPGA. Esta pregunta no se trata de cruzar dominios de reloj.¿Es necesario registrar las entradas y salidas de cada núcleo de hardware?

Mi pregunta es si es una buena idea para registrar de manera rutinaria todo de las entradas y salidas de todos los módulos de hardware interno en un diseño de FPGA. La razón es que queremos romper largas cadenas de lógica combinacional para mejorar la velocidad del reloj, de modo que podamos cumplir con las restricciones de tiempo para una frecuencia de reloj elegida. Esto agregará ciclos adicionales de latencia proporcionales a la cantidad de módulos que una señal debe cruzar. ¿Es esta una buena idea o una mala idea? ¿Debería uno registrar solo las entradas y no las salidas?

respuesta Resumen

Regla de oro: registrar todos los resultados de los núcleos de FPGA internos; no es necesario registrar entradas Si un resultado ya proviene de un registro, como el registro de estado de una máquina de estado, entonces no es necesario registrarse nuevamente.

Respuesta

5

Es difícil dar una regla dura y rápida. Realmente depende de muchos factores.

Podría:

  • Aumentar Fmax mediante la ruptura de caminos combinatorias
  • Hacer lugar y la ruta más fácil al permitir que las herramientas para separar la lógica en la parte
  • Hacer particionar su diseño más sencillo, lo que permite para reconstrucciones parciales

No resolverá mágicamente los problemas críticos de sincronización de ruta. Si hay una ruta crítica dentro de uno de sus principales "bloques", entonces seguirá siendo su camino crítico.

Además, puede encontrar más problemas, dependiendo de qué tan completo sea su diseño en la parte de destino.

Dicho esto, me inclino por el lado de registrar solo salidas.

+0

Hablé con alguien que también dio el mismo consejo de registrar salidas solamente. –

+0

Generalmente participo de los módulos de modo que las salidas de ruta de datos sean registros. Aunque esto ciertamente no es una regla. –

2

Registrar todas las entradas y salidas de cada módulo de hardware interno en un diseño FPGA es un poco exagerado. Si un registro de salida alimenta un registro de entrada sin lógica entre ellos, entonces 2x se consumen los registros requeridos. A menos que, por supuesto, estés haciendo equilibrio de ruta lógica.

El registro de entradas y no salidas de cada módulo de hardware interno en un diseño FPGA es un enfoque de diseño conservador. Si el diseño cumple con los requisitos de rendimiento y utilización de recursos, este es un enfoque válido.

Si el diseño no está cumpliendo con sus requisitos de rendimiento/utilización, entonces tiene que hacer el análisis de temporización adicional para reducir los registros en una ruta lógica dada dentro de la FPGA.

+0

¿Qué hay de registrar solo salidas y no entradas? –

+0

Siempre que se registren las entradas de los pines FPGA, entonces no importa registrar las salidas internas del módulo en lugar de las entradas internas del módulo. –

2

Mi pregunta es si es una buena idea registrar rutinariamente todas las entradas y salidas de cada módulo de hardware interno en un diseño FPGA.

No, no es una buena idea para rutinariamente introducir registros de este tipo.

  1. Hacer las entradas y salidas es redundante. No habrá lógica entre el registro de salida y el siguiente registro de entrada.
  2. Si mi bloque contiene una sola puerta AND, es excesivo. Depende del tiempo y la complejidad del diseño.
  3. Las etapas de registro deben pensarse y diseñarse correctamente. ¿Qué sucede cuando una salida FIFO llena u otras condiciones de pérdida? ¿Todas las señales tienen el retraso de registro correcto para que aparezcan en la etapa correcta en el ciclo correcto? Agregar registros no es necesariamente tan simple como parece.

La razón es que queremos romper las cadenas largas de lógica combinatoria con el fin de mejorar la velocidad de reloj para que podamos cumplir con las restricciones de tiempo para una frecuencia de reloj elegida. Esto agregará ciclos adicionales de latencia proporcionales a la cantidad de módulos que una señal debe cruzar. ¿Es esta una buena idea o una mala idea?

En este caso, parece que debe introducir registros, y no debe leer los puntos anteriores como "no hacerlo". Simplemente no lo hagas a ciegas. Piense en la lógica de control alrededor de los registros y la (ahora) naturaleza multiciclo de la lógica. Ahora está construyendo un "Oleoducto". Ser capaz de detener una tubería correctamente cuando la salida no puede escribir es una gran fuente de errores.

Piense en los coches que se mueven por una carretera. Si un auto aplica es frenos y paradas, todos los autos detrás también necesitan hacerlo. Si las luces de freno de los primeros automóviles no funcionan, el próximo automóvil no recibirá la señal para frenar y se bloqueará. De manera similar, cada etapa de una tubería necesita indicarle a la etapa anterior que se detiene por un momento.

Lo que puede encontrar es que en lugar de tener largas rutas de tiempo a lo largo de sus rutas de cálculo que van de entrada a salida, termina con largas rutas de tiempo en su permiso controlando todas estas etapas de registro de salida a entrada.

0

Otra opción que tiene es dejar que las herramientas le funcionen. Agregue agregue al final de su sistema completo un grupo de registros (si desea canalizar más) y actívelos en su herramienta de síntesis retiming. Esto moverá los registros (con suerte) entre la lógica donde es más útil.

Cuestiones relacionadas