Contadores de ondas frente a síncronos: pros, contras y consumo de energía

Edición sustancial: tenga en cuenta que la respuesta de David Kessner se escribió en respuesta a la publicación original; ver el historial de edición 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 flip flops que comparten un reloj común. Las señales que se cruzan entre dominios de reloj casi siempre requieren sincronizadores dobles.

He visto una serie de artículos que sugieren que los diseños completamente asincrónicos son muy difíciles y propensos a tener dificultades imprevistas. Ciertamente puedo apreciar que si las entradas a cualquier tipo de elemento de enganche no tienen una relación de tiempo específica, es matemáticamente imposible garantizar absolutamente nada sobre la salida, y que incluso llegar al punto en que los comportamientos extraños son lo suficientemente improbables que, para fines prácticos , que no sucedan es a menudo difícil sin un doble sincronizador.

Varios blogs también hablan sobre los males de los relojes cerrados y sugieren que es mucho mejor enviar un reloj no cerrado a un pestillo junto con una señal de "habilitación de pestillo", que bloquear el reloj. Los relojes controlados no solo requieren un gran cuidado en su implementación para evitar pulsos de reloj "atrasados", sino que, a menos que se tenga mucho cuidado para equilibrar los retrasos, los circuitos operados desde relojes controlados por separado deben verse como si estuvieran en su propio dominio de reloj.

Lo que no he visto discutido mucho es la noción de circuitos que usan subsistemas secuenciales que no son todos activados por el mismo reloj, pero siempre serán estables dentro de una cierta duración de un borde de reloj. Si uno está tratando de implementar algo como un contador de eventos de N bits, tener muchos flip flops controlados 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 cambio, se utilizara un arreglo 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 preescalar asíncrona en la entrada de un contador, pero ninguno de los preescalares que he visto permite que el procesador los lea. Además, casi todos los chips que he visto que tienen tales preescalares hacen que sea imposible escribir en el valor del temporizador sin borrar el preescalar. Mi sospecha es que en muchos de estos dispositivos, el preescalar en realidad no sincroniza el contador principal, sino que se usa para determinar, en cualquier ciclo dado del reloj del sistema, si el contador debe avanzar o no. Si bien algunos de estos sistemas proporcionan un modo en el que uno de los contadores se puede configurar en modo "totalmente asíncrono", lo que permite el funcionamiento dentro del modo de suspensión,

Parecería 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 simplificarse mediante el uso de un diseño "semisincrónico" como se describe anteriormente. Es posible diseñar un contador de código gris de entrada en cuadratura bidireccional asíncrono relativamente compacto y rápido que tolere la metaestabilidad en cualquiera de las entradas siempre que la otra sea estable (durante el tiempo que una entrada es metaestable, una salida estará 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 apropiado). Las salidas no estarían sincronizadas con ningún reloj en particular, pero si las entradas cambian en un borde de reloj en particular, la relación con las salidas sería predecible. ¿Alguien ha oído hablar de un circuito de este tipo que se utiliza?

Estas son buenas preguntas, pero el formato stackexchange no las maneja bien. Creo que cuento unas 7 preguntas y, sinceramente, no están muy relacionadas.
@supercat, tengo que estar de acuerdo, ¿crees que podrías limitar esta pregunta a una pregunta más precisa y hacer cualquier otra pregunta que ya tengas con seguridad y hacer más preguntas como respuesta, traerlas adelante/darles raíz?
@Kortuk: Acabo de reescribir la cosa; No estoy seguro de si debo ajustar el título, ya que el enfoque está más en los circuitos de sincronización contra sincronización en general, en lugar de solo los contadores.
@W5VO: Intenté reenfocarlo un poco, aunque supongo que probablemente aún podría usar más recortes.
@supercat, gracias por tomarte el tiempo y los consejos.
@supercat: se lee mejor ahora, gracias. Definitivamente hay un buen punto de discusión allí, y el tipo de cosas que me interesan mucho (en cuanto a FPGA, pero me encantaría participar en el diseño de un ASIC algún día). FWIW Creo que un gran lugar para discutir esto sería en EDAboard en el foro ASIC o PLD, he recogido bastante allí. El boletín EE times PLD (por "Max the Magnificent") también es excelente. Ejemplo aquí
@Oli Glaser: Gracias. Una noción relacionada sobre la que me he preguntado son los pros y los contras de tener un elemento de bloqueo que, por ejemplo, muestrea en un flanco ascendente del reloj y da salida en un flanco descendente del reloj. Este enfoque es común con cosas como SPI, pero no conozco el uso de tales cosas dentro de los chips.

Respuestas (1)

Wow, tu pregunta no está muy enfocada y no es obvio lo que realmente estás pidiendo. Pero déjame darle una oportunidad a este. Lo siento si no lo entendí del todo bien.

Contador de ondas frente a contador síncrono normal: ¿ Quién dice que la gente no usa contadores de ondas? Las personas usan lo que tienen disponible que funciona mejor. En los FPGA, nadie usa un contador de ondas porque los bloques lógicos hacen un contador de sincronización mucho mejor que una ondulación. Pero si está diseñando un chip personalizado, un contador de ondas puede ser más ventajoso cuando se trata de consumo de energía y tamaño lógico. No me sorprendería en absoluto que algunas personas usen contadores de ondas en sus ASIC. Los contadores de sincronización aún serían mejores para la velocidad y la simplicidad del tiempo.

