Fabric Inside Fabric

A larger FPGA design can instantiate a smaller programmable region and feed it a local configuration stream. At that point the region behaves less like a fixed module and more like a tiny fabric with explicit ports, local state, and a bounded routing problem.

The useful comparison is not novelty. It is resource shape. A tiny CPU brings an instruction pointer, registers, program memory, and software tooling. A tiny fabric brings local logic, routing, and configuration bits. Either can be right, but they are not the same machine.

Why Not Just Use Cores?

Thousands of small CPU cores make sense when the work is naturally instruction-driven. They are less natural when the work is a fixed local rule, a small datapath, a routing decision, or a pipeline stage that only needs to change its configuration.

Keeping the behavior as logic can preserve timing and locality. It also makes the cost visible: LUTs, flip-flops, routing, configuration storage, placement pressure, and debug tooling.

Useful Scope

Nested fabric spends FPGA resources to create a programmable substrate inside another programmable substrate. It earns that cost when local reconfiguration is simpler than rebuilding the whole design or embedding a processor where a small circuit would do.

The current concrete reference is Cartilage Core. Its public source repository publishes a local-cell SystemVerilog fabric and exact serial installation, but does not yet provide FPGA synthesis, placement, timing, area, or power results.