Contadores de ondulación frente a los sincrónicos: ventajas, desventajas y consumo de energía

Question

La respuesta de David Kessner fue escrita en respuesta a la publicación original; vea el historial de ediciones para ver a qué estaba respondiendo.

Por lo que he leído sobre diseño digital, hay una tendencia muy fuerte hacia el uso de circuitos estrictamente síncronos en los que los únicos subsistemas "secuenciales" son los flip flops que comparten un reloj común. Las señales que cruzan entre dominios de reloj casi siempre requieren dobles sincronizadores.

He visto varios artículos que sugieren que los diseños totalmente asíncronos son muy difíciles, y son propensos a tener trampas imprevistas. Ciertamente puedo apreciar que si las entradas a cualquier tipo de elemento de enclavamiento no tienen una relación de tiempo especificada, es matemáticamente imposible garantizar absolutamente nada sobre la salida, y que incluso conseguir las cosas hasta el punto en que los comportamientos Impares son lo suficientemente improbables como para que, a efectos prácticos, no sucedan es a menudo difícil sin un doble sincronizador.

Varios blogs también hablan de los males de los relojes con compuerta, y sugieren que es mucho mejor alimentar un reloj sin compuerta a un latch junto con una señal de "habilitación de latch", que compuerta el reloj. Los relojes con compuerta no sólo requieren un gran cuidado en su implementación para evitar pulsos de reloj "runt", sino que, a menos que se tenga un cuidado extremo para equilibrar los retrasos, los circuitos operados a partir de relojes con compuerta por separado deben considerarse como si estuvieran en su propio dominio de reloj.

Lo que no he visto discutir mucho es la noción de circuitos que utilizan subsistemas secuenciales que no son todos disparados por el mismo reloj, pero que siempre serán estables dentro de una cierta duración de un flanco de reloj. Si se trata de implementar algo como un contador de eventos de N bits, tener muchos flip flops todos accionados por un reloj común requerirá, como mínimo, cargar y descargar las puertas de 2N transistores con cada transición de reloj. Si en lugar de ello se utilizara una disposición de "ondulación" para las primeras etapas, se podría reducir sustancialmente la frecuencia de las señales que llegan a las etapas superiores, reduciendo así el consumo de corriente.

He visto algunos procesadores que cuentan con una etapa precalar asíncrona en la entrada de un contador, pero ninguno de los precalares que he visto permite que el procesador los lea. Además, casi todos los chips que he visto que tienen tales precalares hacen imposible escribir en el valor del contador sin borrar el precalar. Mi sospecha es que en muchos de estos dispositivos, el precalar no marca el contador principal, sino que se utiliza para determinar, en cualquier ciclo del reloj del sistema, si el contador debe avanzar o no. Mientras que algunos de estos sistemas proporcionan un modo en el que uno de los contadores puede ser puesto en modo "totalmente asíncrono", permitiendo la operación dentro del sueño, tiende a evitar ganar o perder cuentas si uno necesita usar los contadores para cualquier cosa que no sea un desbordamiento de período completo y hacer que cuenten consistentemente al cambiar entre la vigilia y el sueño.

Parece que algunos de estos problemas podrían aliviarse mediante el uso de un contador de código gris, y que la implementación de dicho contador podría facilitarse mediante el uso de un diseño "semisincrónico" como el descrito anteriormente. Es posible diseñar un contador graycode bidireccional de entrada en cuadratura, relativamente compacto y rápido, que tolere la metaestabilidad en cualquiera de las entradas mientras la otra sea estable (durante el tiempo en que una de las entradas sea metaestable, una de las salidas será indefinida; siempre que la entrada metaestable se estabilice antes de que la otra entrada tenga una transición, la salida se resolverá por sí misma al estado adecuado). Las salidas no serían sincrónicas a ningún reloj en particular, pero si las entradas cambian en un flanco de reloj concreto, la relación con las salidas sería predecible. ¿Alguien ha oído hablar de la utilización de un circuito de este tipo?

Answer 1

Vaya, tu pregunta no está muy enfocada, y no es obvio lo que realmente estás pidiendo. Pero déjame intentarlo. Lo siento si no lo he entendido bien.

Contador ondulante frente a contador síncrono normal: ¿Quién dice que la gente no usa contadores de ripple? La gente usa lo que tiene disponible y que funciona mejor. En las FPGAs, nadie usa un contador de ripple porque los bloques lógicos hacen un contador de sincronización mucho mejor que un ripple. Pero si estás diseñando un chip personalizado, un contador de rizado puede ser más ventajoso en lo que respecta al consumo de energía y al tamaño de la lógica. No me sorprendería en absoluto que algunas personas utilizaran contadores de rizado en sus ASIC. Los contadores de sincronización seguirían siendo mejores para la velocidad y la simplicidad de la sincronización.

Contador gris frente a contador binario: La gente utiliza contadores grises en los ASIC y en los chips personalizados. En las FPGAs, donde los contadores binarios son más rápidos, la gente sigue utilizando contadores grises cuando el valor de la cuenta tiene que ir a través de dominios de reloj, como en los FIFOs.

Relojes multifásicos: Sin duda, se utilizan en el diseño. Hay razones por las que los PLLs en las FPGAs a menudo pueden dar salida a versiones desfasadas de 0, 90, 180 y 270 grados de los relojes originales. Pero a medida que aumentan las frecuencias de reloj, el uso de múltiples relojes se hace más difícil debido a los problemas de desviación y distribución del reloj. No es imposible a altas frecuencias, pero no se hace tanto.

Sync vs. Async: Los circuitos de sincronización no sólo son más fáciles de simular, sino también de diseñar y de garantizar su correcto funcionamiento. Las herramientas de verificación y análisis de tiempo son difíciles o imposibles de utilizar con los circuitos asíncronos.

Circuito contador MCU: ¿Sabe que no hay MCUs que lo hagan así? Si así fuera, ¿cómo podrías saberlo? Tal vez los preescaladores del temporizador son contadores de ripple. Tal vez el propio temporizador es un contador de código gris y la lectura/escritura de los registros lo convierte automáticamente a/de binario. Lo que quiero decir es que los que diseñan MCUs de muy bajo consumo (como el MSP430) hacen todos los trucos posibles para reducir el consumo de energía. Muchos de esos trucos, como el uso de contadores de ripple y código Gray donde sea apropiado, son completamente invisibles para gente como tú y yo. Ellos pueden, y probablemente están, usando esos trucos más un par de cientos de otros trucos en los que tú no has pensado todavía.

Una cosa que no has mencionado es el uso de circuitos completamente asíncronos. Aquí es donde toda tu charla sobre los relojes termina cuando se lleva a su conclusión lógica. Ha habido empresas que han intentado construir CPUs a gran escala que son completamente asíncronas, incluyendo un grupo que intentó sacar al mercado un ARM asíncrono. Las ventajas son asombrosas: consumo superbajo, procesamiento más rápido y menos EMI, entre otras. Pero las desventajas son aún más sorprendentes. La principal es que la complejidad del diseño de este chip es enorme y no es económicamente viable hoy en día. Un problema secundario es que el número de transistores se duplica en comparación con un chip de sincronización equivalente.

Aun así, hoy en día hay CPUs en el mercado que utilizan la lógica asíncrona en algunos de sus bloques, como la FPU, pero nadie la utiliza a gran escala.