Si el sumador de ripple carry contiene menos compuertas y cumple con las restricciones de tiempo, ¿por qué el sintetizador no lo prefiere? En muchos casos, la forma más eficiente de generar una cadena de transporte es utilizar una mezcla de unidades de acarreo por 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 compuertas, procesarlo como dos secciones de once bits y una sección de diez bits puede requerir menos compuertas que la disposición más rápida posible y al mismo tiempo cumplir con el tiempo requisitos.
Yo sugeriría descubrir cómo jugar con restricciones de tiempo; Supongo que lo encontrará independientemente de si diseña en un sumador de arrastre de ondulación o de arrastre de look-look, la combinación de acarreo de ripple y lookahead generada por el compilador variaría con las restricciones especificadas. Si desea mantener una disposición particular de la lógica de acarreo, puede decirle explícitamente al compilador que desea que se generen ciertas señales (ya que este es un diseño ficticio de todos modos, enrutarlos a los pines de E / S puede ser una buena manera de hacerlo). Supongo que un compilador podría decidir ignorar las señales P y G incluso si se vio obligado a generarlas, pero espero que sea lo suficientemente inteligente como para no hacer eso.