The deeper path

Contracts before circuits.

Compute8 × INT8 MAC lanesProposed v0
AccumulationINT32Semantics implemented
Local storage≈ 52 KiBLogical target
ControlHost + serialized DMARISC-V deferred
01 / Direction

A small, inspectable v0.

The proposed first hardware path favors a complete, understandable detector flow over headline throughput: eight INT8 output-channel MAC lanes, INT32 accumulation, about 52 KiB of logical local storage, serialized DMA, and host control.

BoundaryHost or sensors
MovementDMA + external memory
LocalTensor SRAM
ExecutionTensor + utility operations
CONTROL

Host first

v0 keeps host control explicit. Integrated RISC-V control is deferred until a measured v0 justifies it.

MEMORY

Move explicitly

DMA and local SRAM behavior are part of the contract, not invisible implementation detail.

COMPUTE

INT8 first

INT8 activation and weight behavior with INT32 accumulation forms the first proposed hardware path.

DECISIONS

Bounded utilities

Vector, preprocessing, clamp, scale, requantization, and argmax-like operations are kept explicit.

Software proof / two blocks

The first two blocks now run in the simulator.

The reusable scheduler executes both complete Conv-SiLU blocks through 16,245 commands. Both retained tensors match all 614,400 golden INT8 values. See the two-block report.

Trace the commands →
02 / Contract

The machine has to mean something.

HASLAB separates mathematical intent, byte-level commands, implementation, and evidence. This prevents a future circuit bug from silently redefining correctness.

Implemented

Numerical semantics

Ties-to-even rounding, saturation, signed zero, NaN handling, overflow rejection, accumulation order, layouts, and activation behavior.

In progress

Command ABI 0.1

A proposed 128-byte command encoding with version rejection, invalid-field behavior, reset precedence, sequence handling, and structured errors.

Tested

Independent expectations

46 stored fixtures cover bytes, memory images, completion state, errors, provenance, hashes, and strict validation—without deriving expected values during execution.

03 / Precision

Every format has a role.

The project distinguishes software reference support from device-command support and future research. “Supported” never means the same thing at every layer.

HASLAB precision formats, intended roles, and current support
FormatIntended roleCurrent support
INT8Activations and weights for the first hardware pathGolden-model and command-simulator semantics implemented
INT32Exact accumulation, bias, optional raw logitsGolden-model and command-simulator semantics implemented
E4M3FN FP8First planned native FP8 modeReference behavior only; no v0 device command
E5M2 FP8Possible later formatConversion reference only
FP32Reference calculation and proposed FP8 accumulationSoftware reference use only
FP16 accumulationPossible constrained future modeNot selected or implemented
04 / First RTL gate

One thin slice, verified end to end.

The first RTL is intentionally narrow. It must consume reviewed commands and match the same independent vectors as the simulator before coverage expands.

  1. 01 / Control

    Command decoder

    Interpret the command fields and reject invalid instructions.

  2. 02 / Memory

    Local SRAM model

    Provide the local operands with explicit addressing and bounds.

  3. 03 / Compute

    One INT8 MAC path

    Multiply and accumulate signed 8-bit input and weight values.

  4. 04 / Accumulation

    INT32 accumulator

    Keep the running sum under the defined integer arithmetic rules.

  5. 05 / Conversion

    Requantization

    Scale, round, and clamp the result to the output representation.

  6. 06 / Report

    Completion + error

    Expose completion or an architectural fault for comparison.

Read 01 → 06. Colors identify functional roles; every stage is part of the planned RTL slice. Each must match the independent conformance expectations.

05 / Boundaries

What HASLAB is—and is not.

Clear boundaries make the project easier to evaluate, integrate, and extend.

Designed to become

  • A physical-AI inference building block
  • A reproducible research platform
  • An open FPGA-to-silicon path
  • An inspectable numerical and command contract
  • A home for compiler, memory, RTL, and verification research

Not intended to be

  • A training platform
  • A camera image-signal processor
  • A complete robotics stack
  • A safety-certified controller
  • A datacenter large-model accelerator
  • A finished or tapeout-ready chip today