Ouroboros is a FPGA Laptop created by vibe coding to vibe code more. We use a static RVA23 architecture to boot Ubuntu, alongside a reconfigurable systolic array unit based around the AI model to be run on the device. The physical hardware too, outside of the core FPGA will be vibe coded.
Ouroboros aims to be fully RVA23S64 Compliant, verified by running DoomV in Lock-step (which is Sail Compliant).
Ouroboros is more of a funny proof of concept than an actual competitive commercial tool, so for ease of development there will only be basic pipelining with stalls to fix hazards. The number of harts (hardware threads) is configurable, one by default; DoomV, the lock-step reference, runs the same number.
Additionally, the CPU core itself is not the primary focus of optimization, it's purpose is only to boot Ubuntu and commercial software here. If I don't get bored, I'll work on optimizing it for either faster throughput or to minimize look-up tables.
However, the V-Extension of the RVA23 core here adds complexity. Users will have the ability to choose the width of the vector execution units (the length will be set at 128) when configuring their CPU (costs more LUT tho). (Otherwise, our default behavior will be to stall until every operation is complete)
The dynamic systolic array unit is the primary focus here. The goal is to feed Ouroboros a .gguf and an FPGA target, get the parameters from it, and get an optimized systolic array unit out of it. (Thing like the PE's will be based around the data-types used in the .gguf, etc, etc). The user will get a recommended implementation, but users can configure it to generate their own configuration.
When you build, you will be given the generic builds for the CPU in one folder and the reconfigurable systolic array in another. External devices (memory, usb, video output) will be difficult to be generated by the software. However, for the sake of proof-of-concept, we will include the full suite for the Kria KV260 (HDMI Output, Memory Interfacing, USB Interfacing, etc). Where possible, we will try to make these generic and not reliant on the specific FPGA, but when absolutely required we will focus on that target platform. Hopefully, we can make these dynamic. (Ask the user what extra components they need in the configurator, HDNI, USB Input for IO, SD Cards, External Memory, PCIE, etc).
Ideally almost everything will be configurable at build time. (ISA Extensions, Specifics for V Extension, Data Types for the PE Units, Number of PE Units, KV Cache, I/O ports, number of DMA controllers, etc).
Many of these will have pre-calculated recommended optimized settings based on the FPGA (Have controllers for all available I/O that the FPGA support, use data-types based on .gguf, extra space for bigger vector unit). Ideally, it will also optimize around available memory. We will NOT be using any built in CPU cores, cause that's lame. Users will be asked what use cases they want to target, "super-fast prefill, super-fast decode (tokens/sec, balanced, or a percentile of their goals).
All of this will ideally be in a clean CLI kinda like claude code. (Like with fancy text and animations showing current system progress, what step it's on, where it might fail, what is responsible for said failures.)
C Simulation:
RTL Simulation:
This program uses Vitis for compliation.
Run Ouroboros, it will ask for a .gguf and it will ask for an FPGA target. From that target, it reads the model parameters, and the FPGA specifications (Memory / Look-up tables). It will build an estimated requirements document (LUTS needed for the CPU and Systolic Array, number of PE's for the Systolic Array, KV Cache Requirements, Memory format in the PE units, etc) for the user, and it will warn the user if that model optimized architecture won't work for that particular FPGA. With the requirements doc, the software will adjust parameters in the Vitis C++ code, then synthesize for Vivado compilation. It will then generate a bitstream for the target FPGA.