What ships before silicon

Talk is a design draft.
Shipped is the only fact.

Most "architectures" are decks. Mine is a file tree. Everything below is on my disk, opens today, and — where it runs — runs unattended in CI.

0
Core toolchain tools
assembler · runtime · debug · trace
0
Reference spec documents
one coherent plan
0+
Lines of specification
registers, buses, ISAs
0/15
CI test suites — green
ctest, on every push
Shipped · the reference toolchain

The architecture's software is real software.

These four tools ship with the project. They work today — and they are the exact test ground the silicon has to pass against when it exists.

new here? every name, one receipt →

bradc — the BradVector assembler SHIPPED

Parses my native assembly language (.basm), validates it, and emits portable bytecode (.bvbc). It rejects bad code with precise, line-level errors — behaviour the round-trip bytecode tests pin down.

proof: bradc-cli.c · bradc.c · round-trip bytecode tests · 10-insn saxpy confirmed

BVRT — the interpreter SHIPPED

A 32-lane SIMT virtual machine that executes .bvbc. In tests it runs a vector saxpy kernel across all 32 lanes and verifies every result — no result left unchecked.

proof: bvrt.c · BVRT saxpy ok (32 lanes) · BV_HALT status

bradgdb — the debugger SHIPPED

Attach, set a breakpoint by instruction, inspect registers and the program counter. A debugger for an ISA that hasn't seen a wafer yet. When the silicon arrives, this debugger has already been exercised for years.

proof: bradgdb.c · attach → break → step → halt flow tested

BradTimeline — the profiler SHIPPED

A cycle-level trace engine exporting execution timelines to CSV. Your performance toolchain arrives before the hardware — performance engineering is a design input here, so it ships first like everything else.

proof: bradtimeline.c · timeline.csv export · full instruction trace
Shipped · the graphics software

BradSense-Render. The part I could actually prove.

The GPU's reconstruction engine is the least provable claim in the whole spec — its hardware is designed, not fabbed. So the honest move was to ship the mathematics first and let the numbers argue. M0 is done, and it is in the same test suite as everything else on this page.

M0 — the spatial core SHIPPED

This is the receipt that matters: it used to not exist. bradsense_reconstruct() zero-filled its output buffer and booked performance stats on pixels it never computed. It now upscales the frame you hand it — bilinear and Catmull-Rom bicubic at arbitrary ratio off the quality-mode table, then a luma-adaptive sharpen with an anti-ringing clamp and a flat-region gate so it does not amplify noise. No frame supplied, no output: it returns -ENODATA rather than invent one.

src/drivers/bradsense.c · src/tests/test_bradsense_pixels.c · runs in ctest on every push

The numbers MEASURED

2× super-resolution PSNR against ground truth: 39.43 dB bilinear, 39.44 dB bicubic, 39.57 dB bicubic + sharpen. Asserted in the suite, not asserted here: corners map exactly, output is byte-deterministic, a flat field passes through untouched, a step edge crisps without mid-tone mush, and every pixel is inside the anti-ringing bound.

baselines re-checked on every push — if M0 regresses, the build goes red

M1–M4 — queued, not shipped THE ROAD AHEAD

M1 the temporal core: history buffer, motion-vector reprojection, responsive masks so disocclusions do not ghost. M2 the metrics harness that turns "it looks better" into a repeatable number. M3 expressing the temporal core as BradVector kernels — the first proof this ISA can carry the pipeline the Neuro-Stream units will eventually accelerate. M4 the trained per-object semantic experts. None of these are claimed as working. Frame generation is deliberately not on the ladder: it needs patent counsel first.

BRADSENSE_RENDERER_PLAN.md · BRADSENSE_RENDER_SPEC.md

Where the argument honestly is THE CLAIM

"We use AI to upscale" is the floor, not the differentiator — FSR 4, DLSS 4 and XeSS 2 are all machine-learned, and pretending otherwise would be the kind of lie this site does not tell. The claim worth making is the object-aware semantic pipeline: geometry and object identity feeding the reconstruction, not a filter applied to a finished frame. M0 is the baseline that claim gets measured against. The algorithm is FSR-3-derived but reimplemented from published behaviour — AMD's FidelityFX SDK is MIT — never cargo-copied, never branded FSR.

product stays Design/Sil in the company registry; only the software reference ships
Documented · the architecture

To the last register.

My silicon is designed — literature-grade, cross-referenced, internally consistent. A 1,733-line unified specification consolidates 78 reference documents into one book — the paper trail I keep honest.

The unified specification ON DISK

1,733 lines covering the whole ecosystem — chips, GPUs, memory, OS, software, console, roadmap — with honest Gen 1 / Gen 2 / Vision tagging throughout.

BRAD_DEVICES_COMPLETE_SPEC.md · 41-page PDF build

78 reference documents ON DISK

Every subsystem has its own deep-dive: BradVector ISA, GPU architecture, memory model, register maps, driver guides, OS design.

Design tree — silicon · software · devices

A naming language ON DISK

Die names carry meaning: discrete BGT100 (BradGfx), integrated BFT100 (BradFx), datacenter BAT100 (BradApex) — the generation in the number, the tier in the suffix.

Torox architecture §2 — die naming & G1 registry

Every claim carries a tag BY DESIGN

Shipped, designed, or vision — three tags, no invented benchmarks, no pretend silicon. A tag states exactly what the file can prove today.

gen1 / gen2 / vision tags across all 78 docs

Read the book that backs me up.

The full specification is open to read — every register, every risk, every tag I've written.