Computational Progress Is Not Metric Time: From Asynchronous Circuits to Causal Computation

This essay extends the research line developed in:

Those essays distinguish three ideas that are easy to collapse: ordered progression, system regime, and metric time.

The present article asks what happens if that distinction is taken seriously inside a machine we ourselves design.

The motivating question is simple:

That question immediately encounters a large existing field.

Clockless processors are not new. Asynchronous circuits are not new. Dataflow machines are not new. Logical clocks are not new. Petri nets, event structures, latency-insensitive design, event-driven hardware, and neuromorphic processors already address major parts of this territory.

The purpose of this essay is therefore not to claim invention of asynchronous computing.

Its narrower proposal is:

The distinction is conceptual first, architectural second, and potentially experimental third.

Most contemporary general-purpose processors are predominantly synchronous systems, although modern chips may contain multiple clock domains, asynchronous interfaces, and locally decoupled subsystems.

Within each synchronous domain, a clock coordinates when state is sampled and transferred. Registers capture values at clock edges. Combinational logic is given a bounded interval in which to settle. Setup time, hold time, propagation delay, pipeline stages, timing closure, frequency, latency, and throughput are all expressed through metric duration.

This architecture is extraordinarily successful.

Nothing in this article argues that synchronous digital design was a mistake.

The question is narrower.

Suppose two computational blocks perform different operations under different physical conditions.

One may stabilize quickly.

Another may require more time because of path length, data dependence, voltage, temperature, process variation, memory latency, or the intrinsic complexity of the operation.

A synchronous design still coordinates those blocks through a selected timing discipline.

That discipline is useful precisely because it creates a common metric framework.

But usefulness does not imply ontological identity between the framework and the computation itself.

The first conceptual separation is therefore:

An instruction may depend on another instruction because it requires its result.

That dependency is logical and causal.

The number of nanoseconds required to realize the dependency is a property of a particular physical implementation.

The two are related.

They are not the same thing.

For a non-specialist, the core intuition can be stated without circuit theory.

Different computational blocks naturally work at different speeds.

A multiplication, a cache lookup, a sensor event, a memory transfer, and a simple Boolean operation do not have a metaphysical reason to require equal physical durations.

The engineering question is therefore:

The synchronous answer is excellent engineering: because a shared timing discipline makes large systems tractable, predictable, verifiable, and manufacturable.

The present article does not dispute that answer.

It asks whether another abstraction can be made primary:

That shift sounds radical only until one looks at the history of computer science.

Much of it has already been explored.

Leslie Lamport’s 1978 paper Time, Clocks, and the Ordering of Events in a Distributed System is foundational because it separates event order from physical time.

Lamport begins from the problem that distributed processes cannot rely on a perfectly shared physical clock. He therefore defines the "happened-before" relation in terms of observable events and communication.

The resulting structure is a partial order.

If event (a) causally precedes event (b), then:

But two events may be concurrent without a physically meaningful total ordering between them.

The important lesson for this essay is not simply that logical clocks exist.

It is deeper:

Lamport did not propose System Tempo.

He did not claim that metric time is non-fundamental in physics.

His problem was distributed computation.

But the conceptual separation is directly relevant:

This is one of the strongest reasons the present proposal must not be presented as a discovery that computers can operate without a global notion of physical time.

Computer science has known that for decades.

A second mature line of work treats computation through events and causal relations.

Petri nets represent states and transitions without requiring every transition to belong to one universal sequential timeline.

Event structures, developed in the theory of concurrency, make the causal idea especially explicit.

An event structure can represent which events have occurred, which events depend on previous events, which events may occur concurrently, and where nondeterministic choice exists.

The computational structure is therefore not fundamentally:

but can instead be:

where (B) and © depend on (A), may progress independently, and both are required before (D).

The order is partial.

Metric durations can be attached later.

This distinction between causality and elapsed physical time is already formalized by well-established theory.

The present article therefore borrows its language of causal admissibility from a mature intellectual neighborhood rather than inventing it from scratch.

The Manchester Dataflow Machine gives a more architectural example.

Its prototype hardware was operational in the early 1980s.

Instead of treating program execution primarily as traversal of a conventional sequential instruction stream, the tagged-token dataflow model enabled instructions when their required operands became available.

In simplified form:

This is already remarkably close to the intuitive computer imagined in this essay.

An operation does not need to run because "the next clock slot belongs to it."

It runs because its dependencies are satisfied.

Again, the present proposal cannot claim novelty merely from replacing sequential scheduling with dependency-driven execution.

Dataflow computing has explored this territory extensively.

The interesting remaining question is how to formulate the distinction between dependency progression and metric duration explicitly enough to connect it with the broader System Tempo framework.

Asynchronous circuits remove the requirement for a global clock from the hardware itself.

