¿Por qué los microcontroladores necesitan un reloj?

Un ejemplo ilustrativo o dos pueden ayudar aquí. Echa un vistazo al siguiente circuito hipotético:

^{simular este circuito : esquema creado con CircuitLab}

Supongamos que para empezar tanto A como B son altos (1). Por lo tanto, la salida de AND es 1, y como ambas entradas de XOR son 1, la salida es 0.

Los elementos lógicos no cambian su estado instantáneamente: hay un retraso de propagación pequeño pero significativo a medida que se maneja el cambio en la entrada. Supongamos que B baja (0). El XOR ve el nuevo estado en su segunda entrada instantáneamente, pero la primera entrada todavía ve el 1 'obsoleto' de la puerta AND. Como resultado, la salida sube brevemente, pero solo hasta que la señal se propaga a través de la compuerta AND, lo que hace que ambas entradas al XOR sean bajas y que la salida vuelva a ser baja.

La falla no es una parte deseada de la operación del circuito, pero fallas como esa ocurrirán cada vez que haya una diferencia en la velocidad de propagación a través de diferentes partes del circuito, debido a la cantidad de lógica, o incluso solo a la longitud de los cables. .

Una forma realmente fácil de manejar eso es poner un flip-flop activado por borde en la salida de su lógica combinatoria, así:

^{simular este circuito}

Ahora, cualquier falla que ocurra está oculta del resto del circuito por el flip-flop, que solo actualiza su estado cuando el reloj pasa de 0 a 1. Siempre que el intervalo entre los flancos ascendentes del reloj sea lo suficientemente largo para que las señales se propaguen por todo el a través de las cadenas de lógica combinatoria, los resultados serán confiablemente deterministas y libres de fallas.

Siento que muchas de estas respuestas no están respondiendo exactamente a la pregunta central. El microcontrolador tiene un reloj simplemente porque ejecuta (y es impulsado por) lógica secuencial .

En la teoría de circuitos digitales, la lógica secuencial es un tipo de circuito lógico cuya salida depende no solo del valor actual de sus señales de entrada, sino también de la secuencia de entradas pasadas, el historial de entrada. Esto contrasta con la lógica combinacional, cuya salida es una función solo de la entrada presente. Es decir, la lógica secuencial tiene estado (memoria) mientras que la lógica combinacional no. O, en otras palabras, la lógica secuencial es lógica combinacional con memoria.

También:

La principal ventaja de la lógica síncrona es su simplicidad. Las puertas lógicas que realizan las operaciones en los datos requieren una cantidad finita de tiempo para responder a los cambios en sus entradas. Esto se llama retardo de propagación. El intervalo entre pulsos de reloj debe ser lo suficientemente largo para que todas las puertas lógicas tengan tiempo de responder a los cambios y sus salidas se "establezcan" en valores lógicos estables, antes de que ocurra el siguiente pulso de reloj. Siempre que se cumpla esta condición (ignorando otros detalles), se garantiza que el circuito será estable y confiable. Esto determina la velocidad máxima de operación de un circuito síncrono.

Respuesta corta: los gerentes quieren una PRUEBA de funcionamiento simple y comprobable antes de comprometerse con millones (o más) de dólares en un diseño. Las herramientas actuales, simplemente no le den esas respuestas a los diseños asincrónicos.

Las microcomputadoras y los microcontroladores suelen utilizar un esquema de reloj para asegurar el control de tiempo. Todas las esquinas del proceso deben mantener la sincronización en todos los efectos de voltaje, temperatura, proceso, etc. en las velocidades de propagación de la señal. No hay compuertas lógicas actuales que cambien instantáneamente: cada compuerta cambia según el voltaje que se le suministra, el accionamiento que recibe, la carga que maneja y el tamaño de los dispositivos que se utilizan para hacerlo (y, por supuesto, el nodo del proceso). (tamaño del dispositivo) en el que está hecho, y qué tan rápido se está ejecutando ESE proceso --- ESTE paso a través de la fábrica). Para llegar a la conmutación "instantánea", tendría que usar la lógica cuántica, y eso supone que los dispositivos cuánticos pueden cambiar instantáneamente; (No estoy seguro).

