LUT contra multiplicadores basados en IP dura en Spartan-3 FPGA para la multiplicación de coeficientes constantes

Según la hoja de datos el multiplicador duro tarda entre 4 y 5 ns en propagarse desde las entradas a salidas en modo combinacional. Perderá unos cuantos cientos de ps más al llegar al multiplicador y al resto de su lógica. Si eso es lo suficientemente rápido, entonces hazlo.

Si no, construya su multiplicador basado en LUT simplemente escribiendo un código con el operador * , sintetícelo, coloque y enrute y vea si es lo suficientemente rápido. Es posible que necesite un atributo para obligarlo a no usar los multiplicadores duros (consulte el atributo MULT_STYLE en el manual de 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: es una prueba muy rápida.

Solo si esos fallan, debes seguir el camino de la construcción a mano de una estructura basada en LUT, e incluso entonces solo si has visto la salida del sintetizador y estás bastante seguro de que puedes vencerlo por alguna razón. En mi experiencia, los sintetizadores se han sintonizado para calcular multiplicadores de coeficientes constantes, dudo que Coregen gane mucho.

Estimación del dedo mojado: un retraso de LUT es ~ 0.7ns. Suponiendo que los retrasos de enrutamiento son de una magnitud similar, puede permitirse una cadena de solo 3-4 LUT en el retraso del multiplicador duro. Me parece poco probable que logre lo que necesita con esa lógica tan profunda.

el multiplicador más fidedigno que puede usar es uno que realiza la cantidad de operaciones en tan solo unos ciclos de reloj como sea posible.

Normalmente, esto sería un ciclo de reloj.

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

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

No habiendo visto los dos multiplicadores diferentes, no puedo recomendar cuál es el más adecuado para su aplicación.

Si no está seguro de qué 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 una velocidad similar a la máxima (maximice el fMax), por lo general, debe usar los registros de entrada y salida ubicados en el segmento DSP. Esto significa agregar un registro de excedentes en ambos extremos de su operación en RTL y asegurarse de que la síntesis no elimine ningún bit (propagando constantes a través de él) o empujándolo de nuevo a la lógica de activación (es decir, el bloque de RAM ascendente hace que los bloqueos de salida se activen). 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 impulsar 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. Esperamos que utilicen el operador * en el interior, así que no den problemas en la simulación. Observe el manejo de la señal de reinicio asíncrono de los registros de tubería / 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 un registro externo inútil y las entradas del multiplicador puestas en bypass. Mirar el esquema de tecnología de su diseño ayudará a ver lo que tiene.

Más en general, 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 el DSP. El diseño canalizado aún produce un resultado por ciclo, y su fMAX será mayor como resultado de reducir la lógica en la ruta crítica, aumentando el rendimiento.