Instead of assuming that every stage advances according to a common clock edge, neighboring stages can communicate through protocols such as request/acknowledge handshakes.

A simplified exchange is:

The physical circuit progresses when local conditions are satisfied.

The University of Manchester’s AMULET project is especially important because it demonstrated that this was not limited to toy controllers.

AMULET1 implemented the ARM architecture asynchronously, using a micropipeline-based design, and demonstrated substantial internal asynchronous concurrency in prototype silicon.

The later AMULET family showed that processors, caches, and systems-on-chip could be constructed without a conventional global processor clock and could perform competitively with synchronous designs in their intended domains.

This matters for two reasons.

First, a "clockless CPU" is already an engineering reality, not merely a philosophical possibility.

Second, the AMULET work observed behavior directly relevant to this article: throughput could depend on data and actual completion behavior rather than being described only by one fixed global cycle time.

That is close to the intuition that different parts of a computation can possess different natural completion rates.

But asynchronous hardware also exposes the cost of the idea.

Handshaking, completion detection, hazards, metastability management, verification, synthesis, testing, and tool support are difficult.

Synchronous design did not dominate merely because engineers failed to imagine alternatives.

It dominated because a shared clock is an extraordinarily powerful simplification.

Any new proposal must respect that engineering history.

Latency-insensitive design occupies an important middle position.

Carloni, McMillan, Saldanha, and Sangiovanni-Vincentelli developed methods in which synchronous systems can remain functionally correct even when communication latency between components varies.

The architecture remains synchronous.

The clock does not disappear.

But correctness becomes less tightly coupled to a particular wire delay.

This is conceptually useful because it separates two questions:

That separation anticipates one of the central distinctions of this essay:

The first concerns whether the right dependencies and transitions occurred.

The second concerns how long the physical realization took.

Modern neuromorphic systems provide a current engineering example of computation that is sparse, event-driven, and often asynchronous.

Intel’s Loihi 2 uses asynchronous event-based spiking computation in its neuromorphic cores.

The Speck chip, published in Nature Communications in 2024, goes further as an integrated asynchronous sensing-computing system.

Its event camera emits events when the visual scene changes.

The processing pipeline reacts to those events.

When there is no relevant input, large parts of the compute path need not continuously perform equivalent work.

This makes the architecture easy to explain without product language:

Speck is not a general-purpose replacement for a conventional CPU.

Loihi is not proof that every workload benefits from asynchronous operation.

Neuromorphic computing trades generality, numerical conventions, tooling maturity, programmability, and workload fit against advantages on particular sparse and event-driven problems.

But these systems demonstrate that event-driven physical computation is an active engineering direction, not a historical curiosity.

At this point the risk of rediscovery is obvious.

Almost every naive version of the idea already has an established neighbor:

The article becomes interesting only if it states a narrower problem.

That problem is the explicit separation of three computational coordinates.

The broader research program distinguishes:

For computation, introduce analogous notation.

Let:

denote a computational ordering or progress coordinate.

This is not a clock reading and not yet a universal measure of "how much computation" has occurred.

It labels advancement through a declared causal structure: which dependencies have been resolved, which transitions have completed, which records have become available, and which future transitions are now admissible. Any quantitative use of \Delta\lambda_C therefore requires an explicit progress definition for the workload or model being studied.

Let:

denote a candidate computational-regime coordinate.

It labels the operational regime in which the physical computing system currently exists: voltage domain, thermal state, available accelerators, memory regime, active topology, fault mode, precision regime, power budget, or another condition that changes the mapping between logical work and physical realization. As with the parent System Tempo notation, the coordinate is not identical to the regime itself.

Finally:

remains metric physical time.

It is represented by clock readings and durations such as seconds, nanoseconds, deadlines, response times, and intervals derived from physical or logical clocks.

The proposal is not:

It is that:

should remain conceptually distinct unless an explicit mapping among them is defined.

Consider two executions of the same dependency graph.

The program is:

Its causal graph can be represented as:

The exact drawing is not important.

The dependency structure is.

Now imagine two physical realizations.

Execution A:

Execution B:

The metric histories differ radically.

Yet the causal structure can remain the same.

The same prerequisites become satisfied.

The same dependency graph is realized.

The same final value can be produced.

Thus:

while the relevant computational progression may remain equivalent:

The equivalence symbol is intentional.

Two physical executions need not possess identical microscopic histories.

They need only realize the same declared computational equivalence relation.

This gives the central distinction:

A minimal causality-first execution model requires surprisingly few concepts.

Each computational node has prerequisites, a transition function, a completion condition, and an emitted result or record.

A node remains dormant until the results on which it causally depends are available.

When those dependencies are satisfied, the transition becomes admissible.

The physical implementation performs the transition.

