VHDL: uso del operador '*' al implementar multiplicadores en el diseño

Los FPGA actuales han incorporado bloques DSP, los últimos FPGA incluso han incorporado unidades de punto flotante compatibles con IEEE-754.

Es posible crear una entidad / módulo DSP usando una GUI después de seleccionar los parámetros requeridos en él, y luego crear una instancia en el diseño.

¿Cuándo necesitamos hacer tal microgestión en un diseño de instauración de bloques DSP reales y cuándo simplemente ingresamos un operador '*' en el código y dejamos que la herramienta de síntesis maneje los detalles de bajo nivel? ¿Cual es mejor?

Hay muchos tipos diferentes de algoritmos de multiplicación cuando se trata de multiplicación binaria. Desde ahora hemos construido bloques DSP en silicio e incluso multiplicadores de coma flotante, ¿significa que todos esos algoritmos no han quedado obsoletos de manera efectiva?

Lo he hecho algunas veces yo mismo.

En general, las herramientas de diseño elegirán entre una implementación de estructura y un segmento DSP en función de la configuración de síntesis.

Por ejemplo, para Xilinx ISE, en la configuración del proceso de síntesis, Opciones HDL, hay una configuración "-use_dsp48" con las opciones: Auto, AutoMax, Sí, No. Como puede imaginar, esto controla qué tan duro intentan colocar las herramientas. DSP rodajas. Una vez tuve un problema en el que multipliqué un número entero por 3, lo que infirió un segmento DSP, excepto que ya estaba inferiendo manualmente cada segmento DSP en el chip, ¡así que el sintetizador falló! Cambié la configuración a No, porque ya estaba usando cada segmento de dsp.

Esta es probablemente una buena regla general (acabo de inventarlo): si su diseño tiene una frecuencia de reloj de menos de 50 MHz, y probablemente usará menos del 50% de los cortes DSP en el chip, entonces simplemente use el *, + y - operadores. Esto inferirá segmentos DSP sin registros de canalización. Esto realmente limita la velocidad máxima. (No tengo idea de lo que sucede cuando usas la división)

Sin embargo, si parece que va a ejecutar los cortes más cerca de la velocidad máxima del corte DSP (333 MHz para el grado de velocidad normal Spartan 6) Si va a usar todos los cortes, debe inferirlos manualmente .

En este caso, tienes dos opciones.

Opción 1: use manualmente la plantilla de instanciación DSP sin formato. Opción 2: use un bloque de IP de Xilinx Core Generator. (Usaría esta opción. Al mismo tiempo, aprenderá todo sobre core gen, lo que ayudará en el futuro)

Antes de hacer cualquiera de estos, lea las primeras páginas de la guía de usuario de DSP. En el caso del Spartan 6, (DSP48A1), ese sería Xilinx doc UG389: http://www.xilinx.com/support/documentation/user_guides/ug389.pdf

Considere primero la opción Core Generator. Por lo general, creo un proyecto de prueba en Core Generator para la parte con la que estoy trabajando, donde creo cualquier número de bloques de IP solo para aprender el sistema. Luego, cuando estoy listo para agregar uno a mi diseño en ISE, hago clic derecho en la Jerarquía de diseño, clic en nueva fuente y selecciono "IP (CORE Generator & Architecture Wizard)" para poder editar y regenerar el bloque directamente de mi proyecto

En Core gen, eche un vistazo a los diferentes bloques de IP que puede elegir: hay algunas docenas, la mayoría de las cuales son geniales.

El núcleo multiplicador es lo que debe mirar al principio. Echa un vistazo a cada página y haz clic en el botón de la hoja de datos. Las partes importantes son los anchos de bits enteros, las etapas de la tubería (latencia) y cualquier señal de control. Esto produce el bloqueo más simple posible al eliminar todos los puertos que no necesita.

