Cartilage Reconfigurable Computing Roadmap: Progress And Next Milestones

The finite continuation program for turning the Cartilage prototype into a readable, controllable, robust, shareable, and teachable spatial circuit workstation.

Cartilage already makes local Boolean roles, routing, ownership, and configuration visible. The next version does not need a new theory of computation. It needs a disciplined renderer and inspector, a region-scale configuration interface, safe ownership transfer and recovery, and the web-product ergonomics that let an engineer build and debug a serious circuit.

This page provides public progress tracking. It says what remains, why the order matters, and what evidence will be required before an item changes from Planned to Complete.

Established baselineThe public Core demonstrates one exact serially installed 6×6 child region, and the MUX visual edition separately verifies already placed application circuits.

Continuation workAll 28 implementation items below are proposed. The diagrams describe target behavior; they are not screenshots of features the current shader already supports.

Engine reviewed for this roadmap: Cartilage Core 48ff6e0.

Inspect the current Core Open public source Learn Cartilage Support or contribute

Implementation Progress

0/28 complete

0 of 28

28 work items remain. Roadmap publication itself is complete and is not counted as an engine feature.

Completion Rule

Planned names an accepted target.

Active requires a linked implementation branch or issue.

Complete requires merged code, a repeatable check, and a public capture, demo, or report.

Last reviewed .

Proposed Cartilage dependency roadmap from component and wire visibility through region claiming, single-writer ownership, closed-contour recovery, simulator controls, and lessons
The dependency order is deliberate: make the fabric observable first, make authority deterministic second, then add destructive recovery and product-facing workflows.

What Exists Before This Roadmap

The continuation starts from working machinery, not from a slide deck. Cartilage Core publishes a local WebGL1/GLSL transition, independent SystemVerilog, and one checked 6×6 image streamed as 252 payload bits plus one apply pulse. The installed image realizes an interior-MUX AND circuit.

MUX Algebra gives 34 one-to-one abstract and Cartilage views with 606 shader-readback cases. Those captures load circuits that are already placed and routed, so they prove application behavior and illustration parity, not a general compiler or the serial installation of every example.

The preserved nested-instantiation artifact shows the architectural direction: a parent, a local port, a bounded daughter region, and roles rewritten through the fabric. The roadmap below makes the missing interface and lifecycle work explicit.

Established
Local roles, parent directions, one fixed ownership-tree postorder, one exact region install, current application-plane patches, and preserved nested-region behavior.
Not established
The block inspector, named net tracing, multi-cell root interface, generalized claim protocol, ownership overlap, kill-pill recovery, hosted persistence, tutorial shell, or Logisim-replacement milestone.

The Build Order

Usability is first because the ownership and recovery protocols cannot be debugged through a sea of unlabeled wires and instantaneous bubbles. Region claiming comes next because overlap and recovery need deterministic authority. The hosted tool and lessons then expose the same checked mechanisms without inventing a second simulator.

  1. See and control it.
    Blocks, ports, nets, fanout, pause, and step.
  2. Claim it.
    A multi-cell root and deterministic spanning tree.
  3. Share it safely.
    Overlapping references with one writer.
  4. Recover it.
    A serial token around one closed contour.
  5. Publish and teach it.
    Save, host, replay, and button-driven lessons.
P0

Render Components And Make Every Net Traceable

The first release must let a person see the same component structure that the design author intended, without pretending that every named block is an independently reconfigurable region.

A defining block may attach a stable, non-reconfigurable component tag to the cells in its subtree. That tag is display and authoring metadata. It does not create a reconfiguration-port root, it does not break the larger continuous ownership tree, and it does not grant write authority. The renderer can then derive block backgrounds, exact block boundaries and contours, hover states, labels, and inspection data from tag membership.

Proposed Cartilage component tags deriving block backgrounds, contours, and hover selection while one continuous ownership tree passes through all tagged subcomponents
A component tag identifies a subtree for people and tools. It is not an ownership root or transport port; parent pointers remain one continuous tree.

Wire rendering needs a second mode. An unbranched net should read as one continuous route, not as a chain of bubbles. The present instantaneous wave was optimized for rendering throughput, not for a person following the route. Direction may be shown with static arrowheads and, when wire animation is enabled, slow interframes that expose modeled propagation order. Selecting any segment must reveal the complete named net, its single driver, every branch, every sink, and every component boundary it crosses.

Proposed Cartilage wire rendering comparing repeated bubbles with a named directional net traced from one input port to three fanout sinks across component regions
Value, activity, and direction are separate cues. A fanout trace follows logical connectivity; it is not a claim about transistor drive strength or physical timing.
P0

Replace The One-Cell Root Assumption With A Region Interface

One MUX-sized cell is too small a unit for the complete reconfiguration interface now required at a practical region boundary.

The issue is a reconfiguration channel contract, not merely drawing space. A region must independently carry at least configuration clock, data in, and data out while remaining connected to its internal ownership tree. The implementation should therefore define one logical root whose physical footprint may use several cells or lanes. The exact minimum shape must be measured; a 2×2 drawing is only a candidate, not a theorem.

Proposed Cartilage reconfiguration interface comparison showing the channel conflict of one root cell and a larger logical root with separate clock, data-in, data-out, and ownership-tree connections
The future root is a logical interface implemented by enough physical cells to keep its channels and ownership-tree trunk explicit.

Boot must also become deterministic. In the current experimental transition, a cell without a live configuration signal can rotate its parent direction while searching. A practical fabric cannot depend on an indefinite search that makes cells spin or gray unpredictably. The proposed boot image makes unclaimed cells explicitly claimable, then lets a reconfiguration root claim them through an ordered spanning tree with a defined edge and child order.