When completion is detected, a stable result becomes available to downstream nodes.

The machine therefore progresses through a relation like:

There is no conceptual requirement for the phrase "one cycle later."

Metric time can still measure every stage.

It simply no longer supplies the primary semantic ordering.

This connects directly to From Irreversibility to Metric Time.

That essay proposed the conceptual sequence:

A causality-first computer makes a related engineering structure visible.

A downstream transition should not depend on an imagined abstract past.

It depends on a physically accessible result produced by a preceding transition.

In hardware that result may be stored as charge, voltage state, magnetic state, memory cell state, packet, token, handshake state, or another physical record.

This suggests a computational formulation:

This does not mean that all computation must be thermodynamically irreversible at every microstep.

Reversible computing remains a separate and important field.

The point is epistemic and architectural: later stages require accessible state correlated with earlier stages.

The machine, like the internal observer, advances through present-accessible records.

No.

This is one of the most important boundaries of the article.

Physical computers exist in physical environments.

Propagation delays matter.

Metastability matters.

Thermal relaxation matters.

Memory retention matters.

Deadlines matter.

Real-time control matters.

Users care whether an answer arrives in one millisecond or one hour.

A computer that produces the correct result after a century is semantically interesting and practically useless for most applications.

Therefore metric time remains indispensable.

The proposed demotion is narrower:

Or, more compactly:

Without an engineering consequence, the distinction could remain philosophical bookkeeping.

The practical motivation begins with a simple fact: computational blocks naturally operate at different physical rates.

A memory access, a local Boolean operation, a network transfer, a sensor event, an accelerator invocation, and a multiplication may require different durations.

A causality-first architecture can, in principle, allow each block to progress when its own completion conditions are satisfied rather than forcing the logical model to treat equal metric intervals as the primary organizer of every transition.

That can matter for energy, latency, sparse workloads, variable-delay systems, and heterogeneous machines, but none of those benefits should be promised universally.

Asynchronous logic carries overhead. Completion detection has a cost. Handshaking has a cost. Verification is harder. Toolchains are less mature. Some workloads map beautifully onto regular synchronous arrays and gain little from event-driven execution.

The meaningful claim is therefore conditional:

This is not a theorem of performance.

It is an engineering hypothesis that can be measured.

Clock frequency is one of the most familiar quantities in computing.

But frequency alone does not equal useful progress.

A 5 GHz processor does not perform five billion meaningful application-level state transitions per second.

Different instructions require different resources. Pipelines overlap work. Caches miss. Speculation succeeds or fails. Accelerators use different timing domains.

Modern processors already contain extensive mechanisms that make the relationship between clock count and useful work highly indirect.

A causal-progress model therefore invites another metric.

For example:

where (E) is energy consumed and (Delta\lambda_C) is a declared measure of useful computational progression.

This is not yet a universal benchmark.

The hard problem is defining \lambda_C without hiding arbitrary choices in it.

Possible measures include number of causally completed graph nodes, reduction in unresolved dependency count, depth advanced through a dependency graph, number of durable outputs produced, or application-defined progress toward a terminal state.

Each choice has limitations.

The point is not that one of them should replace FLOPS, instructions per cycle, latency, or energy-per-operation immediately.

The point is that metric time and useful causal progress need not be represented by the same variable.

A modern computing system may contain general-purpose CPU cores, GPUs, NPUs, storage controllers, network accelerators, sensors, DSPs, memory devices, programmable logic, and specialized AI accelerators.

These components already operate under different internal assumptions and often different clock domains.

Clock-domain crossing, buffering, synchronization, queueing, and protocol design exist precisely because one universal local rhythm is increasingly unrealistic across a complete machine.

A causality-first abstraction states the relationship more naturally:

Metric time remains relevant for a service-level requirement:

But functional dependency can remain:

This distinction may become increasingly valuable as computing hardware becomes more heterogeneous.

The connection to AI should be made carefully.

Today’s dominant AI accelerators are extremely successful precisely because dense numerical operations can be organized into highly regular massively parallel computation.

There is no reason to assume that causal hardware will replace matrix accelerators for those workloads.

But not all intelligent computation is naturally dense and uniform.

Reasoning systems, agents, robotic systems, event-driven perception, dynamic retrieval, tool use, and adaptive planning can produce dependency structures such as:

Only some branches need to progress.

Some branches die.

Others awaken after new evidence.

The structure resembles a dynamic causal graph more than a uniform sequence of identical operations.

This suggests a research question rather than a prediction:

Neuromorphic systems demonstrate one concrete version of event-driven activation.

They do not answer the broader question.

The first experiment should not be a fabricated processor.

That would make the hypothesis expensive before it becomes precise.

A better first step is a causality-first virtual machine.

The VM would deliberately omit a global instruction cycle from its semantics.

