1.1. One generator, many elements🔗

Hardware projects have a way of accumulating processors: a main core for the application, a little helper core for booting, a vendor management core hiding in a corner — each with its own instruction set, its own bugs, and its own manual. Every extra ISA multiplies the work of understanding the system, and for us it would multiply something worse: the proof burden.

So Tilessa has exactly one processor definition. Every element on the chip — the workhorse tessera, the shrunken variant we tape out on hobby shuttles, the conductor that boots everything — is the same core generator instantiated with different feature flags, the way one template yields many concrete types. One ISA, one meaning, everywhere. This pays off twice: in hardware, there is a single design to verify; in software, programs running on the conductor obey the same mathematical description as the hardware they manage, so proofs about firmware and proofs about gates snap together instead of meeting at an awkward translation layer.

The second unusual decision: there is no privileged mode. In a conventional CPU, some instructions are reserved for the operating system, and a mode bit tracks whether you are currently allowed to use them — so a bug (or an attack) that flips the bit is catastrophic. Tilessa's privilege is physical instead. The conductor is "privileged" because it is the only element whose wiring reaches the control registers — the UART, the timer, the switches that start and stop the mesh. A tessera cannot escalate for the same reason a kitchen toaster cannot open a garage door: no wire goes there.

Here are the three configurations this book builds. Read tessera first; the other two differ only in the knobs.

1.2. The tessera ISA🔗

A tessera understands a deliberately small set of instructions: integer arithmetic and logic, a multiply-accumulate unit (the workhorse of all neural-network math), loads and stores to a small local scratchpad, send and recv for talking to the four neighbours, branches, and halt. That is the entire list — no operating-system instructions, no vector unit, and no floating-point unit inside the element.

The floating-point story deserves a sentence before the next section tells it in full: bulk math travels through the mesh in a block format that turns it into integer arithmetic, and the expensive functions (exponentials, reciprocals) live in shared units at the mesh edge. On the rare occasion element code needs to touch an individual float outside that fast path, it computes with integer instructions — the classic technique called soft-float, costing roughly fifteen instructions per multiply. The fp instructions below are a placeholder for a future variant that does carry the unit; in every configuration in this book they simply halt, the same as any instruction for hardware that is not there.

1.3. Arithmetic: block-float, MX-compliant🔗

Here is the problem this section solves. Neural-network math is almost entirely multiply-and-add, and doing it in ordinary floating point means every single addition pays for alignment and normalisation hardware — the shifters that line two numbers up before adding and line the result back up afterwards. When we measured our own designs, that bookkeeping — not the multipliers — dominated the silicon area. Giving every element in a mesh its own float hardware would spend most of the chip on it.

Block floating point (BFP) is the old, good trick that avoids the bill. Take a block of numbers — say thirty-two of them — and make them share one exponent, so each number keeps only its mantissa (its significant digits). Within the block everything is aligned by construction: multiply-accumulate becomes an integer multiply and an integer add. No shifters, no rounding logic, no float hardware in the elements at all. The exponent is handled exactly once per block, at the edge of the mesh where blocks are formed, instead of inside every element on every operation. Numerically the scheme behaves like fixed point within a block and floating point across blocks — and it is not exotic: it is the arithmetic pinned down by the industry's OCP MX standard formats, the ones the machine-learning world is converging on. Tilessa's math is MX math.

The numbers below make it concrete: hardware sums blocks eight at a time (a tree we measured at about one-and-a-half multipliers of area — cheap), four such sums make one 32-element MX block, and the running total lives in a 64-bit accumulator with room to spare. That "room to spare" is not a comment that might rot — it is a theorem the build checks: