FPU‑130 / numeric coprocessor

Introduction & Scope

FPU‑130 is a small numeric coprocessor intended to be fabricated as a digital design on a Tiny Tapeout Sky130 shuttle. It receives operands and a command from a host (the demo board's RP2040, or any SPI controller), performs one arithmetic or logic operation, and returns the result. The whole design must fit the severe area budget of a Tiny Tapeout tile while still supporting multiply and divide, so the architecture trades latency for area: complex operations are iterative and take multiple clock cycles rather than being fully combinational.

Goals

• Maximize useful arithmetic per gate. Reuse one add/subtract core across add, subtract, multiply, and divide instead of building separate units.
• Two host transports. A low‑pin‑count SPI command/data channel, plus a faster parallel byte port with valid/ready flow control for streaming ("burst") workloads.
• Integrity. Every frame on either transport carries a CRC so the host can detect corrupted commands or operands.
• Self‑contained. No external memory; one accumulator register lets results be chained without re‑sending an operand.

Scope of this document

This is an interface and micro‑architecture specification: it defines externally observable behavior (pins, protocols, instruction semantics, timing) and the internal block structure precisely enough to write RTL against. It does not include the Verilog source, the synthesis scripts, the physical floorplan, or the test‑bench code; those are downstream deliverables that must conform to this document.

Glossary

Key Design Decisions

Earlier revisions left several load‑bearing questions unanswered — most importantly what an operand actually is. These are the decisions now locked in; each is also explained where it is used.

Target Platform

FPU‑130 targets a Tiny Tapeout Sky130 shuttle, mounted on the TT demo board and exercised by the on‑board RP2040. Tiny Tapeout exposes a fixed, standard interface to every project; the design must use exactly those pins.

The 24 user pins divide into three groups of eight: ui_in (input‑only), uo_out (output‑only), and uio (bidirectional, each pin's direction set by the matching bit of uio_oe). A global clk, an active‑low rst_n, and a tile‑enable ena are also provided. The host RP2040 can drive all of these and can read uo_out back, which is exactly the channel FPU‑130 uses to return results.

Number Format

Every operand and result in FPU‑130 is a bfloat16 value: a 16‑bit floating‑point number with a 1‑bit sign, an 8‑bit exponent (bias 127, identical to fp32), and a 7‑bit mantissa with an implicit leading 1 for normal values. Because the fields match the top half of an IEEE‑754 fp32, a host produces a bf16 simply by truncating (or round‑to‑nearest‑even) the upper 16 bits of an fp32 — conversion is trivial and the dynamic range is the same as fp32 (~10^±38).

4.1 Field layout — two bytes

A bf16 value does not fit in one byte, so every operand and result crosses the 8‑bit interface as two bytes. The 8‑bit exponent straddles the byte boundary: 7 of its bits sit in the high byte alongside the sign, and its least‑significant bit sits in the low byte alongside the mantissa. Bytes travel high byte first to stay consistent with MSB‑first SPI.

What it costs in the datapath. bf16's significand is 8 bits (7 stored + the implicit 1), so MUL is a full 8×8 significand multiply and DIV an 8‑bit iterative divide — there is no small‑mantissa shortcut. The exponent path is 8 bits wide and the aligner/normalizer work on 8‑bit significands. All of this is still sequenced through the one shared add/sub core (§12), just wider and a few more cycles than a minifloat would need.

4.2 Why bfloat16

Top-Level Architecture

FPU‑130 is five blocks: two transport handlers (SPI and the parallel I/O port), a register file, the iterative datapath, and a control unit that sequences everything. The redrawn block diagram below tightens up the Rev 0.1 sketch and shows the actual signal grouping on the pins.

Pin Interface

FPU‑130 uses every group of the standard Tiny Tapeout interface. The dedicated input byte carries burst operands; the dedicated output byte carries results; the bidirectional bus carries SPI on its low nibble and the four flow‑control signals on its high nibble.

6.1 Complete pin map

SPI Interface

FPU‑130 is an SPI peripheral (slave). The host owns spi_sck and spi_cs_n. The link runs in Mode 0: clock idles low (CPOL=0) and data is sampled on the rising (leading) edge (CPHA=0). All frames are 8 bits, MSB‑first.

7.1 Frame structure

A transaction begins when the host pulls spi_cs_n low and clocks an instruction byte (its own CRC‑3 is validated first, which fixes how many bytes follow). When operand data travels over SPI (burst = 0), a control byte and the operand bytes follow, all covered by a single trailing CRC‑8. Each bf16 operand is two bytes (high byte first).

7.2 Reading the result over SPI

SPI is full‑duplex at the wire level: every byte the host clocks out on MOSI simultaneously clocks a byte in on MISO. While the FPU is busy it returns the status byte (§11) with BUSY=1, so the host polls; once BUSY clears, a read returns the two result bytes (high byte first). Each transaction's status byte echoes the control byte's TAG field for request/response correlation.

7.3 Clocking & oversampling

The core clocks at 40 MHz; SPI SCK runs at 10 MHz. FPU‑130 is an oversampled SPI peripheral: SCK is never used as a clock. The SPI inputs (spi_sck, spi_cs_n, spi_mosi) pass through 2‑flop synchronizers into the core domain; a one‑cycle edge‑detect pulse off the synchronized SCK enables MOSI sampling (rising edge) and MISO update (falling edge).

Parallel Full-Duplex Port

For streaming workloads, operands can be pushed in over the dedicated 8‑bit input bus and results pulled out over the dedicated 8‑bit output bus, each governed by an independent valid/ready handshake. This is the "burst" path (instruction bit 7 = 1). It is faster than SPI because a whole byte moves per clock instead of one bit per SCK edge.

8.1 Handshake rule

A byte transfers on the rising board‑clock edge where both valid and ready are high. Either side may assert its signal first; neither waits on the other to begin asserting. This is the standard AXI‑Stream‑style contract and is deadlock‑free as long as valid never waits for ready.

1. Receiver raises ready when it can accept a byte.
2. Sender raises valid and drives the byte onto the bus. (Steps 1–2 may occur in either order.)
3. On the first clock edge with valid & ready both high, the byte is transferred.
4. Each side deasserts its signal (or keeps it high to stream the next byte back‑to‑back).

8.2 Burst frame

A burst carries the same CRC‑protected payload as SPI, just moved over the parallel port one byte per handshake: control, then each bf16 operand as two bytes (high byte first), then the single CRC‑8 over the whole payload. Each operand therefore takes two in_valid/in_ready transfers. Results stream back over uo_out as two bytes (high first) with the FPU as sender (out_valid) and the host as receiver (out_ready); the status byte is available on the same path. The instruction byte and its CRC‑3 are always delivered over SPI first — burst only relocates the operand data.

Instruction Set

The 3‑bit opcode selects one of eight operations, completed with exact semantics, operand count, and result for the bfloat16 format of §4. Operands are a = op1 (or ACC in accumulate mode) and b = op2; rounding follows the RND field of the control byte (§11).

9.1 Control byte (host → FPU) & status byte (FPU → host)

Each transaction carries a host‑supplied control byte as the first byte of the CRC‑protected payload (§7.1), and the FPU returns a status byte on read‑back. The two are symmetric and share a 2‑bit TAG that the FPU echoes, letting the host match each result to its request in a pipelined or burst stream.

Control Modes

The two mode bits in the instruction frame are orthogonal and can be combined freely.

10.1 Burst (instruction bit 7)

burst = 0: operands and result travel over SPI (data frames on MOSI, read‑back on MISO). burst = 1: operands arrive over the parallel ui_in port and the result leaves over uo_out, each under valid/ready flow control (§8). The instruction frame itself is always delivered over SPI regardless of burst — burst only changes where the operand data flows.

10.2 Accumulate (instruction bit 6)

acc = 0: both operands come from the incoming frames. acc = 1: the first operand is taken from the ACC register (the previous result), and only op2 is supplied. This lets the host chain operations — e.g. a running sum — without re‑transmitting the accumulator each time.

CRC Definition

FPU‑130 uses two layered CRC scopes, both computed MSB‑first with a small LFSR. The instruction byte is protected on its own and validated first — that is what tells the receiver the payload length, so a single CRC over the rest is unambiguously placed.

The payload CRC‑8 spans the control byte plus (arity − acc) × 2 operand bytes — for a binary op that is the control byte and four operand bytes under one CRC, versus the two separate CRCs an earlier draft would have used. The LFSR is reset at the start of the payload, clocked through every payload byte, and checked once against the trailing byte. By CRC linearity an 8‑bit CRC over the whole block keeps the same ~1/256 random false‑accept and still catches errors that straddle the op1/op2 boundary; the only thing given up is per‑operand fault localization, which costs nothing because recovery resends the whole frame anyway.

On any mismatch the FPU sets the ERR status bit and drops the frame rather than computing on corrupt data; the host re‑sends. Both CRCs together are a few XOR gates and two short shift registers — negligible area for the integrity.

Datapath Micro-architecture

This is the only section that depends on the number‑format choice. The datapath is deliberately narrow and reused: one shared add/subtract core does the heavy lifting for every instruction, sequenced over several clocks by the control unit (Decision D2). For bfloat16 the core and the unpacked operands are 8‑bit significands (7 stored + the implicit 1) with an 8‑bit exponent path; MUL is a full 8×8 significand multiply and DIV an 8‑bit iterative divide, both shift‑sequenced through the one core.

12.1 How each op uses the core

Latency is variable, which is exactly why the FPU exposes a busy status: the host either polls the status byte or watches out_valid, rather than assuming a fixed delay.

Control Unit FSM

The Rev 0.1 state diagram was a dense, partly‑overlapping sketch. Redrawn as a single clean flow, the control unit is a straightforward request→decode→fetch→execute→writeback→return loop. The same FSM serves both transports; only the fetch and return states branch on the burst bit.

Worked Transactions

Two end‑to‑end examples make the protocol concrete.

14.1 SPI multiply, no accumulate (burst=0, acc=0)

1. Host pulls spi_cs_n low.
2. Host clocks the instruction byte: burst=0, acc=0, opcode=010 (MUL), CRC3.
3. FPU verifies CRC‑3, decodes MUL → payload = control + 4 operand bytes + CRC‑8.
4. Host clocks the payload: control · op1_hi · op1_lo · op2_hi · op2_lo · CRC8 (one CRC over all five data bytes).
5. FPU verifies CRC‑8, asserts BUSY, runs the multiply (≈6–8 cycles), writes the 16‑bit ACC, sets any NAN/OVF/INX flags.
6. Host polls: a read returns the status byte (BUSY=1) until done, then the two result bytes (high first); the status byte's TAG echoes the control byte's TAG.
7. Host raises spi_cs_n.

14.2 Burst accumulate‑add stream (burst=1, acc=1)

1. Host sends the instruction byte over SPI: burst=1, acc=1, opcode=000 (ADD), then the control byte (e.g. CLRA=1 on the first to zero ACC).
2. For each value: host drives ui_in + raises in_valid; FPU raises in_ready; the two operand bytes (high first) transfer, then the CRC‑8 byte; FPU checks CRC.
3. FPU computes ACC ← ACC + op2 per value (running bf16 sum), updating ACC in place.
4. To read the total, host raises out_ready; FPU raises out_valid and streams the two ACC bytes (high first) plus status.

Area & Gate Budget

A first‑order gate estimate (2‑input NAND equivalents, before place‑and‑route overhead). These are planning numbers, not synthesis results; routing and tap/antenna cells typically add 30–50%, which — with the bf16 datapath and 16‑bit registers — puts the design clearly into a 2‑tile budget.

Reset, Clocking & Power

• Clock. Single clock domain on the board clk at 40 MHz (25 ns). SPI signals are sampled into this domain through 2‑flop synchronizers at 4× oversampling (SCK = 10 MHz); the design never uses spi_sck as a true clock. This keeps the whole core synchronous and synthesis‑friendly.
• Reset. rst_n is active‑low and applied synchronously (the board clock free‑runs, so a sync reset is glitch‑immune and clean for STA/DFT). On reset: ACC = +0.0, A/B cleared, status cleared, all output enables driven to their idle values, FSM → IDLE.
• Enable. When ena is low the tile is not selected; outputs hold their reset/idle values.
• No floating outputs. Per Tiny Tapeout rules, every unused uo_out / uio_out / uio_oe bit is tied to a defined value (0). FPU‑130 uses all output pins, but any reserved bits default to 0.

Verification Plan

Tiny Tapeout supports cocotb test benches that can later be replayed against the real chip via the demo board. The plan:

Open Issues & Roadmap

Consolidated list of everything flagged above that needs your sign‑off before RTL starts:

Resolved since Rev 0.2: the format (D1 → bf16), the single operand‑region CRC (D4), the operating point and oversampling margin (was O3, now D6), and the exception/status reporting (was O1, now D7 + §9.1).

Suggested next steps

1. Confirm the D7 bit assignments (control/status bytes) and O2 (MISO drive) — these freeze the host‑facing interface.
2. Confirm O4 (burst stream framing) so the streaming case is unambiguous.
3. Write the cocotb bfloat16 reference model first (it doubles as the spec's executable check), then the RTL; close timing against the 40 MHz target.