Cuando construí un filtro IIR de orden 5 por 3 el año pasado, tuve que usar la plantilla de creación de instancias manual ya que estaba creando una implementación muy personalizada, con 2 cortes DSP con una velocidad 4 veces mayor que la frecuencia de muestreo. Fue un dolor total.

Si solo desea multiplicar dos números y se adaptan al bloque DSP, el *operador debe inferir un bloque DSP. Si no, devuelve la herramienta de síntesis :)

Sin embargo, para aprovechar las combinaciones más complejas de la funcionalidad DSP a menudo se requiere una instanciación directa del bloque y la configuración de sus parámetros. Ejemplos de cosas que pueden no mapearse bien por inferencia (usando el Xilinx DSP48E1 como ejemplo):

• Uso de pre-sumador
• Uso del acumulador posterior
• Uso del detector de patrones
• Uso de la unidad lógica.

Y especialmente combinaciones de lo anterior.

Las herramientas de síntesis aún no son lo suficientemente buenas como para mapear combinaciones completamente arbitrarias de lógica y aritmética tan eficientemente como podría esperarse.

Si hay bloques DSP presentes, debe usarlos si puede porque será más eficiente que usar LUT para hacer lo mismo. A menos que no necesite una multiplicación de alto rendimiento, en cuyo caso debe implementar, por ejemplo, un sumador canalizado y un registro de desplazamiento para ahorrar espacio.

Sin embargo, miraría inferir bloques DSP antes de entrar en las herramientas GUI. El manual Xilinx XST tiene 'recetas' HDL sobre cómo instanciar bloques DSP con puro verilog / VHDL. Básicamente, si agrega suficientes registros antes y / o después de los multiplicadores, XST usará un bloque DSP para implementar la operación automáticamente. Puede verificar los registros de síntesis para ver si está inferiendo los bloques DSP correctamente. Supongo que Altera tiene algo similar.

Por cierto, estaba reflexionando sobre esto hace unos minutos, ya que actualmente estoy trabajando en una implementación de Mersenne Twister que solo usa un multiplicador para la semilla inicial. La implementación de mi primer paso no cumple con el tiempo, pero la funcionalidad es correcta. XST también puso la operación de multiplicación en bloques DSP, sin embargo, no está optimizada, por lo que funciona aproximadamente la mitad de rápido que quisiera. Probablemente volveré a implementar la multiplicación utilizando una técnica de cambio y adición que tomará 32 veces la cantidad de ciclos de reloj, pero ya no requerirá un multiplicador de hardware.

Depende de la cantidad de optimización que necesite y de lo portátil que debe ser su diseño. Es un poco como el software, optimizando usando un poco de ensamblaje o dejando que el compilador elija las instrucciones. También puede tener algunas compensaciones de tamaño / velocidad para que no pueda permitirse un multiplicador combinatorio de doble precisión.

No sabía dónde había multiplicadores de FP cableados en FPGA.

Un operador de multiplicación real compatible con IEEE P754 adecuado para una CPU implica más que un multiplicador grande: debe agregar los exponentes, cambiar los valores normales, administrar infinitos y algunos indicadores en su mayoría inútiles (inexactos, flujo inferior ...)

Leí este documento http://www2.warwick.ac.uk/fac/sci/eng/staff/saf/papers/fpl2014-ronak.pdf :

Si bien las funciones que caben en un solo bloque DSP se pueden sintetizar de manera eficiente a partir de código RTL canalizado, hemos encontrado que las funciones más complejas que requieren múltiples bloques DSP adolecen de un rendimiento inferior. Sin embargo, una descripción RTL estándar de una función matemática se puede canalizar en gran medida, por ejemplo, después de cada operación, ya que esta canalización puede no tener en cuenta la estructura y las etapas internas del bloque DSP, el diseño sintetizado resultante puede mostrar un rendimiento inferior al estándar ya que Los bloques DSP se combinan de una manera que no les permite funcionar a toda velocidad.

Desearía poder encontrar la fuente de sus herramientas para verificar sus hallazgos.