u/FarLock9989

Horus-Geometry-Fabric
▲ 0 r/FPGA

Horus-Geometry-Fabric

Please have fun: https://github.com/sotiriosc/Horus-Geometry-Fabric

I’ve spent the last few months working on something I call the Horus-Geometry-Fabric. I’m a nobody just learning, and frankly, I started this project with a lot of wrong assumptions. If I’ve managed to accomplish anything useful, it’s a gift—and I’m here to explore, not to argue.

The Context I wanted to see if I could build a better AI hardware primitive. My initial hypothesis was that I could create a "fused" core that would morph between inference (fast/efficient) and gradient accumulation (precise/stable). I thought it would be the holy grail of efficiency.

The Reality Check The silicon told me otherwise. Through a rigorous series of "arenas"—my way of forcing the hardware to prove its own performance—I discovered that fusion is essentially a lie. Trying to force a monolithic datapath to do both jobs carries a massive 1.97× area penalty. It was expensive, bloated, and fundamentally inefficient.

The "Derived" Architecture I stopped trying to "design" my way into a solution and started "deriving" it from the physical constraints the synthesis tools were showing me.

  • Modularity is the tax: I found that splitting the cores wasn't just about logic—it was about amortizing costs. By refactoring the tile into a lean primitive (~3,188 µm²) and moving the heavy lifting (the normalizer and buffer) to the system level, I got the glue overhead down to 7.2%.
  • The Float vs. BlockFP debate: I tested everything. I instrumented the "flush" rates in block-floating-point designs, and the data was clear: the standard floating-point paradigm remains "load-bearing" for a reason. You can't beat the efficiency of a per-element exponent without paying a massive area tax elsewhere.

What this is The horus_tile is now a verified, scalable primitive. It’s a dual-core unit—E4M3 for inference and E3M6 for gradients—that actually works. It doesn’t try to be a giant brain; it’s a tiny, efficient piece of math logic that can be tiled across an entire fabric.

The Repository Everything is documented. Every failure, every FAIL verdict, and every measurement that led to the v2 specification is in the docs/ folder.

Closing Thoughts I’m sharing this because I learned a lot by being wrong, and I think the audit trail of these "wrong" turns might be more valuable than the final chip itself. This isn't a finished product; it’s an exploration. I’m just here to see how far the logic goes.

Wishing everyone the best.

u/FarLock9989 — 6 hours ago
▲ 0 r/FPGA

13-bit floating-point format for AI inference — per-value exponent instead of block-shared, C-model verified against FP64

I've been working on a custom 13-bit numeric format (Horus-NFE) aimed at

attention-layer inference, and just did a public release of the spec +

golden-reference C model. Posting here for feedback before I go further

with RTL.

The core idea: instead of a block-shared exponent (like MXFP4/MXFP6/MXFP8

under the OCP microscaling standard), each value gets its own exponent —

1 sign + 6-bit biased exponent + 6-bit fraction with implicit leading bit,

IEEE-754-style. Bias-32, range 2^-32 to 2^31.

The tradeoff this targets: MX formats amortize an 8-bit exponent across

a block of 32 values, which is efficient but means one outlier in a block

forces everything else to share its scale, crushing precision on the rest.

Per-value exponent avoids that entirely at the cost of ~5 more bits per

value.

C-model results (10M random ops vs FP64 reference):

- ADD/SUB: 0.00% error (lossless, power-of-2 shift)

- MUL: 0.54% mean, 1.49% max (theoretical bound 1.56%)

- Adversarial 32-element block (1 outlier at 10.0, 31 values near 0.001-0.023):

0.33% mean error vs ~8% for MXFP8 E4M3 on the same vector

RTL is still in development and not in this release — the repo currently

has the C model, format spec, and design rationale so the numbers can be

independently checked before I go further.

Repo: https://github.com/sotiriosc/Horus-NFE-Research

https://github.com/sotiriosc/Horus-NFE-Research/tree/main

License: CERN-OHL-S-2.0

Genuinely looking for pushback — particularly interested if anyone sees

a flaw in the outlier-block methodology or thinks the per-value-exponent

tradeoff doesn't hold up against real workload distributions rather than

random test vectors.

u/FarLock9989 — 4 days ago