FireStorm — FPGA Pinout

Bank 2 — 0 free

Bank 3 — 0 free

Bank 4 — 0 free

Bank 5 — 0 free

Bank 6 — 0 free

Bank 7 — 0 free

Bank 10 — 0 free

I've put the JTAG pins on DeMon pins that can either bitbang/PIO JTAG or DeMon can act as a 4 pin SPI master (depending on the FPGA image) after programming

MIPI ESP32-P4

The MIPI D-PHY receiver for Pulse's feed into FireStorm — one of the FPGA's two RX hardcells. Pulse (the ESP32-P4 supervisor) streams its per-frame display-layer descriptions and audio chunk over this link, frame-locked to the system vsync; the hardcell is 4-lane capable but Pulse drives only the lanes it needs.

MIPI Cartridge port

The second MIPI D-PHY receiver, brought out to the cartridge port. It lets an active cartridge — a camera, a video/capture device, or a co-processor rendering its own layer — feed a stream into FireStorm exactly as Pulse does, composited as another display layer. All four lanes are exposed on the cartridge edge.

PCIe

The bulk data path to DeMon (the Raspberry Pi CM5): a PCIe link (x1 to the CM5) on the Q0 SerDes quad. It carries high-throughput transfers between DeMon and FireStorm, complementing the low-latency QSPI control channel. All four lanes and both reference-clock pairs are provisioned, though a single lane serves the CM5.

Display port -> HDMI

The main display output — a DisplayPort link on the Q1 SerDes quad, converted to HDMI for the primary monitor. This is FireStorm's finished video to the outside world; its hot-plug-detect and AUX sideband lines are in the Display port / PCIe support table below.

Analog

The GW5AST's on-die ADC differential input pairs (ADCTP/N, ADCVP/N) — low-rate analogue measurement (supply/temperature monitoring or general sensor input) without an external ADC chip.

Lists of i/o for above

hdmi to vga

Signal-level pin lists for the interfaces above and the remaining board connectors — each table gives the connector-side signal names and how they map to the FPGA, with notes.

The retro analogue video output. FireStorm drives an HDMI/LVDS-style TMDS signal set (RGB + sync) that an external converter turns into VGA/SCART, giving the machine its retro RGB output alongside the main DisplayPort→HDMI feed.

FPGA flash boot + HyperRAM 1 (shared MSPI master bus)

The FPGA's MSPI master bus, shared between the boot flash and HyperRAM 1. FireStorm loads its bitstream from the SPI flash here; HyperRAM 1 rides the same IO0–3/CCLK lines and only widens to x8 when its own HR1_CS is selected, so the two never collide. HR1 is fast working memory; its RESET# comes from DeMon expander PA2. (The fully separate HyperRAM 2 is a private bus — see below.)

I2S to WM8960/2

The I2S link to the onboard Cirrus WM8960/WM8962 codec — the standard audio DAC path that carries Tempest's stereo output off the FPGA (MCLK/BCLK/LRCLK/SDATA).

Audio expansion I2S (TI PCM3168A?)

The I2S link to the optional Studio I/O audio expansion (TI PCM3168A multichannel ADC/DAC) — the extra record/playback channels of the premium audio path, fitted as standard on the Ant64C and optional on the other models.

DDR3 (on prototype SDRAM?) connector