Contador gris frente a contador binario: la gente usa contadores grises en ASIC y chips personalizados. En los FPGA, donde los contadores binarios son más rápidos, la gente todavía usa contadores Gray cuando el valor de conteo tiene que atravesar dominios de reloj, como en FIFO.

Relojes multifásicos: estos ciertamente se utilizan en el diseño. Hay razones por las que los PLL en los FPGA a menudo pueden generar 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 vuelve más difícil debido a problemas de desviación y distribución de relojes. No es imposible a altas frecuencias, pero simplemente no se hace tanto.

Sync vs. Async: los circuitos de sincronización no solo son más fáciles de simular, sino también más fáciles de diseñar y más fáciles de garantizar que funcionen correctamente. Las herramientas de verificación y análisis de tiempo son difíciles o imposibles de usar con circuitos asíncronos.

Circuito contador de MCU: ¿SABES que no hay MCU que lo hagan de esa manera? Si lo hiciera, ¿cómo podría saberlo? Tal vez los preescaladores del temporizador sean contadores de ondas. Tal vez el temporizador en sí mismo sea un contador codificado en Gray y la lectura/escritura de los registros lo convierta automáticamente a/de binario. Mi punto es este: los muchachos que diseñan MCU de súper bajo consumo (como el MSP430) hacen todo lo posible para reducir el consumo de energía. Muchos de esos trucos, como el uso de contadores de ondas y el código Gray cuando corresponda, son completamente invisibles para las personas como usted y yo. Ellos pueden, y probablemente lo hagan, usar esos trucos más un par de cientos de otros trucos en los que aún no ha pensado. .

Una cosa que no ha mencionado es el uso de circuitos completamente asíncronos. Aquí es donde toda su charla sobre los relojes finalmente se lleva cuando se lleva a su conclusión lógica. Ha habido empresas que han intentado construir CPU a gran escala que sean completamente asíncronas, incluido un grupo que intentó llevar al mercado un ARM asíncrono. Los beneficios son sorprendentes: potencia súper baja, procesamiento más rápido y menos EMI entre ellos. Pero las desventajas son aún más asombrosas. La principal es que la complejidad de diseñar este chip es enorme y no es económicamente viable hoy en día. Un problema secundario es que la cantidad de transistores se duplica en comparación con un chip de sincronización equivalente.

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

+1 por un muy buen esfuerzo para responder una (múltiple) pregunta muy vaga y difícil.
El último punto primero: entiendo que los diseños totalmente asincrónicos deben evitarse cuando sea práctico, porque cada vez que uno tiene un circuito de enganche que combina señales con relaciones de tiempo desconocidas, es muy difícil garantizar el comportamiento . Supongo que mi principal interés son los circuitos en los que todas las señales cambian en respuesta a algo derivado de un borde de reloj, en lugar de ser cambiado directamente por el borde; un ejemplo de un circuito de este tipo sería un contador de código de grises de entrada en cuadratura asíncrono que es más simple que un contador de escala de grises totalmente síncrono.
@supercat Sí, la gente hace eso en ASIC y chips personalizados. Las cosas escritas en libros y artículos, y enseñadas en la escuela, a veces están muy lejos de lo que se hace en la realidad.
Sé que los relojes multifásicos eran muy comunes en los diseños más antiguos (un par que he estudiado en detalle son el MOS 6502, el Atari TIA, etc.) y continúan usándose en cosas como el PIC. Los artículos que había leído, sin embargo, parecen recomendar firmemente el uso de chanclas activadas por borde para todo, todas ejecutadas desde un reloj común.
Circuitos contadores de MPU: muchas CPU ofrecen preescalares asincrónicos para algunos de sus contadores, pero son limitados (consulte la edición anterior). Como ingeniero de sistemas integrados que sabe algo sobre los componentes internos de VLSI y tiene intuición de diseño, pero probablemente no lo suficiente como para conseguir un trabajo en el diseño de VLSI, me resulta frustrante que muchos chips gasten hardware en características que podrían emularse muy bien en el software. al menos si el hardware incluye algunas otras características que deberían ser más baratas de implementar. Uno de mis grandes deseos sería tener un sistema de tiempo "agnóstico del sueño", que podría...
@supercat Creo que el 95 % del hardware que existe no se diseñó pensando en el software. El viejo UART 16550 es un gran ejemplo de eso. Con algunos ajustes simples, podría haber hecho que SW fuera mucho más eficiente.
...fácilmente intervalos de tiempo de 1/65536 de segundo a horas o días sin tener en cuenta si está despierto o dormido. Mejor aún sería un contador respaldado por batería que podría mantener el tiempo durante años. Muy pocas CPU parecen capaces de permitir una reactivación precisa; Todavía tengo que ver un sistema de reloj respaldado por batería que permita tal precisión. No tengo muy claro por qué pocos subsistemas de reloj en tiempo real brindan una buena manera de leer con una resolución superior a un segundo, y algunos ni siquiera prometen que se puedan leer sin perder la cuenta.
De hecho, muchos diseños de hardware parecen haberse realizado sin consultar a los programadores. Soy bastante bueno solucionando las limitaciones en los diseños de hardware, pero eso no significa que me guste hacerlo. Me encantaría conversar sobre ese tema, pero se estaría desviando un poco del tema aquí.
Contadores de ondas frente a síncronos: pros, contras y consumo de energía
RespuestasAquíPolítica de privacidad1y, 2v