¿Por qué los microcontroladores necesitan un reloj?

¿Por qué las instrucciones deben procesarse a intervalos de tiempo establecidos (es decir, con el uso de un reloj)? ¿No pueden ejecutarse secuencialmente, inmediatamente después de que se haya completado la instrucción anterior?

Una analogía para la necesidad de relojes en microcontroladores resultaría particularmente útil.

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

^{simular este circuito : esquema creado con CircuitLab}

Supongamos que tanto A como B son altos (1). La salida del AND es, por lo tanto, 1, y dado que ambas entradas al 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 al instante, pero la primera entrada todavía ve el 'rancio' 1 desde la puerta AND. Como resultado, la salida sube brevemente, pero solo hasta que la señal se propaga a través de la puerta AND, haciendo que ambas entradas al XOR estén bajas y haciendo que la salida vuelva a bajar.

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 a la longitud de los cables. .

Una manera realmente fácil de manejar eso es poner un flipflop activado por el borde en la salida de su lógica combinatoria, de esta manera:

^{simular este circuito}

Ahora, cualquier falla que ocurra está oculta del resto del circuito por el flipflop, que solo actualiza su estado cuando el reloj pasa de 0 a 1. Siempre que el intervalo entre los bordes ascendentes del reloj sea lo suficientemente largo como para que las señales se propaguen a través de las cadenas lógicas combinatorias, los resultados serán confiablemente deterministas y sin fallas.

Siento que muchas de estas respuestas no están exactamente en la pregunta central. El microcontrolador tiene un reloj simplemente porque ejecuta (y está controlado 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 presente 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 función de solo la entrada actual. 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 sincrónica es su simplicidad. Las puertas lógicas que realizan las operaciones en los datos requieren una cantidad de tiempo finita para responder a los cambios en sus entradas. Esto se llama retraso 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 asienten" a valores lógicos estables, antes de que ocurra el siguiente pulso de reloj. Siempre y cuando se cumpla esta condición (ignorando ciertos otros detalles), se garantiza que el circuito será estable y confiable. Esto determina la velocidad máxima de funcionamiento de un circuito síncrono.

Respuesta corta: los gerentes quieren una PRUEBA de función simple, comprobable antes de comprometerse con millones (o más) de dólares para un diseño. Las herramientas actuales, simplemente no dan diseños asincrónicos esas respuestas.

Las microcomputadoras y los microcontroladores suelen utilizar un esquema de sincronización para asegurar el control del tiempo. Todas las esquinas del proceso deben mantener el tiempo 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 suministra, la unidad 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) y qué tan rápido se está ejecutando ESE proceso --- ESTO pasa a través del fab). 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 de reloj hace que PROVING tenga en cuenta que la sincronización en todo el procesador funciona a través de las variables de voltaje, temperatura y procesamiento esperadas. 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, en mi experiencia, lo hace ) tomar entre 1/3 y 1/2 de la potencia utilizada en un microprocesador.

Entonces, ¿por qué no un diseño asincrónico? Existen pocas, si es que hay alguna, herramientas de cierre de sincronización para apoyar este estilo de diseño. Existen pocas, si es que hay alguna, herramientas automáticas de ubicación y ruta que puedan manejar y gestionar un gran diseño asíncrono. Por lo menos, los gerentes NO aprueban nada que no tenga una PRUEBA de funcionalidad directa, generada por computadora.

El comentario de que el diseño asincrónico requiere "una tonelada" de señales de sincronización, que requirió "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 más rápidos que sus contrapartes cronometradas. (Uno simplemente toma el ONE ruta de señal más lenta, y los usos que para alimentar de vuelta una señal de "listo" para la lógica anterior).

La lógica asincrónica es más rápida, porque nunca tiene que esperar un reloj que tuvo que extenderse para otro bloque en otro lugar. Esto es especialmente cierto en las funciones de registro a lógica a registro. La lógica asincrónica no tiene múltiples problemas de "configuración" y "retención", ya que solo las estructuras de sumidero (registros) finales 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 fronteras

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 un chip completo (o incluso en un sistema) está mucho más involucrado. Obtener el tiempo en papel es razonablemente directo para cualquier bloque o subsistema. Controlar esa sincronización en un lugar y sistema de ruta automatizados es mucho más difícil, porque las herramientas NO están configuradas para manejar el conjunto potencial mucho mayor de restricciones de sincronización.

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

Lograr un mecanismo de señal de "bloqueo" de "primero en llegar" es un problema de diseño de circuito, y hay formas conocidas de lidiar con eso. Las condiciones de carrera son un signo de 1). mala práctica de diseño; o 2). Señales externas que entran en el procesador. El cronometraje en realidad introduce una condición de carrera de señal contra reloj que se relaciona con violaciones de "configuración" y "retención".

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