The DDR3-800 main-memory interface — the machine's primary DRAM (1.125–4.5 GB by model), a 72-bit bus of nine byte lanes — the ninth is real data in a full 72-bit word, or a debug/break tag lane in some FPGA configurations (as with the SRAM's 9th bit). The table lists the full connector: control/command (CS#, RAS/CAS/WE, ODT, CKE, RESET#), address, and data. It is single-rank for now — CS1/ODT1 are kept low and CK1 is unused — but the rank-1 control pins (CS1, ODT1, CKE1) stay under FPGA control rather than tied off, so dual-rank support could be added later purely in the controller configuration (and by populating the second rank), with no board change (the module's second clock pair CK1/CK1#, mapped in the table, carries the same clock as CK0/CK0# — usually driven from the same source, often just tied to CK0 — so dual-rank needs CK1 wired, not a second independent clock).

DIMM / SODIMM pin columns. Module pins are the JEDEC x72 ECC pinouts — 240-pin UDIMM (Micron MT18JSF…AZ) and 204-pin SODIMM (Micron MT18KSF…HZ). DQ0–63 map to the module DQ0–63, the ninth lane DQ64–71 to the module check-bit byte CB0–7, and DQS/DM follow their byte lane. The DQ-bit order within a byte lane is a free routing choice — any FPGA DQ may go to any module DQ pin of the same lane — so treat the per-bit rows as the identity default, not a fixed constraint. Rank-1 pins (CS1, ODT1, CKE1, CK1) are shown for the future dual-rank option.

SRAM

The wide-mode SRAM: two IS61LPS51236B synchronous SRAMs (512K×36 each) forming a 1M×36 space (~4.5 MB). This is the memory that makes wide mode possible — each 36-bit word carries four bits beyond a 32-bit instruction, which the EE uses as the Xwide register-extension nibble on fetch, and as a fast single-cycle scratchpad otherwise. Chip select: both chips share A0–A18, the 36-bit data bus and all timing/control; SRAM_CE (D20) enables both, and SRAM_BANK (D18) selects which one responds — chip 0 when 0, chip 1 when 1 — so the pair is addressed as one contiguous 1M×36 array with no external glue. (Full truth table in the Assignment summary.)

2x HDMI IN

The two HDMI receivers that bring DeMon's video into FireStorm. DeMon (the CM5) outputs its UI/display layers over HDMI rather than MIPI; FireStorm receives both streams here and composites them as layers, frame-locked to vsync like every other source.

Pulse OPI (master) to FPGA (slave)

The runtime control/data bus between Pulse and FireStorm — an octal-SPI (OPI) link with Pulse as master and the FPGA as slave, on the FPGA's SSPI slave/config pins. It runs x4 QPI during boot configuration and widens to x8 OPI at runtime, with a dedicated interrupt line back to Pulse.

Display port/PCie support

The low-speed sideband lines for the two SerDes interfaces above: DisplayPort hot-plug-detect and the AUX channel for the DP output, and PCIe_nRST for the DeMon PCIe link.

Sticky UART TX to FPGA

The direct controller-input UART. Sticky (the joypad controller) streams normalised controller state straight into FireStorm over this one line, so a running personality reads input at UART latency with no supervisor in the path. (Clicky's keyboard does not use this route — its keys reach a core via DeMon.)

HyperRAM 2 (allocated in bank 2)

The second HyperRAM — a fully private, independent HyperBus with its own clock and DQS, carrying no flash or configuration traffic (unlike HyperRAM 1, which shares the MSPI flash bus). It serves as fast working memory that can be reset independently; its RESET# comes from DeMon expander PA4.

Controller UART input streams

Sticky TX → FPGA K15 (STICKY_UART_TX). Clicky has no FPGA UART connection; its key stream goes to DeMon, which forwards events to FireStorm when needed. M15, L15 and J16 now carry restored header GPIO19, GPIO20 and GPIO16.

Assignment summary

SRAM bank selection and released pin

Two IS61LPS51236B chips share A0–A18, the 36-bit data bus and timing/control signals. FPGA D20 (SRAM_CE) drives both active-low /CE inputs. FPGA D18 (SRAM_BANK, formerly SRAM_CE2) selects the bank:

SRAM_BANK=0 selects chip 0; SRAM_BANK=1 selects chip 1, when enabled. No inverter is required. M17 (SRAM_CE_B) is released. Selection is synchronous: latch the bank during a valid address-load cycle and satisfy output-disable/read/write turnaround timing; changing the bank bit alone does not end a burst.

Spare-pin count

Counts below follow the bank tables after the ninth DDR3 byte lane was allocated. A spare is an unassigned general-purpose I/O ball. User-header signals and dedicated configuration functions are already allocated; unused SerDes, MIPI and ADC connections are not counted as GPIO spares.

The 312 listed balls include dedicated configuration functions; this is not a claim of 312 independently usable GPIOs. All I/O balls are now allocated. Bank 3's six former spares (M17, M15, L15, K16, M16, J16) and bank 4's two (K26, M19) carry restored header GPIO15–22; the three former beyond-Pi extras GPIO28–30 (G1/H3/G8) are renumbered GPIO23–25. No unassigned spares remain.

Signal → pin assignments are in each bank's Ant64 column above. Bank allocation and I/O standards:

DDR3 logical byte lanes

Logical lane n is DQ[8n+7:8n], DQM[n] and DQS[n]/DQS_N[n]. Logical lane numbers are independent of the FPGA's physical DQS-group numbers. The first eight lanes retain their data-ball assignments with corrected logical mask/strobe names. Lane 8 uses former GPIO15–25 in bank 5; all eleven pins belong to physical DQS group 11. Apply these names consistently in the schematic and controller constraints.

The 72-bit interface uses 11 existing GPIO allocations: DQ64–71 = U26, V26, W26, W25, Y26, V24, W24, Y25; DQM8 = AA25; DQS8/DQS_N8 = AB26/AC26. Disconnect these FPGA balls from the user-header translators; they now carry the DDR3 ninth lane. The GPIO15–25 header contacts are re-driven from reassigned balls in banks 3/4/7 — see the User I/O Header section. DDR_RESET_N remains on U25. Validate the nine-lane controller configuration and DQS11 routing in Gowin EDA before committing the schematic.

Key pin choices

HR1 RWDS / PUDC_B pull-up

Fit 1 kΩ from FPGA ball P15 (HR1_RWDS / PUDC_B) to bank-4 VCCIO (3.3 V). Place it close to the FPGA, with a short branch from the RWDS trace. This is a pull-up, not a series termination; do not tie RWDS directly to the supply.

The resistor holds PUDC_B high during configuration, selecting high-impedance GPIO behaviour rather than the configuration-wide weak pull-ups. Other signals that need a defined boot level, especially flash and HyperRAM chip selects, therefore require their own external bias. Keep HR1 deselected and verify that its RWDS output remains high-impedance throughout power-up and FPGA reconfiguration.

After configuration, reclaim P15 for the HyperRAM PHY; the resistor stays fitted. At 3.3 V it adds approximately 3.3 mA load when RWDS is driven low. Verify low-level voltage, drive capability and RWDS timing for both FPGA and HyperRAM drivers with this load. If the boot-state or runtime checks fail, revisit the shared-pin arrangement.

The nominal 1 kΩ value follows the configuration-bias guidance in Gowin UG984 §3.3. It does not resolve the separate HR1 DQS-routing validation.

• DDR3 — each SDRAM byte-lane's 8 DQ + DM + DQS± kept inside one FPGA DQS group (logical byte lanes 0–8 → physical DQS groups 1, 0, 3, 2, 5, 4, 7, 6, 11) so write-levelling stays legal; DRAM CK± on the SGCLK6 clock pair (Y22/Y23). Internal VREF (0.5·VCCIO = 0.75 V) — no VREF ball consumed.
• HyperRAM 2 — RWDS on DQS23 (F18), CLK on SGCLK1 (E17): a fully private HyperBus, independent of DDR3/SRAM.
• Pulse OPI (FPGA = slave) — runtime SSPI/OPI clock on R16 (SSPI_CLK; not a general-clock pin), SPI_DQS on DQS15 (T25). G20 is the codec/I²S MCLK connection.
• HDMI — TMDS differential pairs; pixel clocks on SGCLK5 / MGCLK5 / SGCLK4; on-die 100 Ω differential termination on the two receive links.
• SRAM clock on SGCLK0 (E20); WM8960 MCLK on G20. N21 is Pulse OPI data (D5).

HyperRAM 1 vs HyperRAM 2

• HyperRAM 1 rides the MSPI master bus (shared with the boot flash): x4 base IO0–3 on R14/R15/P14/N14, flash MCS_N P18, clock CCLK H13. It widens to x8 only when its own CS is selected, on four separate nearby pins — DQ4–7 = N16/P16/N22/L25 — with RWDS on P15 (DQS12) and HR1_CS on R23. It never touches the SSPI set.
• Pulse OPI = the SSPI slave bus (bank 4): CS L24 · CK R16 · D0–3 on N17/N18/R17/T24, widened to x8 at runtime with D4–7 on T23/N21/R18/L20, DQS T25, INT M20. At boot Pulse is the SSPI master and QPI-programs the FPGA (x4); post-config the same pins widen to Pulse's x8 OPI data. The bank-3 OPI was dropped and WM8960 I²S + Clicky/Sticky UART moved into the island (bank 3). Each SSPI pin needs a 4.7 kΩ pull-up to bank-4 VCCIO. Runtime OPI clock sits on the SSPI_CLK pin (not a GCLK) — DQS-based capture covers it, but confirm in timing.
• Boot-mode straps: MODE0/1 (bank-10 AB7/Y9) remain DeMon-expander outputs (PA0/PA5). MODE2 (W9) is permanently strapped low with a 10 kΩ resistor; it is not connected to the expander because MSPI boot (001) and SSPI programming (010) both require MODE2=0. After configuration, W9 is reused as VSYNC_OUT; the FPGA image must release the MODE2 input and enable the output only after configuration. HSYNC is removed and optical S/PDIF remains on bank 4 (K25); together with shared SRAM enable/bank selection this freed K16, M16 and M17 — all three now reassigned as restored header GPIO15, GPIO17 and GPIO18.
• HyperRAM 2 (assigned here, banks 2/3) is a private, independent HyperBus — no flash, no config traffic, own clock and DQS. RESET# from DeMon expander PA4 (HyperRAM 1 = PA2), each bank clearable independently.

Before fab — run in GoWin EDA for DRC

• Set VCCIO per the table (2/3/4 = 3.3 V, 5/6/7 = 1.5 V); confirm DQS-group completeness and internal VREF on 5/6/7.
• HDMI-in is the open electrical item: confirm the GW5AST-138 takes TMDS33 input directly on the 3.3 V bank, or whether the two DeMon links need AC-coupling + re-bias.
• MSPI bus pull-ups (from the GW5A config-pin spec): MI2/WP (P14) and MI3/clock-lock (N14) gate MSPI validity — WP must read high for MSPI to be valid, and clock-lock is active-low with only a weak internal pull-up — so both need 4.7 kΩ pull-ups to bank-4 VCCIO (3.3 V) on the board. Confirm the flash/HR1 clock is EMCCLK (P16) vs CCLK, and pin down the x8 MI4–7, HyperRAM DQS/RWDS and 2nd CS against GoWin's MSPI-HyperRAM app note (the x4 MCSN/MOSI/MISO/MI2/MI3 are solid).
• All banks are fully allocated — no unassigned spares remain. Bank 3's six former spares and bank 4's two now carry restored header GPIO15–22. Header GPIO assignments are not spare pins.

User I/O Header — Raspberry Pi layout

All 28 header GPIO are populated (GPIO0–27), a full 40-pin Raspberry-Pi-layout interface. GPIO0–14 and GPIO23–27 reach the header through the 1.5 V ↔ 3.3 V translators on banks 5/6/7; the restored GPIO15–22 come off bank-3/4 balls at 3.3 V and connect directly, no translator. GPIO15–25 no longer route to their original bank-5 balls — those now carry the DDR3 ninth byte lane — so they are re-driven from the reassigned balls (banks 3/4/7). The earlier beyond-Pi extras GPIO28–30 are dropped. Power/ground retain their existing positions.

Parallel-bus grouping. The full 18-bit SMI data bus (SD0–SD17 on GPIO8–25) is restored: GPIO8–14 on bank-5 balls, GPIO15–25 on the reassigned bank-3/4/7 balls. SA0–5 (GPIO0–5) and SOE_N/SWE_N (GPIO6/7) are unchanged. Caveat: the 18 data lines are no longer bank-contiguous — GPIO8–14 sit in bank 5 (1.5 V, translated), GPIO15–22 in banks 3/4 (3.3 V, direct) and GPIO23–25 in bank 7 (1.5 V, translated) — so per-line skew/delay tuning may be needed at high SMI clocks. The clean single-bank grouping is not recoverable while the DDR3 ninth lane occupies the original bank-5 balls.

Physical placement — rear-mounted, Raspberry Pi 400 / 500 style. The header sits on the rear edge of the case, horizontal and facing outward, the way the Pi 400 and Pi 500 expose theirs — the natural home for a keyboard-computer: reachable without opening the case, and a HAT or ribbon lies flat off the back. This does not change the pin-to-signal map below — it is the standard Pi electrical pinout (pin 1 = 3.3 V, pin 3 = GPIO2, … pin 40 = GPIO21). What it changes is orientation: a rear-facing connector is approached from the opposite side to a board-top header, so its physical pin-1 corner is flipped relative to a classic Pi — the same reason Pi-400 GPIO adapters are "reversed". Fix pin 1's physical corner in the mechanical layout, and if Pi-400/500-style adapters or cables should drop in, match their orientation and verify against a real unit.

Accelerator adapter — optional Raspberry Pi co-processor

The user I/O header above is a general Raspberry-Pi-layout expansion — HATs, the 18-bit SMI bus, the Z80 bus, and user GPIO all live on it as documented. Plugging a Raspberry Pi in as a co-processor — the way the ZX Spectrum Next uses a Pi Zero "accelerator" — is a purist/enthusiast option, not a normal-use feature: the Ant64 already has a built-in companion computer (DeMon, the CM5), so an external Pi is a bonus, not the primary compute path.

To keep the base header general, Pi-accelerator support lives inside the add-on module — a small adapter or carrier board — not on the mainboard connector. That confines every accelerator-specific quirk — connector orientation, the 3.3 V cut, Pi-tuned power protection — to a cheap, revisable board, and leaves the mainboard header fully available for HAT / SMI / Z80 / user-GPIO use.

Module options

The socket is a fixed contract — a standard 40-pin Pi-GPIO header, rear-mounted, with power gated by DeMon (PB6 / PB7). What fills the add-on module is free to vary, provided it presents that same standard header back to the socket:

• Pi Zero 1 / 2 W on the internal adapter (below) — mirrors the Next and reuses its NextPi ecosystem.
• A Compute Module (CM4/CM5, or a CM4-form module) on a small carrier PCB inside the module — the carrier breaks the CM's GPIO out to the same standard 40-pin footprint, so it looks identical to the socket. This is usually less bulky than a full Pi 4/5 in a box, brings out no port cluster, and reuses the CM know-how the Ant64 already has from DeMon; the orientation question softens too, since a carrier routes GPIO deliberately rather than mating two fixed headers.

Both are modest-current, internal, GPIO-only co-processors (≈0.2–0.5 A for a Zero; a CM similar at idle, more under load) — comfortably within the switched 5 V path, so the socket contract and DeMon power control are identical either way.

What the adapter passes, cuts, and protects

Physical pin order. Electrically the map is 1-to-1 by GPIO number, but the physical pin positions must match how a Next-style accelerator mounts — its Pi carries a female header on its underside and sits inverted over the host, so the position order is not necessarily a straight pass-through. Take the exact position translation from the ZX Spectrum Next's published Accelerator header pinout and verify it against the target Pi's inverted mount before committing the shim layout; do not assume a plain 1:1 physical pass-through. Note too that the base header is itself rear-mounted (Pi-400/500 orientation — see the header section), so the shim has two orientation factors to reconcile: the header's rear-facing hand and the accelerator Pi's inverted mount.

Power protection (why the shim, and the mainboard)

• Back-feed on 5 V. The Pi's header 5 V pins connect straight to its 5 V rail with no input protection (the Pi's fuse/ideal-diode is only on its USB input). The load switch above blocks the Pi back-feeding the Ant64 (e.g. if a user also plugs USB power into the Pi) and trips on a Pi fault instead of sagging the board rail.
• Phantom-powering through GPIO. Driving a GPIO high into a Pi whose 3.3 V rail is down leaks current through the Pi's ESD clamps into its rail (possible latch-up). Mitigate with the series resistors above and, ideally, an output-enable-gated buffer/translator held disabled until the Pi's 3.3 V is up. Sequence that across the two supervisors: DeMon enables 5 V (expander PB7), the Pi's 3.3 V comes up, and only then does FireStorm drive the header GPIO — coordinated over the DeMon↔FireStorm ready/done lines and QSPI channel.
• Mainboard supplies. The header's 3.3 V and 5 V are switched, current-limited rails (load switch / eFuse) enabled by DeMon's I/O expander — PB6 = 3.3 V, PB7 = 5 V — defaulting off until DeMon powers them up. That gives current limiting and reverse-block protection for any HAT or a shorted header, not just the accelerator, and lets DeMon gate header power independent of FPGA state. Keep the switched header-pin 3.3 V separate from the 3.3 V powering the level translators, so cutting HAT power doesn't disable the FPGA's own GPIO / SMI / Z80 use of the header.

Packaging — rear-plug accelerator module

Because the header is rear-mounted and outward-facing (above), the whole accelerator — the adapter or carrier board plus its Pi or CM — can be a sealed rear-plug module that clips onto the back of the case like a dock or an oversized cartridge. Every awkward detail (the orientation flip, the 3.3 V cut, the series resistors, the Pi-specific load switch) is resolved inside the module, so the mainboard header stays fully general and the accelerator is a clean optional accessory.

Design intent for the enclosure:

• The module hosts its own load switch. Size the eFuse / load switch (soft-start, current limit, reverse-current block) to the module's Pi or CM. The mainboard just presents the raw switched 5 V — still PB7-gated by DeMon for the coarse enable, power sequencing and header-short protection — plus the GPIO; it needn't know whether the module holds a Pi Zero or a CM, because the module owns its own tailored protection.
• Key the connector. Once the shim is wired and boxed, a keyed/shrouded connector means the module can seat only one way — which retires the "two orientation factors" concern entirely for the user. Key it deliberately, since the header's rear-facing (reversed) hand makes a wrong-way insert plausible otherwise.
• Take the mechanical load off the pins. A boxed module cantilevered off a single 40-pin connector has mass and leverage, and the contacts must not carry it. Plan retention — a clip, a thumbscrew, or a shroud/rails the module slides into and seats against the case.
• Sealed, GPIO-only — thermals stay modest. Whether the module holds a Pi Zero on the adapter or a CM on a carrier, it's an internal co-processor that talks only over the header GPIO, so the box can be sealed with no ports to bring out. A Pi Zero runs happily passive; a CM under sustained load wants a small heatspreader and a thermal path to the case — but neither needs the airflow a boxed full Pi would.