Jinix Jupiter v0.1-alpha — first public release of my custom 32-bit FPGA console/computer architecture
I’ve reached the point where I’m comfortable publishing the first developer release of a project I’ve been working on called Jinix Jupiter.
Jupiter is an original FPGA-based computer/console architecture rather than a recreation of an existing system. I’ve been developing and physically bringing it up on a SuperStation One, and v0.1-alpha is now available as the first public developer preview.
The current architecture includes:
- Custom 32-bit CPU
- SDRAM interface
- Shared-memory/DMA arbitration
- 2D graphics renderer
- Fixed-function 3D hardware under development
- Four-voice PCM audio
- Controller interface
- Minimal BIOS
- Custom assembler
- System-image/build tooling
For this release I wanted to avoid simply saying “it synthesizes, ship it,” so I went through a fairly strict release-validation process.
The exact committed release candidate was run through the full simulation suite, followed by a clean Quartus build using a pinned Quartus 17.0.2 environment. The resulting release RBF was then copied to the target media and physically smoke-tested on the FPGA hardware.
The public RBF successfully:
- boots on the target hardware;
- establishes HDMI output; and
- produces visible 2D graphics output.
The exact public binary was also downloaded back from the GitHub Release after publication and verified byte-for-byte against the validated release candidate.
There are a couple of important limitations that I’m deliberately documenting rather than hiding.
3D is not currently claimed as physically working. The fixed-function 3D path exists and has been exercised in simulation, but physical testing exposed an implementation-sensitive failure that I haven’t reduced to a proven root cause yet. I’ve paused that investigation at a reproducible diagnostic point rather than continuing to change things immediately before the public release.
Timing is also not being claimed as fully signed off. The constrained worst-case timing checks from the release build had non-negative slack, but TimeQuest reports that setup/hold coverage is not fully constrained. So I’m treating the timing status as:
PASS_WITH_PARTIAL_CONSTRAINT_COVERAGE
rather than calling the design fully timing-closed.
The release artifact is:
JinixJupiter_v0.1-alpha.rbf
SHA-256:
de5094dbd9da362e54f35627a7cbbc128e20144e1904fb685f41a38091076a4b
Size:
2,926,564 bytes
Release:
https://github.com/austinbland1/jinix_jupiter/releases/tag/v0.1-alpha
Repository:
https://github.com/austinbland1/jinix_jupiter
This is still very much an alpha developer platform, but it’s now at the point where there is a defined CPU, graphics/audio hardware, software toolchain, reproducible release artifact, and an actual public hardware-tested build.
I’d be particularly interested in feedback from people who have worked on:
- custom soft CPUs;
- SDRAM controllers;
- FPGA video pipelines;
- arbitration between CPU/DMA/graphics clients;
- timing-constraint coverage;
- or debugging designs that simulate correctly but become implementation-sensitive on physical hardware.
This version is mostly about establishing a solid public baseline. Now that v0.1-alpha is frozen, I can go back to breaking things again.
Verified video output over HDMI from a SuperStation one running the RBF