La lógica cronometrada DEMUESTRA que la temporización en todo el procesador funciona con el voltaje, la temperatura y las variables de procesamiento esperados. Hay muchas herramientas de software disponibles que ayudan a medir este tiempo, y el proceso neto se llama "cierre de tiempo". El reloj puede (y, según mi experiencia, lo hace ) tomar entre 1/3 y 1/2 de la energía utilizada en un microprocesador.

Entonces, ¿por qué no el diseño asíncrono? Hay pocas herramientas de cierre de tiempo, si es que hay alguna, para apoyar este estilo de diseño. Hay pocas herramientas automatizadas de lugar y ruta, si es que hay alguna, que puedan manejar y administrar un gran diseño asíncrono. Por lo menos, los gerentes NO aprueban nada que no tenga una PRUEBA de funcionalidad sencilla, generada por computadora.

El comentario de que el diseño asíncrono requiere "una tonelada de" señales de sincronización, lo que requiere "muchos más transistores", ignora los costos de enrutamiento y sincronización de un reloj global, y el costo de todos los flip-flops que requiere el sistema de reloj. Los diseños asincrónicos son (o deberían ser) más pequeños y rápidos que sus contrapartes sincronizadas. ( Uno simplemente toma la ruta de señal ÚNICA más lenta y la usa para retroalimentar una señal de "listo" a la lógica anterior).

La lógica asíncrona es más rápida, porque nunca tiene que esperar un reloj que tuvo que extenderse por otro bloque en otro lugar. Esto es especialmente cierto en funciones de registro a lógica a registro. La lógica asíncrona no tiene múltiples problemas de "configuración" y "retención", ya que solo las estructuras receptoras finales (registros) tienen esos problemas, a diferencia de un conjunto de lógica canalizada con flip-flops intercalados para espaciar los retrasos de propagación de la lógica al reloj. límites.

Se puede hacer? Ciertamente, incluso en un diseño de mil millones de transistores. ¿Es más difícil? Sí, pero solo porque PROBAR que funciona en todo un chip (o incluso en un sistema) es mucho más complicado. Obtener el tiempo en papel es razonablemente directo para cualquier bloque o subsistema. Obtener ese tiempo controlado en un lugar automatizado y un sistema de ruta es mucho más difícil, porque las herramientas NO están configuradas para manejar el conjunto potencial mucho más grande de restricciones de tiempo.

Los microcontroladores también tienen un conjunto potencialmente grande de otros bloques que interactúan con señales externas (relativamente) lentas, además de toda la complejidad de un microprocesador. Eso hace que el tiempo sea un poco más complicado, pero no mucho.

Lograr un mecanismo de señal de "bloqueo" de "primero en llegar" es un problema de diseño de circuito, y existen formas conocidas de abordarlo. Las condiciones de carrera son un signo de 1). mala práctica de diseño; o 2). señales externas que ingresan al procesador. El cronometraje en realidad introduce una condición de carrera de señal contra reloj que está relacionada con infracciones de "configuración" y "retención".

Yo, personalmente, no entiendo cómo un diseño asíncrono podría entrar en una condición de estancamiento o cualquier otra condición de carrera. Esa podría ser mi limitación, pero a menos que suceda cuando los datos ingresan al procesador, NUNCA debería ser posible en un sistema lógico bien diseñado, e incluso entonces, dado que puede suceder cuando ingresan las señales, usted diseña para manejarlo.

(Espero que esto ayude).

Dicho todo esto, si tienes el dinero...

Los microcontroladores necesitan usar un reloj porque necesitan poder responder a eventos que pueden ocurrir en cualquier momento, incluso casi simultáneamente con otros eventos externos o eventos generados por los propios controladores, y a menudo tendrán múltiples circuitos que necesitan saber si un evento X precede a otro evento Y. Puede que no importe si todos esos circuitos deciden que X precedió a Y, o todos esos circuitos deciden que X no precedió a Y, pero a menudo será fundamental que si alguno de los circuitos decide que X precedió a Y, Y, entonces todos deben hacerlo. Desafortunadamente, es difícil asegurar que los circuitos alcancen un consenso garantizado en cuanto a si X precede a Y, o incluso llegar a un consenso sobre si han alcanzado un consenso o no, dentro de un tiempo limitado. La lógica síncrona puede ayudar enormemente con eso.