(Espero que esto ayude).

Todo lo dicho, si tienes el dinero ...

Los microcontroladores necesitan usar un reloj porque deben ser capaces de 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á crítico que si alguno de los circuitos decide que X precedió Y, entonces todos deben hacerlo. Desafortunadamente, es difícil asegurarse de que los circuitos alcanzarán en un tiempo limitado un consenso garantizado sobre si X precede a Y, o incluso alcanzarán un consenso sobre si han alcanzado o no un consenso. La lógica síncrona puede ayudar enormemente con eso.

Agregar un reloj a un circuito permite garantizar que un subsistema no experimente 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 al 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 realmente muy pequeña. Desde una perspectiva práctica, a menos que uno esté tratando deliberadamente de causar un fracaso consensuado,

Ciertamente es posible diseñar sistemas completamente asíncronos que funcionen "lo más rápido posible", pero a menos que un sistema sea extremadamente simple, será difícil evitar que un diseño se vea afectado por 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 de manera mucho más rápida y fácil usando relojes de lo que sería el caso sin ellos. Aunque la lógica asincrónica a menudo podría 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 lograr que partes de un sistema lleguen a un consenso sobre si han alcanzado o no un consenso.. Un sistema que puede ejecutar consistentemente un millón de instrucciones por sección generalmente será más útil que uno que a veces puede ejecutar cuatro millones de instrucciones por segundo, pero podría detenerse durante milésimas de segundo (o más) a la vez debido a las condiciones de la 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 (D-FF) cronometrado, 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 de memoria básicos (D-FF) pegados con toneladas de puertas lógicas (estoy simplificando demasiado).

Ahora vamos al punto: ¿por qué las MCU usan D-FF en lugar de pestillos D como elementos de memoria internamente? Es esencialmente por fiabilidad 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 intencionales y carreras). Diseñar un circuito secuencial complejo utilizando bloques de construcción asíncronos es inherentemente más difícil y propenso a errores. Los circuitos síncronos evitan tales trampas al restringir el funcionamiento 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 sea realimentada a una entrada que no se haya adquirido por completo y arruine 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 asincrónica . Puede funcionar, y cuando lo hace, a menudo es más rápido y usa menos energía que la lógica síncrona (sincronizada). Desafortunadamente, la lógica asincrónica tiene algunos problemas que impiden que sea ampliamente utilizada. El principal que veo es que se necesitan muchos más transistores para implementar, ya que necesita un montón 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 necesiten relojes, ya que sus periféricos generalmente necesitan medir el tiempo. Los temporizadores y los 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 de reloj individualmente,

para ser más específicos, piense simplemente en acceder a una dirección desde 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 la instrucción en sí misma ocurre en pequeñas unidades de operación que requieren ciclos de reloj, estos combinados para ciclos de máquina , que explican varias propiedades de MCU como velocidad (FLOPS ** en MCU complicadas), revestimiento de tuberías, etc.

Respuesta a Comentario de OP

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

Como puede saber que las partes básicas de MCU son CPU, ALU y 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 instante de tiempo T1 y después la dirección es la matriz correspondiente de almacenamiento de condensadores (carga como señal) ( * mapeo de memoria * ) se activa y se selecciona.

Después de la selección, la señal ALE se activa, es decir, el pin ALE se hace 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 direcciones 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 oportunos

¿Qué sucedería si no usáramos el reloj? Entonces tendremos que usar el método de reloj asíncrono ASQC, esto haría que cada compuerta dependiera de la otra y podría ocasionar fallas en el hardware. hora de completar la tarea.
Entonces es algo indeseable

El problema fundamental que resuelve un reloj es que los transistores no son realmente dispositivos digitales: usan niveles de voltaje analógico 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 pasará 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 tranisistores que componen cada puerta lógica responderán en momentos ligeramente diferentes. El reloj se utiliza para "enganchar" las salidas de los dispositivos componentes una vez que se hayan 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 reafirmará la línea del Reloj para indicar que la línea de Salida de datos tiene un valor válido. El dispositivo esclavo tomará muestras de 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 muestrear la línea de entrada de datos? Podría probarlo antes de que el maestro establezca la línea o durante la transición entre estados. Los protocolos asincrónicos, 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 (generales).

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 rompecabezas (100 ojos azules) indicado en el enlace de arriba, y explicado con cierto detalle en esta pregunta en Maths Stack Exchange, el 'oráculo' actúa como el reloj para las personas en la isla.