Multiplicadores basados ​​en LUT vs. IP dura en Spartan-3 FPGA para multiplicación de coeficiente constante

Antes de llegar a mi pregunta, aquí están las especificaciones de la placa y la herramienta de síntesis que estoy usando:

  • Familia: Spartan3
  • Dispositivo: XC3S200
  • Velocidad: -5
  • Herramienta de síntesis: XST

Mi multiplicador de 4 bits está en la ruta crítica de mi diseño. Me gustaría reducir el tiempo que toma la multiplicación para poder reducir mi ruta crítica y aumentar mi frecuencia de reloj.

Puedo usar CoreGEN para crear instancias de multiplicadores basados ​​en LUT, multiplicadores de coeficiente constante basados ​​en LUT, multiplicadores duros y multiplicadores de coeficiente constante duro (que creo que podrían ser multiplicadores duros con una entrada cableada).

Estoy pensando que si uso 15 multiplicadores de coeficiente constante basados ​​en LUT (o tal vez 11, puedo encargarme de los casos 2,4,8 con desplazamiento y 0,1 son triviales) que puedo dividir un poco esta ruta crítica. Mis restricciones de diseño me impiden canalizar estos multiplicadores; Necesito que se integren en mi ruta lógica combinacional.

¿Sería esto más rápido que simplemente usar un multiplicador duro? ¿O un multiplicador normal basado en LUT sería más rápido que cualquiera de las dos opciones?

Más información sería útil: ¿Qué tan rápido necesitas ser? ¿Qué dispositivo? ¿Qué grado de velocidad? ¿Qué sintetizador?
@MartinThompson: Se agregó la información adicional.
No creo que la multiplexación de la salida de 15 multiplicadores de coeficiente constante separados supere alguna vez a un solo segmento DSP duro, dado que desea una ruta combinatoria. Podríamos dimensionar esto mejor si nos diera una tasa objetivo de reloj.

Respuestas (3)

Según la hoja de datos, el multiplicador duro tarda entre 4 y 5 ns en propagarse de entradas a salidas en modo combinacional. Perderá algunos cientos más de ps yendo y viniendo del multiplicador al resto de su lógica. Si eso es lo suficientemente rápido, entonces utilícelo.

De lo contrario, cree su multiplicador basado en LUT simplemente escribiendo un código con el *operador, sintetícelo, colóquelo y dirija, y vea si eso es lo suficientemente rápido. Es posible que necesite un atributo para obligarlo a no usar los multiplicadores duros (consulte el MULT_STYLEatributo en el manual XST). Incluso podría intentar forzar un solo multiplicador basado en LUT (no constante) con esa restricción y ver cuál es el resultado; esa es una prueba muy rápida.

Solo si fallan, debe seguir la ruta de construir a mano una estructura basada en LUT, e incluso entonces solo si ha mirado la salida del sintetizador y está bastante seguro de que puede vencerlo por alguna razón. Según mi experiencia, los sintetizadores han sido ajustados para calcular multiplicadores de coeficiente constante muy bien; dudo que Coregen gane mucho.


Estimación de dedo húmedo: un retraso de LUT es de ~0,7 ns. Suponiendo que los retrasos de enrutamiento sean de una magnitud similar, puede permitirse una cadena de solo 3-4 LUT en el retraso del multiplicador duro. Me parece poco probable que logres lo que necesitas en esa profundidad de lógica.

Mi problema no es "lo suficientemente rápido" en este momento. Voy a por lo más rápido posible . Sin embargo, no he estado considerando construir a mano una estructura basada en LUT. CoreGEN se puede usar para construir explícitamente un multiplicador a partir de IP físicas o LUT. De forma predeterminada, XST (o alguna otra herramienta en la cadena ISE) instancia un multiplicador duro cuando encuentra el *en mi código. Sin embargo, estaba pensando que el esquema de multiplicadores de coeficiente constante basado en LUT podría tener una latencia más baja.

el multiplicador más rápido que puede usar es el que realiza la cantidad de operaciones en la menor cantidad de ciclos de reloj posible.

Por lo general, esto sería un ciclo de reloj.

Para lograr esto, generalmente tiene que usar más celdas lógicas. La compensación se reduce a espacio vs velocidad para este ejemplo.

No ha establecido ningún requisito de espacio, así que use cualquier multiplicador que logre el resultado en un ciclo de reloj.

Al no haber mirado los dos multiplicadores diferentes, no puedo aconsejar cuál es el más adecuado para su aplicación.

Si no está seguro de cuál es más rápido, escriba un banco de pruebas con los dos en paralelo y vea cuántos ciclos de reloj toma cada uno de ellos.

Si desea que los multiplicadores DSP duros funcionen a su máxima velocidad (maximice fMax), generalmente necesita usar registros de entrada y salida ubicados en el segmento DSP. Esto significa agregar un registro excedente en ambos extremos de su operación en RTL y asegurarse de que la síntesis no elimine ningún bit (al propagar constantes a través de él) o empujarlo nuevamente a la lógica de conducción (digamos que el bloque de RAM ascendente activa los pestillos de salida). Esto permite que el mapeo absorba el registro libre en el segmento DSP y le da al multiplicador el ciclo completo, eliminando los tiempos de enrutamiento de la señal.

Este tipo de optimización generalmente se requiere cuando intenta llevar fMax al máximo en las hojas de datos, en cuyo caso deberá seguir la guía de síntesis/DSP exactamente y usar las plantillas de creación de instancias. Esperemos que usen el *operador interno para que no den problemas en la simulación. Observe el manejo de la señal de restablecimiento asíncrono de los registros de canalización/entrada/salida, ya que no son tan versátiles en los registros de corte DSP como los cortes generales y pueden frustrar su intento, lo que resulta en el uso de un registro externo sin sentido y las entradas del multiplicador en derivación. Mirar el esquema de tecnología de su diseño le ayudará a ver lo que obtuvo.

En términos más generales, no está claro por qué canalizar el diseño no es una opción para usted. Normalmente, volvería a sincronizar el resto de sus rutas de señal para que coincidan con la canalización que ha permitido que se absorba en DSP. El diseño segmentado todavía produce un resultado por ciclo, y su fMAX será mayor como resultado de la reducción de la lógica en la ruta crítica, aumentando el rendimiento.