Agregar un reloj a un circuito permite garantizar que un subsistema no experimentará ninguna condición de carrera a menos que una entrada al sistema cambie en una ventana muy pequeña en relación con el reloj, y también garantiza si la salida de un dispositivo se alimenta a otro. , la salida del primer dispositivo no cambiará en la ventana crítica del segundo dispositivo a menos que la entrada del primer dispositivo cambie dentro de una ventana crítica aún más pequeña. Agregar otro dispositivo antes de ese primer dispositivo garantizará que la entrada al primer dispositivo no cambie en esa pequeña ventana a menos que la entrada al nuevo dispositivo cambie dentro de una ventana muy, muy pequeña. Desde una perspectiva práctica, a menos que uno esté tratando deliberadamente de causar una falla en el consenso,

Ciertamente, es posible diseñar sistemas completamente asincrónicos que se ejecuten "lo más rápido posible", pero a menos que un sistema sea extremadamente simple, será difícil evitar que un diseño se tropiece debido a una condición de carrera. Si bien hay formas de resolver las condiciones de carrera sin necesidad de relojes, las condiciones de carrera a menudo se pueden resolver mucho más rápida y fácilmente usando relojes que sin ellos. Aunque la lógica asíncrona a menudo sería capaz de resolver las condiciones de carrera más rápido que la lógica cronometrada, las ocasiones en las que no puede hacerlo plantean un problema importante, especialmente dada la dificultad de que las partes de un sistema lleguen a un consenso sobre si han alcanzado o no el consenso .. Un sistema que pueda ejecutar un millón de instrucciones por sección de manera constante será generalmente más útil que uno que a veces puede ejecutar cuatro millones de instrucciones por segundo, pero que podría detenerse durante milsegundos (o más) a la vez debido a las condiciones de carrera.

Las MCU son solo un ejemplo muy complejo de un circuito lógico secuencial síncrono. La forma más simple es probablemente el D-flip-flop sincronizado (D-FF), es decir, un elemento de memoria síncrono de 1 bit.

Hay elementos de memoria que son asíncronos, por ejemplo, el D-latch, que es (en cierto sentido) el equivalente asíncrono del D-FF. Una MCU no es más que un montón de millones de elementos básicos de memoria (D-FF) pegados con toneladas de puertas lógicas (estoy simplificando demasiado).

Ahora vayamos al punto: ¿por qué las MCU usan D-FF en lugar de D-latches como elementos de memoria internamente? Es esencialmente por confiabilidad y facilidad de diseño: los pestillos D reaccionan tan pronto como cambian sus entradas y sus salidas se actualizan lo más rápido posible. Esto permite interacciones desagradables no deseadas entre diferentes partes de un circuito lógico (bucles de retroalimentación no deseados y carreras). Diseñar un circuito secuencial complejo utilizando bloques de construcción asincrónicos es inherentemente más difícil y propenso a errores. Los circuitos síncronos evitan tales trampas restringiendo la operación de los bloques de construcción a los instantes de tiempo cuando se detectan los bordes del reloj. Cuando llega el borde, un circuito lógico síncrono adquiere los datos en sus entradas, pero aún no actualiza sus salidas.. Tan pronto como se adquieren las entradas, las salidas se actualizan. Esto evita el riesgo de que una señal de salida se retroalimente a una entrada que no se haya adquirido por completo y estropee las cosas (dicho simplemente).

Esta estrategia de "desacoplar" la adquisición de datos de entrada de la actualización de salidas permite técnicas de diseño más simples, lo que se traduce en sistemas más complejos para un esfuerzo de diseño dado.

Lo que estás describiendo se llama lógica asíncrona . Puede funcionar, y cuando lo hace, a menudo es más rápido y usa menos energía que la lógica síncrona (con reloj). Desafortunadamente, la lógica asíncrona tiene algunos problemas que impiden su uso generalizado. El principal que veo es que se necesitan muchos más transistores para implementar, ya que necesita una tonelada de señales de sincronización independientes. (Los microcontroladores hacen mucho trabajo en paralelo, al igual que las CPU). Eso aumentará los costos. La falta de buenas herramientas de diseño es un gran obstáculo inicial.

Los microcontroladores probablemente siempre necesitarán relojes, ya que sus periféricos generalmente necesitan medir el tiempo. Los temporizadores y PWM funcionan a intervalos de tiempo fijos, las tasas de muestreo de ADC afectan su ancho de banda y los protocolos de comunicación asíncrona como CAN y USB necesitan relojes de referencia para la recuperación del reloj. Por lo general, queremos que las CPU funcionen lo más rápido posible, pero ese no es siempre el caso de otros sistemas digitales.

