Implementación canalizada frente a baja latencia del cubo de un número en Verilog

Estaba estudiando sobre el diseño de FPGA y luego encontré estos términos Throughputy Latency. Entonces, el autor proporcionó un ejemplo de una implementación altamente segmentada para encontrar la raíz cúbica de un número:

ingrese la descripción de la imagen aquí

que aparentemente tiene el siguiente diagrama lógico:

ingrese la descripción de la imagen aquí

Luego, el autor ha intentado reducir la 'Latencia' escribiendo el código de esta manera:

ingrese la descripción de la imagen aquí

que se desenrolla así:

ingrese la descripción de la imagen aquí

Mi pregunta es para mí, ambas implementaciones parecen casi idénticas, entonces, ¿en qué se diferencian? Entiendo la asignación de bloqueo y no bloqueo, pero ¿cómo están causando un diagrama lógico diferente en este caso? ¿ Cómo está disminuyendo la latencydel circuito en el segundo caso?

Respuestas (1)

Lógicamente hablando, tienes razón, son idénticos. Sin embargo, la primera implementación está cronometrada (tenga en cuenta las @(posedge clk)sentencias always frente a las @*sentencias de la segunda), por lo que tiene una latencia mínima de tres ciclos que se determina a partir del período del reloj. La segunda implementación se calcula de forma completamente asincrónica, por lo que su latencia depende solo de la velocidad de su tecnología (qué tan rápido se resuelven las multiplicaciones y los retrasos en el enrutamiento).

Lo que ilustra este ejemplo es que muchas funciones digitales se pueden implementar de una manera muy canalizada o en una ruta lógica larga, o en algún punto intermedio. El que elijas puede depender de muchos factores. La primera implementación es menos eficiente en cuanto a recursos, ya que utiliza muchos registros adicionales para almacenar los valores canalizados de un ciclo a otro. El segundo es más eficiente en recursos , pero si lo coloca en un sistema síncrono que se ejecuta a una frecuencia de reloj alta , será más difícil cerrar el tiempo porque encaja mucha lógica en un ciclo.

En particular, ambas implementaciones tienen un rendimiento equivalente . Ambos pueden manejar un cálculo cada ciclo de reloj, solo que la primera implementación proporcionará la salida tres ciclos de reloj después de recibir las entradas correspondientes.

Entonces, ¿está diciendo que solo la alwaysdeclaración hace la diferencia? ¿Qué pasa con los registros? ¿Por qué no está allí en la segunda implementación?
Sí, todo se reduce a las declaraciones siempre. Esa es también la razón por la que ve declaraciones de no bloqueo en el primero (siempre se usa para asignaciones cronometradas) y bloqueo en el segundo. Solo ve registros en el primero porque son un dispositivo de "memoria", que se necesita en la implementación con reloj para almacenar valores de ciclo a ciclo, pero no es necesario en la implementación sin reloj.
Bueno... no sabía eso... también, ¿cómo calculó con precisión la latencia de 3 relojes... para mí, en la primera implementación, llegan los datos y después de eso, el siguiente flanco ascendente asignará todos los valores simultáneamente... estoy equivocado?... pero para la segunda implementación desde su serie, probablemente debería tomar 1 ciclo de reloj + 2 ciclos de multiplicación, supongo.
@DuttaA Puedo ver la latencia de los tres relojes de un vistazo al diagrama lógico, que muestra tres capas de registros. La segunda implementación no realiza ningún cronometraje, por lo que la latencia sería predominantemente el tiempo de las multiplicaciones, aunque en un circuito real también tendría retrasos debido al enrutamiento, los búferes, etc.
¿Qué pasa si no tenemos ese diagrama?
Puedes determinarlo a través del análisis. La clave es notar que las asignaciones ocurren en el posedge del reloj sin bloqueo. Luego, solo tiene que contar el número de asignaciones sincronizadas desde la entrada hasta la salida. En este caso X -> X1/XPower1 (1 ciclo), X1/Xpower1 -> X2/Xpower2 (2 ciclos) y X2/Xpower2 -> Xpower (3 ciclos). En este ejemplo de código, está organizado con bastante claridad para mostrar eso, pero no siempre es así.