When a design crosses a single FPGA, partitioning, clocks, SerDes links, latency, placement, and routing become part of the program.

The problem is not just buying more fabric. The design now has physical boundaries that must be represented in the architecture.

Scale noteOriginally posted 2022-05-11; rewritten here around the multi-device engineering problem.

Included: partitioning, SerDes, clocks, protocols, latency, pipelines, placement, routing, and why the software stack often appears when the FPGA boundary becomes too hard to manage directly.

Article focus: what changes when an FPGA design crosses one device: partitioning, SerDes, clocks, protocols, latency, pipelines, placement, and routing.

The Device Boundary

A large FPGA design is still one physical timing problem while it fits inside one package. Once the design crosses into a second package, the boundary becomes architectural.

Internal nets are no longer only routes. They become framed links, clock-domain crossings, latency contracts, reset rules, flow-control paths, debug paths, and placement constraints.

What Changes

Partitioning

The design must be split where data movement, timing, and ownership can survive the package boundary.

SerDes

Internal wires become serialized links with framing, recovery, training, flow control, and error behavior.

Clocks

Clock distribution becomes clock-domain crossing, synchronization, timestamping, or explicit asynchronous protocol design.

Latency

Pipeline timing now includes link delay, buffering, retry behavior, and remote backpressure.

Placement

Physical placement and routing are no longer only vendor-tool concerns; they affect the program architecture.

Why The Software Stack Appears

Teams often escape this problem by moving work into CPUs, Linux, GPU kernels, orchestration systems, services, or message queues. That can be the right tradeoff, but it changes the machine.

The FPGA fabric stops being the whole execution model and becomes one layer inside a larger software-controlled system. That may improve delivery, but it also adds latency, memory movement, operating-system behavior, deployment complexity, and more places for state to hide.

What Must Remain Readable

The useful goal is not scale as a headline. The useful goal is a split design whose timing, data ownership, resource pressure, and failure behavior can still be read by the people maintaining it.

A multi-device fabric needs explicit boundaries: what crosses, when it crosses, who owns it after it crosses, what happens when it arrives late, and how the rest of the pipeline keeps moving.

Related Fabric Work

The Cartilage articles explore a smaller, visual version of the same concern: ownership, configuration, and routing boundaries should remain visible inside the fabric. The Cartilage Visual Language article decodes the cell-role alphabet used by that line of work.

Original Post Context

The original post was written around the moment when a single FPGA is no longer enough: the logic must be partitioned, clocks and latency must be redesigned, and the project can become dominated by custom glue.

The cleaned-up claim is narrower and stronger: crossing a device boundary turns physical scale into part of the program.