This is a dated review of related Tang FPGA projects that may inform NextTang. Each result applies only to the named upstream commit, tool version and target. No reviewed source or generated vendor output has been imported into NextTang, and none of these results is a NextTang build or hardware result.
| Project | Reviewed identity | Useful evidence | Local result |
|---|---|---|---|
| NextNano | ba1d834 |
Gowin clock-enable, memory CDC, reset-epoch, sticky-diagnostic and timing-report patterns | Source reviewed only |
| MSXimus | v2.1.2, commit 56543fe |
Candidate Console 60K clock, HDMI, SD, flash, BL616 and board-control mappings | Synthesis completed, but the full build failed before place-and-route; no bitstream |
| Tang Mega 138K FPGA projects | 7c17183 |
50 MHz input and 150/750 MHz DVI path using OSER10 and differential outputs |
Five bitstreams generated; one project missed its 150 MHz setup constraint |
| MSXnano | v1.9, commit ce46ef9 |
Nano 20K shell, BL616 FPGA Companion boundary and focused regressions | Two regressions passed; a compatibility-adjusted build generated a bitstream with 36 setup and 12 hold violations |
| MSXgoauldSD_usbkb | 15f1a7f |
External RP2040 USB-input boundary and shared MSXnano lineage | Clean FPGA build failed because four required Verilog files are absent; gw_sh still returned zero |
| TangCore | f69c6ff |
BL616-managed multi-core shell, storage and FPGA loading | Source reviewed; release images not run |
| SNESTang | 427af30 |
Toggle-mailbox and video-arbitration failure precedent | Source and issues reviewed only |
| NESTang | 5b24a71 |
Explicit SDRAM client priority and bank ownership | Source and issues reviewed only |
| 486tang | b3de0a8 |
Console 138K onboard-DDR3 framebuffer and read-ahead pattern | Released bitstream exists upstream; source reviewed only |
| ddr3_framebuffer_gowin | d3c2773 |
Buffered DDR3 framebuffer for Console 60K/138K | Upstream reports hardware tests; not reproduced by NextTang |
| usb_hid_host | 678b013 |
Small low-speed direct-device USB host | Source and issues reviewed only |
The local builds used GOWIN EDA Standard V1.9.12.03. Simulation checks used
Icarus Verilog and Verilator 5.020 where applicable.
The vdalex projects establish that the installed vendor flow can synthesize,
place, route and generate bitstreams for substantial pure-Verilog
GW5AST-138C designs. They also provide a useful DVI bring-up shape. Their
constraints target the bare Tang Mega 138K, not the Tang Console carrier, so
the pins cannot be transferred until the exact Console board is inspected.
MSXimus provides the best candidate Console 60K constraint study found so far. Its active design uses the Console's external SDR SDRAM module and its DDR3 wrapper is unfinished. It does not solve the Console 138K buffered-DDR3 path.
NextNano, MSXnano and Goa'uld provide companion-controller, USB-input and board shell patterns. These are useful at platform boundaries. They do not identify the Tang Console's high-speed USB controller or establish Console behaviour.
The build attempts answer a separate process question: a zero tool exit status
or an existing .fs file is not sufficient evidence of success. Goa'uld logged
missing-source errors, returned zero and produced no fresh bitstream while its
repository contained older generated output. MSXnano generated a fresh
bitstream but failed timing. Future NextTang board drivers must therefore use
clean outputs, inspect tool logs, require fresh reports and artefacts, and reject
violated required timing constraints.
The most useful result is a sharper memory-controller contract. SNESTang issue 17 contains an unmerged analysis of request toggles and addresses changing while a read is outstanding. The described result is a cancelled request or a response associated with a mixed old/new address. It is not a NextTang diagnosis, but it is close enough to the upstream Layer 2 toggle interface to become a required simulation case.
The NextTang adapter must keep request metadata stable until acknowledgement, define what happens to a second request, bind each response to its accepted address, prioritise fixed-deadline video work and report any overrun. DDR latency and refresh injection must cover back-to-back address changes, CPU/video collisions, reset during an outstanding request and buffer underflow.
The onboard DDR3 examples do not remove that work. 486tang uses DDR3 only for a
continuously rewritten framebuffer, while main RAM remains on external SDRAM.
Its wrapper and ddr3_framebuffer_gowin read ahead and disable refresh. That is a
useful framebuffer precedent, but it cannot retain NextTang's 2 MB memory and
does not satisfy its two-port contract.
TangCore issue 8 adds a separate transport requirement. Reports describe ROM loading reaching completion before a black screen or audio pops. The suspected BL616-to-FPGA loss is not confirmed. NextTang will make the boundary testable through transfer length, integrity checks, acknowledgements, timeouts and error counters rather than adopting the suspected diagnosis.
Tool and source identity also need to be exact. NESTang and SNESTang reports show
behaviour changing between Gowin patch releases. TangCore has a reported missing
pinned submodule commit, and the reviewed source tree does not reproduce every
Console image shipped in v0.9. A clean source build, timing result, release
image and hardware observation remain separate evidence.
The vdalex repository has no licence grant and no provenance notice for its shared DVI/TMDS block. NextTang will not copy its source or constraints. MSXimus has a GPLv3 root but includes an active V9968 core under non-commercial terms and other component licences. MSXnano and Goa'uld also contain multiple component and payload boundaries. Any reuse still requires a per-file audit.
The current disposition is to study or independently reimplement narrow board shells, tests, reset sequencing, clocking and interface patterns. MiSTer ZXNext remains the pinned core baseline.
- Exact Tang Console 138K product, SOM, PCB and B/C silicon revision.
- Whether bare Tang Mega 138K constraints match the Console carrier.
- NextTang synthesis, resource fit and timing closure on either Console.
- Buffered onboard-DDR3 integration on the 138K.
- The Console USB debug path and measured throughput.
- PCIe stability against a Raspberry Pi 5.
- A complete Console 60K build and hardware result.
These questions remain open until the relevant exact-board build or hardware evidence exists.