En realidad, está viendo la MCU como una unidad completa, pero la verdad es que está hecha de diferentes puertas y lógicas TTL y RTL, a menudo matriz FF, todas necesitan la señal del reloj individualmente.

Para ser más específicos, piense simplemente en acceder a una dirección de la memoria, esta simple tarea puede implicar múltiples operaciones, como hacer que el BUS esté disponible para las líneas de datos y las líneas de dirección.
La mejor manera de decirlo es que las instrucciones en sí mismas ocurren en pequeñas unidades de operación que requieren ciclos de reloj, estos combinados para ciclos de máquina , que representan varias propiedades de MCU como velocidad (FLOPS ** en MCU complicados), revestimiento de tuberías,

etc. Comentario de OP

Para ser muy preciso, les doy un ejemplo, hay un chip llamado ALE(Habilitación de pestillo de dirección) generalmente con el fin de multiplexar el bus de dirección inferior para transmitir tanto la dirección como los datos en los mismos pines, usamos osciladores (el Intel 8051 usa un oscilador local de 11.059 MHz como reloj) para obtener la dirección y luego los datos.

Como sabrá, las partes básicas de la MCU son la CPU, la ALU y el registro interno, etc., la CPU (que controla s/g) envía la dirección a todos los pines de dirección 16 en el caso de 8051, esto ocurre en el momento T1 y después. la dirección es la matriz correspondiente de almacenamiento de capacitores (carga como señal) ( *mapeo de memoria* ) está activado y seleccionado.

Después de la selección, la señal ALE se activa, es decir, el pin ALE se pone alto en el siguiente reloj, digamos T2 ( generalmente una señal alta pero cambia según el diseño de la unidad de procesamiento ), después de esto, los buses de dirección inferiores actúan como líneas de datos y los datos se escriben o leen. (dependiendo de la salida en el pin RD/WR de la MCU).
Puede ver claramente que todos los eventos son secuenciales a tiempo

¿Qué sucedería si no usamos el reloj? Entonces, tendremos que usar el método de reloj asincrónico ASQC. Esto haría que cada puerta dependiera de la otra y puede provocar fallas de hardware. tiempo para completar la tarea.
Entonces es algo indeseable.

El problema fundamental que resuelve un reloj es que los transistores no son realmente dispositivos digitales: utilizan niveles de tensión analógicos en las entradas para determinar la salida y tardan un tiempo finito en cambiar de estado. A menos que, como se mencionó en otra respuesta, ingrese a dispositivos cuánticos, habrá un período de tiempo en el que la entrada pasa de un estado a otro. El tiempo que lleva esto se ve afectado por la carga capacitiva, que será diferente de un dispositivo a otro. Esto significa que los diferentes transistores que componen cada puerta lógica responderán en momentos ligeramente diferentes. El reloj se utiliza para "bloquear" las salidas de los dispositivos componentes una vez que se han estabilizado.

Como analogía, considere la capa de transporte de comunicaciones SPI (Serial Peripheral Interface). Una implementación típica de esto utilizará tres líneas: Entrada de datos, Salida de datos y Reloj. Para enviar un byte sobre esta capa de transporte, el maestro configurará su línea de salida de datos y afirmará la línea de reloj para indicar que la línea de salida de datos tiene un valor válido. El dispositivo esclavo muestreará su línea de entrada de datos solo cuando se lo indique la señal del reloj. Si no hubiera señal de reloj, ¿cómo sabría el esclavo cuándo probar la línea de entrada de datos? Podría muestrearlo antes de que el maestro estableciera la línea o durante la transición entre estados. Los protocolos asíncronos, como CAN, RS485, RS422, RS232, etc. resuelven esto mediante el uso de un tiempo de muestreo predefinido, una tasa de bits fija y bits de trama (sobrecarga).

En otras palabras, se requiere algún tipo de conocimiento común para determinar cuándo todos los transistores en un conjunto de puertas han alcanzado su estado final y la instrucción está completa. En el acertijo (100 ojos azules) indicado en el enlace anterior, y explicado con cierto detalle en esta pregunta en Maths Stack Exchange, el 'oráculo' actúa como el reloj para la gente de la isla.