Un circuito como una unidad lógica aritmética tomará un par de números como entradas y producirá un número como salida. Puede garantizar que dentro de un cierto período de tiempo, todos los bits de la salida habrán alcanzado sus estados finales correctos, pero la cantidad real de tiempo para que los bits de salida se conviertan en válidos puede variar considerablemente según una variedad de factores.
Sería posible construir una ALU con una entrada "válida" y una salida "válida", y especificar que siempre que la entrada "válida" sea baja durante un período de tiempo suficiente antes de que se realice un cálculo, y los datos las entradas contienen los valores deseados antes de que la entrada "válida" sea alta, la salida "válida" no será alta hasta que los bits de salida sean correctos. Un diseño de este tipo probablemente requeriría aproximadamente el doble de circuitos que una ALU convencional [básicamente tendría que hacer un seguimiento de si cada bit era "conocido" como cero o "conocido" como uno; su salida "válida" se volvería verdadera una vez que se conociera el estado de cada bit de salida].
Para empeorar las cosas, permitir que aquellas partes de una CPU que serían capaces de ejecutarse más rápido para hacerlo, solo será útil si no están esperando todo el tiempo para que las partes más lentas puedan ponerse al día. Para que esto suceda, debe haber lógica para decidir qué parte de la máquina está "adelante" en un momento dado en el tiempo, y seleccionar un curso de acción basado en eso. Desafortunadamente, ese tipo de decisión es una de las más difíciles de hacer para la electrónica. Decidir de manera confiable cuál de los dos eventos que ocurrieron primero es generalmente fácil si se puede garantizar que nunca habrá "llamadas cerradas". Supongamos que un secuenciador de memoria está manejando una solicitud de la unidad de procesamiento # 1 y la unidad # 1 tiene otra solicitud pendiente después de eso. Si la unidad # 2 envía una solicitud antes de que se complete la primera solicitud de # 1, la unidad de memoria debe manejar eso; de lo contrario, debería manejar la siguiente solicitud de la unidad # 1. Eso parece un diseño razonable, pero termina siendo sorprendentemente problemático. El problema es que si hay algún momento en el tiempo tal que una solicitud recibida antes de ese momento se procesará de inmediato, y una solicitud recibida después de eso tendrá que esperar, la cantidad de tiempo requerido para determinar si una solicitud supera la fecha límite será aproximadamente inversamente proporcional a la diferencia entre el momento en que se recibió la solicitud y el plazo. El tiempo requerido para que la unidad de memoria determine que una solicitud de # 2 superó la fecha límite en un femptosegundo podría exceder sustancialmente la cantidad de tiempo que se habría requerido para atender una segunda solicitud de la unidad # 1, pero la unidad no puede atender cualquiera de las dos solicitudes hasta que decida a cuál de ellas dar servicio primero.
Tener todo funcionando en un reloj común no solo elimina la necesidad de que los circuitos determinen cuándo es válida la salida de un cálculo, también permite que se eliminen las "llamadas cerradas" de temporización. Si todo en el sistema funciona con un reloj de 100Mhz, no cambia la señal en respuesta a un reloj hasta 1 n después del límite del reloj, y todo lo que sucederá en respuesta a un borde del reloj ocurre dentro de las 7 ns, entonces todo lo que sucederá antes de un El borde del reloj en particular "ganará" al menos 3 ns, y todo lo que no sucederá hasta que después del borde del reloj se "pierda" al menos 1 ns. Determinar si una señal tiene posibilidades antes o después del reloj, cuando se garantiza que no estará "cerca", es mucho más fácil que determinar cuál de las dos señales temporizadas arbitrariamente ocurre primero.