¿Por qué design_vision compila mi sumador de acarreo anticipado en un sumador de acarreo continuo?

En mi escuela tenemos Synopsis "design_vision" en los laboratorios de computación. No sé cómo usar ninguna de las funciones, así que para mí es solo una herramienta de dibujo esquemático.

Por curiosidad, codifiqué a mano en Verilog un sumador de búsqueda anticipada de 8 bits y luego le pedí a design_vision que lo compilara. El resultado se parece mucho a un sumador de acarreo de ondulación.

Ahora, el sumador de transporte ondulado usa menos puertas, pero es mucho más profundo. ¿Por qué design_vision prefiere el ripple-carry?

Respuestas (2)

Si el sumador de acarreo ondulado tiene menos puertas y satisface las restricciones de tiempo, ¿por qué el sintetizador no debería preferirlo? En muchos casos, la forma más eficiente de generar una cadena de acarreo es usar una combinación de unidades de acarreo de ondulación y de anticipación. Por ejemplo, si uno está implementando un sumador de 32 bits con un presupuesto de tiempo de retardo de 16 puertas, representarlo como dos secciones de once bits y una sección de diez bits puede requerir menos puertas que el arreglo más rápido posible sin dejar de cumplir con el tiempo. requisitos

Sugeriría descubrir cómo jugar con las limitaciones de tiempo; Supongo que encontrará que, independientemente de si diseña en un sumador de acarreo de rizo o de acarreo anticipado, la combinación de acarreo de rizo y acarreo anticipado generada por el compilador variará con las restricciones especificadas. Si desea mantener un arreglo particular de lógica de transporte, puede decirle explícitamente al compilador que desea que se generen ciertas señales (dado que este es un diseño ficticio de todos modos, enrutarlas a pines de E/S podría ser una buena manera de hacerlo). Supongo que un compilador aún podría decidir ignorar las señales P y G incluso si se vio obligado a generarlas, pero con suerte sería lo suficientemente inteligente como para no hacerlo.

¿A qué tecnología te dirigías?

Si fuera un FPGA, el sintetizador podría haber sido tan inteligente que sabía que el acarreo de ondulación es más eficiente (en términos de recuento de LUT, y probablemente también de rendimiento) ya que la cadena de acarreo está allí de forma gratuita.