Proposed Cartilage multi-cell root and deterministic wavefront that claims a closed component, assigns one adjacent parent per non-root cell, and produces one postorder visit
An ordered claim must visit every selected cell exactly once, give every non-root one adjacent parent, reject cycles and orphans, and reproduce the same postorder stream.
P1

Support Shared Objects Without Creating Multiple Writers

Composition becomes much more flexible when an object can be referenced, stored, and managed from more than one surrounding object while mutation authority remains singular.

Here, ownership overlap means overlapping logical containment or shared application references above a physical ownership forest. It does not mean that one physical cell suddenly has two adjacent parents. In the requested 4×4 fixture, every non-root cell still has exactly one adjacent parent, and exactly one surrounding block holds the current single writer authority.

A passable ownership pointer is therefore an ordered transfer of unique mutation authority, not a duplicate writer. The handoff must fence the old writer, acknowledge the new generation, and reject stale pointers.

Proposed Cartilage 4 by 4 shared object referenced by adjacent blocks while one marked parent and writer token transfers atomically from block B to block D
Sharing and physical ownership use different edges. The shared object may participate in several compositions, but its physical parent tree and mutable writer remain unique.

physical parents per non-root cell = 1
active writers per mutable shared object ≤ 1
writer transfer = fence → acknowledge → generation change → release

P1

Recover A Stuck Ownership Island With A Closed-Contour Kill Pill

A self-pointing or cyclic ownership island needs a bounded recovery protocol that does not depend on the stuck object cooperating internally.

The sequential serial kill pill is a proposed reset token, not an instantaneous global clear. The surrounding owner or owners first establish one valid closed contour around the isolated object. If one object surrounds the full perimeter, it can inject alone. If several objects share that perimeter, boundary collaboration must create one ordered transaction.

The token propagates around the perimeter and returns to its injection point. Only that loop closure authorizes injection into the enclosed region. The enclosed subfabric then performs a reset to power-on: it receives the same explicit claimable image used at startup. Open, branched, duplicated, or incomplete contours must abort without a partial reset.

Proposed Cartilage serial kill-pill sequence in which surrounding blocks collaborate on a closed perimeter, the token returns to its origin, and only then resets the enclosed stuck ownership object
The perimeter is the authorization path. No enclosed cell resets until the complete closed contour has been traversed and acknowledged.
P2

Turn The Shader Into A Practical Browser Workstation

The simulator needs ordinary controls and durable project state, but the host must remain a driver, observer, serializer, and publisher rather than becoming a hidden semantic interpreter.

Play, pause, single-step, and speed control must govern the real simulator state and the propagation view together. Saving must distinguish the editable source project from a transient runtime checkpoint. Static hosting can publish the application; authenticated server hosting and project storage are a separate service with versions, permissions, and conflict protection.

Target Cartilage browser workstation with play, pause, step, speed, save, load and share controls, a named-net inspector, and lesson buttons that drive the actual simulator
Run control, project persistence, publication, and lessons are different surfaces over the same engine. A lesson button must cause one visible state change and one machine-checked result.
P3

Publish A Button-Driven Cartilage Learning Series

A reader should be able to press a button on a web page and watch the actual fabric receive a signal, trace a net, claim a region, transfer authority, or recover an object.

The series must not be a slideshow sitting next to the simulator. Every button-driven tutorial starts from a deterministic machine snapshot, gives one visible action, and checks one real result. The order begins with constants, wires, a MUX, fanout, names, and ports; it then advances through state, component composition, regional reconfiguration, ownership transfer, and closed-contour recovery.

The Logisim Replacement Target

Release gateThe goal is to replace Logisim completely in the Cartilage design, simulation, debugging, and teaching workflow, then go beyond it with spatial ownership and runtime replacement.

That claim will be earned when a user can:

  • place and edit constants, wires, crossings, MUXes, state, blocks, and named ports;
  • trace fanout, pause, step, probe, label, and compare expected behavior;
  • save, reopen, share, and continue editing a project in the browser;
  • rebuild representative existing circuits, including the MUX catalog, an adder, a sequential circuit, and the bubbles-free serial multiplier;
  • run the region-claim, ownership-transfer, and recovery mechanisms that Logisim does not provide.

Until that bar is met, the accurate phrase is a path toward replacing Logisim in the Cartilage workflow. File-level .circ compatibility is a separate milestone and will not be implied unless it is implemented and tested.

How To Support Or Contribute

This roadmap is what the Cartilage continuation program needs fundraising, engineering time, review, hosting, and contributors to finish. The work is concrete enough to divide without fragmenting the architecture.

Fund a work package

Move One Milestone To Evidence

Support a bounded renderer, protocol, persistence, or lesson package with its completion test defined in advance.

Contribute engineering time

GLSL, Web UI, Protocols, Or Verification

Help implement one task ID, build its fixture, or make its result repeatable across browser and hardware-model layers.

Review and teach

Try To Break The Model, Then Help Explain It

Architecture review, fault injection, accessibility work, curriculum design, classroom pilots, and server infrastructure all move this from prototype proof to a usable engineering environment.

Contact Brian Greenforest about Cartilage

Contributions and funding will be reported against the task IDs above. No percentage will move without a defined denominator, and no item will be marked complete without linked evidence.

Progress Log

  1. : roadmap opened with 28 planned implementation items across renderer ergonomics, region roots, ownership overlap, recovery, the simulator shell, and lessons.