The mechanism
A powered accelerator is not yet a usable participant in a computation. Its interface must be recognized, its required resources must be available, and a driver must complete the device-specific readiness contract. Firmware and boot software can establish initial device state, but a compatible interface string does not prove who produced an image or whether it is trustworthy. This lesson deliberately begins with an advertised teaching ABI and follows how that claim gates later actions. The process can already own and populate host buffers while the device remains unavailable. Rejected compatibility leaves those values intact and produces no DMA or numerical output. The distinction matters during bring-up: silicon, an installed driver, a discovered function and a running command are different milestones. The execution trace makes each gate inspectable while leaving firmware loading, secure boot, attestation and physical reset release outside its scope.
- The host process creates identified input and output buffers before it attempts a device job.
- The device handoff advertises matrix-int32-v1 or an incompatible version; the model does not execute firmware code.
- A recognized teaching device identity binds to a driver, and the register resource is claimed.
- The assumed DMA addressing capability and queue setup are accepted before publication.
- An incompatible ABI stops commissioning before any submission, device read or multiply-accumulate.
- A later acknowledged device reset clears readiness and requires the contract to be established again.
Science and assumptions
The declared ABI gate
ABI gate equals one only when the advertised and required interface identifiers match.
Symbols and units
- GABI
- Compatibility gate
Boolean
- adevice
- Advertised ABI identifier
string
- adriver
- Required ABI identifier
string
The model accepts one exact operation-interface identifier. Resource and queue gates remain separate after this comparison.
Assumptions A declared symbolic interface contract, not image authentication, feature probing or proof of correct device behavior.
Engineering example
Keep A=[[1,2],[3,4]] and B=[[5,6],[7,8]]. With a compatible handoff, the later job can publish [[19,22],[43,50]]. Select incompatible ABI: the trace still shows the process input values, but submitted attempts, DMA read bytes and executed MACs are all zero. It publishes no C. Restoring compatibility permits the remaining gates to run; it does not by itself establish memory visibility, correct mappings or a correct completion.
Distinctions and tradeoffs
Matching a device interface identifies a supported contract; it does not verify a firmware image or establish end-to-end correctness.
Adding interface versions can preserve compatibility only when negotiation and failure behavior are explicit. The current model chooses an exact single-version gate instead of emulating feature negotiation.
Accelerator bring-up joins physical hardware to supported execution. A model framework depends on this lower interface being usable before tensor work can run.
Specifications and interfaces
- Teaching ABI
- matrix-int32-v1
String equality is a compatibility test, not cryptographic verification.
- Scope of discovery
- One declared device/driver match
No actual PCI configuration transactions or operating-system enumeration.
- Readiness outcome
- Queue ready or commissioning blocked
Installed hardware is not counted as a completed job.
Interfaces
- Declared runtime inputs Input
- Stable matrix job, buffer identities and the stated device/visibility contract
- Inspectable accepted or rejected result Output
- Event trace, actual buffer values and bounded completion/work ledger
Check your understanding
An ABI mismatch leaves host buffers populated. Has the device computed their matrix product?
- Yes, because the driver is installed
- No: no job was submitted or operands consumed
- Yes, because populated memory implies DMA completion
Answer and reasoning
No: no job was submitted or operands consumed
Host allocation and initialization do not execute the device command.
Evidence and scope
Primary sources establish the cited runtime mechanisms. Numerical values, address ranges, ABI strings, event schedule and reset/retry epochs are authored teaching contracts. No real device, firmware image, operating-system driver, page table, cache protocol or security verification is executed.
The commissioning-execution-1 studio executes this bounded 2×2 matrix, buffer and completion contract. The surrounding atlas scene is conceptual; it is not a firmware emulator or system simulator.