Cartilage Project Structure, 2022
April 27, 2022

Project-structure noteOriginally posted 2022-04-27; rewritten here around concrete Cartilage work packages.

Included: fabric emulator, FPGA element sizing, LUT/MUX/DFF trade space, Sinew control plane, physical FPGA prototypes, Cartilage VM/runtime, and language syntax.

Four Work Packages

The 2022 Cartilage work split into four practical layers: a fabric emulator, physical FPGA prototypes, a Cartilage VM/runtime, and a massively parallel language surface.

That split still reads well because each layer answers a different engineering question. What is the right cell size? Can the structure run on available hardware? What owns regions and routes? How does another builder express work for the fabric?

1. Fabric Emulator

The emulator was meant to explore FPGA-element size and interconnect shape before committing to hardware. The variables included D flip-flops, multiplexer networks, LUTs, local routing, and SerDes bandwidth for inter-node communication.

An early GLSL prototype used a very small reconfigurable switching fabric. The next step was a JavaScript/Node.js emulator for a small array of interconnected FPGA-like nodes controlled by a special overlay control plane called Sinew.

2. Physical FPGA Prototypes

The physical path used stock FPGAs as a near-term substrate. The note mentions a flex-PCB direction using iCE40LP384-SG32 parts and a higher-bandwidth FIFO-rich iCE40HX1K-TQ144 modular PCB direction.

The point was not to pretend stock parts were the final element. They were a way to test packaging, communication, modularity, and the cost of building a fabric from available devices.

3. Cartilage VM and Runtime

The Cartilage runtime layer was the zone manager. It could sit on top of the emulator, stock-FPGA prototypes, or a later optimized physical element.

Its responsibility was to manage reactive structure: local regions, ports, route management, contained object instantiation, and runtime type creation without flattening the fabric into one global controller.

4. Language Surface

The language layer was the human-facing surface for distributed massively parallel programs. It had to express regions, messages, state, configuration, placement, and failure without hiding the runtime boundaries that make the system supportable.

That remains the adoption test for this kind of work. A fabric becomes useful when another builder can run examples, see ownership, and understand what changes when a region is instantiated or reconfigured.

Current Mechanism

The 2022 project structure was a roadmap. The current inspectable mechanism is Cartilage Core: a compact browser fabric, hardware paper, local-clocked SystemVerilog RTL, and an exact 252-bit installation. Its public source repository is the concrete starting point for evaluating what now exists and what still belongs to the roadmap.