The mechanism
An algorithm can be specified as a function over symbols, tensors or state transitions without saying how a device will store, move, time or verify those states. Realization begins when that specification is given a representation, an architecture, interfaces and measurable acceptance conditions. The same computation can be realized by different circuits and systems, each with different communication, energy, fault and manufacturing boundaries. This lesson makes the gap explicit so the later chip-design steps are understood as transformations of a contract rather than an unexplained jump from software to a finished die.
- State the computation independently of a particular chip implementation.
- Choose physical representations with defined noise, timing and energy margins.
- Carry those representations through architecture, design, manufacturing and operation.
- Measure whether each boundary preserves the required behavior.
- Feed failures back into the next design or deployment decision.
Science and assumptions
A realization contract
A physical-realization contract records five kinds of information: representation, interfaces, budgets, error model and verification evidence. Each must be instantiated for the chosen workload and physical boundary.
A useful contract records representation R, interfaces I, budgets B, error model E and verification evidence V. The tuple is a design scaffold, not a theorem that all systems share one format.
Assumptions The tuple is a conceptual decomposition; each element must be instantiated for a chosen workload and physical boundary.
Engineering example
Trace a matrix multiply from its graph operation to a tile schedule. The operation is unchanged, but layout, data type, memory traffic, arithmetic units, link budgets and acceptance tests become explicit at each boundary.
Distinctions and tradeoffs
A high-level algorithm is not a chip design; realization adds interfaces, budgets, implementation choices and evidence.
More detailed contracts reduce ambiguity but increase design and verification effort; an underspecified contract moves risk downstream.
AI systems are useful only when model operations survive the chain into memory, arithmetic, communication, power, cooling and evaluation.
Specifications and interfaces
- Boundary
- Abstract computation → physical state transitions
A teaching boundary; no single implementation is implied.
- Required invariants
- Meaning, timing, energy, error and interface scope
Each invariant needs a measurable definition before signoff.
Interfaces
- Computation intent Input
- Function, tensor graph, state transitions and quality target
- Realization contract Output
- Representations, interfaces, budgets and proof obligations
Check your understanding
What makes an abstract computation physically realizable?
- Naming a semiconductor process alone
- A chain of representations and verified interfaces that preserve its required behavior
- Increasing parameter count until a circuit appears
Answer and reasoning
A chain of representations and verified interfaces that preserve its required behavior
Realization is a chain of constrained transformations and checks, not a single process-node label.
Evidence and scope
This lesson presents the CRG framing as Semi AI Foundry research context and separates it from the independently sourced physical-computation literature.
Use the manufacturing investigation to trace compatible inputs, assembly and operating constraints; no current standalone calculator models this lesson’s full mechanism.