Skip to main content
Contact Nelix Partner with Nelix
Inference accelerator

InferEdge

Inference as a bounded transaction, not a kernel call

AI inference accelerator for energy-bound sites. Each request is admitted against a joule budget and completes with proof or aborts explicitly.

RTL in progress Pre-silicon
Partner with Nelix Product roadmap
Interposer stack

Interposer stack

Bounded execution Inference
Bounded, energy-contracted edge inference A conceptual die floorplan for edge inference. Sensor data enters through an ingress block and a quantiser, then runs on a bounded array of compute tiles on a deterministic schedule. A completion state machine, drawn as a ring, admits work, runs it, holds it inside a bound and reports completion; results and a signed proof leave through separate export blocks. Beneath the datapath an energy contract rail fills to a hard stop bar and no further, with the remaining track drawn as an unused ghost. Edge inference domain Ingress Sensor Quantise INT8 / INT4 Npu tiles Bounded array Deterministic schedule Completion state machine Admit Run Bound Done Export Result Proof Signed Both or neither Energy contract Hard bound Never entered Admitted only if it fits One bounded execution
  • Inside the contract
  • Beyond the bound
  • Light stops at the bar
Inference at the edge is a contract: admitted only if it fits the energy budget, and it either completes with a proof or not at all.
InferEdge · architecture, design intent
ARCHITECTURE

Read the architecture

Each state is entered explicitly, failure is a defined transition rather than an absence, and what is drawn is specified rather than measured.

Sequence InferEdge
The enforced order of operations, 6 steps from first to last Sequence diagram with a trunk on the left edge. Steps in order: Admit; Execute; Checkpoint; Complete; Prove; Export. Gate ticks sit between steps; the last step is the only exit. Enforced order 01 Admit Input attested; energy contract accepted or refused 02 Execute Runs within agreed joule budget and clock profile 03 Checkpoint Progress committed at tile boundaries 04 Complete Result finalised; digest computed 05 Prove TrustCore binds digest to device, firmware, model 06 Export Result and attestation leave together, or not at all No step may be skipped The enforced order of operations, 6 steps from first to last Sequence diagram with a trunk on the left edge. Steps in order: Admit; Execute; Checkpoint; Complete; Prove; Export. Gate ticks sit between steps; the last step is the only exit. 01 Admit Input attested; energy contract accepted or refused 02 Execute Runs within agreed joule budget and clock profile 03 Checkpoint Progress committed at tile boundaries 04 Complete Result finalised; digest computed 05 Prove TrustCore binds digest to device, firmware, model 06 Export Result and attestation leave together, or not at all
  • Ordered step
  • Only exit
Every state is entered explicitly, and the gates between them are why the order holds.
While running Runtime verification
Continuous runtime verification A conceptual die floorplan for continuous measurement. An always-on measurement engine occupies the left of the die, with a four-phase cycle beneath it: sample, hash, extend, compare. To its right a recessive band shows workload activity in three lanes of uneven task footprints. A sample bus runs under the band and a comb of taps drops from it into a digest chain of linked cells, one per epoch, which the light extends from left to right. One epoch is flagged and re-measured. Beneath the chain the measured history stacks downward in rows that fade as they age, and the chain has no entry from its left end, so the record can only be extended and never rewound. Fresh evidence leaves through a port on the right edge. Operating die · power on Measure engine Always on Sampler Hash macro Every epoch not only at boot Sample Hash Extend Compare Workload activity L0 L1 L2 Sample bus Rolling digest E0 E1 E2 E3 E4 E5 E6 No rewind Re-measure Measured history E6 E5 E4 E3 Fresh quote Measurement continues for as long as the device runs
  • Measured epoch
  • Flagged for re-measure
  • Light = the digest being extended
Boot-time proof goes stale, so measurement continues while the device works and the evidence an operator asks for is always current.
Mechanism context · design intent
MECHANISMS

What holds, and why

  1. Energy contract admission

    Budget, model tier, clock, and checkpoint policy agreed before work starts

  2. Completion state machine

    Every request occupies an explicit state; failure is a defined transition

  3. Checkpointed recovery

    Restore validates integrity and contract before resume

  4. Proof-carrying output

    Result digest bound to authorised execution context

Memory-block silicon
Memory-block silicon
DESIGN TARGETS

Specification

Pre-silicon. Architecture specified; RTL in progress; FPGA next. Figures are design targets, not measured silicon results.

InferEdge design targets
Status RTL in progress
Power envelope Sub-15 W (design target)
Numeric formats INT8 / INT4 (design target)
Execution model Completion transaction under energy contract
Recovery Checkpoint and validated restore
Output Result plus attestation bundle
Validation route FPGA prototype before ASIC
Where it fits
  • Brownout-tolerant sites
  • Energy-constrained edge
  • Proof-carrying inference
  • Offline-capable execution
  • Narrowband telemetry sites
Engage

Talk to the design team

The specification is still open to review.

Partner with Nelix Product roadmap
RELATED