A program would compile into a directed dependency graph.

Each node would define its input dependencies, the transformation to apply, the rule by which completion becomes visible, and the output records it produces.

The runtime would execute any node whose prerequisites have become satisfied.

Metric time would be logged separately.

This allows two layers to be observed independently:

The experiment would then inject artificial delays.

The same program could be run repeatedly while giving different operations radically different durations.

If the model is correct, functional equivalence should survive those timing changes as long as causal and completion constraints remain satisfied.

That would demonstrate something modest but important:

This is already expected from established asynchronous and dataflow theory.

The value of the PoC would therefore not be to prove something unknown.

Its purpose would be to make the \lambda_C / q_C / \tau distinction executable and measurable.

The VM also creates a way to explore q_C.

Suppose the same causal program is executed at several values of the computational-regime coordinate q_C, corresponding to physical or simulated regimes such as high voltage / high performance, low voltage / low energy, thermal throttling, degraded memory latency, accelerator available, accelerator unavailable, high precision, approximate computation, or partial hardware failure.

These regimes can change the mapping:

A fixed amount of causal progress may require very different metric durations in different regimes.

Likewise, the energy cost may change.

This gives a computational analogue of a System Tempo question:

For ordinary computers the answer is obviously yes.

Thermal throttling alone demonstrates it.

But formalizing that fact is useful because it prevents the stronger philosophical hypothesis from hiding inside a trivial engineering observation.

A computer gives us a controlled system in which q_C, \lambda_C, and \tau can all be instrumented.

That makes it a useful conceptual laboratory.

If the software model is useful, the next step can be a small hardware prototype.

A practical target would be a tiny asynchronous or handshake-driven processor rather than an attempt at a modern CPU.

Possible scope includes a 4-bit or 8-bit datapath, a small register set, simple arithmetic and Boolean operations, request/acknowledge communication, completion detection, no global execution clock, and instrumentation for latency and energy.

A still cleaner design may avoid pretending to be a conventional instruction-set processor and implement a small dataflow engine directly.

Workcraft is relevant here because it supports Petri nets, Signal Transition Graphs, circuit models, verification, and synthesis of asynchronous control logic.

The research sequence could therefore be:

The hardware experiment would then compare at least two implementations of the same functional graph:

The comparison should measure actual behavior rather than ideology: correctness, latency, throughput, energy, idle behavior, sensitivity to variable delays, area or resource cost, control overhead, and verification complexity.

No result should be assumed in advance.

A trivial result would be:

That is already known.

A more interesting result would be:

An even stronger engineering result would be:

And the strongest conceptual result relevant to the broader research program would be:

That final result would still be an analogy.

It would not prove System Tempo as a physical theory.

A serious research proposal should say how it can fail.

The computational model becomes uninteresting if \lambda_C is merely a renamed instruction count, if q_C is merely a loose label for ordinary hardware state with no explanatory use, if all useful properties are already captured more cleanly by existing dataflow or asynchronous models, if the separation adds vocabulary without improving prediction or measurement, if the PoC demonstrates only known handshake behavior, or if practical overhead consistently dominates any benefit for the target workloads.

The broader analogy also fails if it is used rhetorically:

That inference would be invalid.

An engineered counterexample to clock-centric design does not establish new cosmology.

The computer is useful because it lets us sharpen concepts under controlled conditions, not because it can prove the ontology of the universe.

The argument can now be separated cleanly.

The most disciplined bridge back to System Tempo is methodological.

In a computer, we can observe all three layers.

We can know the causal graph.

We can manipulate hardware regime.

We can measure metric duration.

We can therefore ask:

at different values of q_C.

The answer can vary.

This does not establish that the universe possesses an analogous hidden coordinate.

But it gives a concrete example of why the following inference is not logically automatic:

Nor is the inverse automatic.

A local metric and a system’s meaningful progression can be tightly related without being conceptually identical.

That is the bridge.

The interesting computer is not one in which time disappears.

It is one in which the role of time becomes more precise.

Metric time remains necessary for physical engineering, deadlines, latency, energy analysis, communication, and user experience.

But computational causality can be defined separately.

The next event need not be meaningful because another equal metric interval elapsed.

It can be meaningful because the conditions that enable it became true.

That distinction is already present in asynchronous circuits, logical clocks, event structures, and dataflow systems.

The research opportunity is not to rediscover them.

It is to make the distinction explicit enough to connect three layers:

and then ask whether that separation yields a better model for irregular, event-driven, heterogeneous, or intelligent computation.

The practical intuition is simple:

The deeper question is whether our computational semantics should continue to treat one metric rhythm as primary when causality already provides another organizing structure.

A compact formulation is:

Or, more provocatively:

That is not yet a new computer architecture.

It is a research question precise enough to build.