GMSL2 Multi-Camera Sync Past 4 Cameras: Fanout Topology

Every GMSL2 deserializer on the market caps out at four camera inputs per chip, so any system that needs five, six, or eight synchronized cameras has to bridge multiple deserializer chips together. GMSL2 multi-camera sync past 4 cameras is not a bigger-chip problem, because no bigger chip exists. It is a topology decision, and the wrong one turns an “8-camera synchronized array” into two perfectly-synced but mutually unsynced islands of four. This post covers why daisy-chaining deserializers destroys frame alignment as you scale up, and the fanout topology that keeps an array of any size on one shared timing reference.

Key Insights

• GMSL2 deserializers have a hard per-chip camera-input ceiling, commonly four, so scaling past that always means adding chips, not reconfiguring one
• Daisy-chaining deserializers, where one chip generates the sync pulse and relays it to the next over a GPIO link, routes the reference through a full extra hop of relay propagation delay before it reaches the second chip’s cameras
• That extra hop is not a rounding error: it moves the delay budget from a tight, single-chip skew figure to something orders of magnitude larger, and it lands on every camera downstream of it
• The fix is parallel-subordinate fanout: one shared hardware-timer reference, split on length-matched traces, feeding every deserializer at the same time, with none of them relaying for another
• A software GPIO toggle cannot serve as that shared reference no matter how the chips are wired; only a hardware timer or PWM source has jitter tight enough to matter at this scale

Why GMSL2 multi-camera sync breaks down past 4 cameras

A GMSL2 deserializer is built to be the sync hub for its own links. It owns the timing reference, whether that reference originates internally or from an external GPIO, and it distributes that reference to every camera wired to it. Inside a single chip, this is a solved problem: the deserializer’s own datasheet specifies a tight skew budget across its links, and as long as you enable the delay-compensated mode for that reverse-channel signal, every camera on that chip sees the same edge within that chip’s own tight tolerance of every other camera on it.

The ceiling is the chip itself. Deserializers in this class support four camera inputs each. A system that needs five, six, or eight cameras needs two or more of these chips, full stop, there is no larger single-chip part that changes this math. Once frames span more than one deserializer, frame-start alignment stops being a per-chip configuration question and becomes a system-architecture question: every chip in the array now has to be driven from a common reference, or the array is not one synchronized system, it is several small synchronized systems that happen to share a housing and a power supply.

If you have not configured FSYNC on a single deserializer yet, our GMSL2 multi-camera sync FSYNC setup guide covers the delay-compensated mode and DTS wiring for arrays of up to four cameras. This post picks up where that one leaves off, once a fifth camera forces a second chip into the design.

That failure mode is common enough that it has a name we use internally: islands of four. Boards marketed as “8-camera synchronized” often turn out, on inspection, to be two four-port deserializers that are each internally perfect and never shared a timing source with each other. Each half looks fine in isolation. Across the two halves, there is no relationship at all between frame starts, because nobody wired a shared reference between the chips in the first place. For an application where the whole point is that every camera captures the same instant, an unsynchronized pair of perfectly-synchronized quads is a very expensive way to fail the actual requirement.

This is exactly the kind of thing to catch before hardware is committed. When you are choosing a GMSL2 carrier board for Jetson Orin, port count and deserializer chipset are not the only questions that matter, whether the board’s own layout ties multiple deserializers to one shared reference matters just as much, and it is rarely called out in a vendor’s marketing copy.

The daisy-chain trap

The instinctive way to connect two deserializer chips is to make the first one the source and let it drive the second, the same way you’d chain two switches on a network. For GMSL2 sync, this is the wrong instinct, and it is worth being explicit about why.

In a daisy chain, deserializer 1 is configured as the sync generator and deserializer 2 is configured to receive its reference from deserializer 1 over a GPIO link between the two chips. That link is not a passive wire. The reference has to pass through deserializer 1’s own relay logic (the same reverse-channel GPIO path it uses to forward sync to its own cameras) before it ever reaches deserializer 2. That relay adds a full hop of propagation delay, well outside the tight tolerance a chip’s own internal skew budget is built around. That gap is not something you tune around. It shows up as every camera behind deserializer 2 capturing measurably later than every camera behind deserializer 1, consistently, on every frame.

Topology	What the reference passes through	Effect on cross-chip alignment
Single deserializer (up to 4 cameras)	Nothing, the chip drives its own links directly	Tight, chip-specified skew across those cameras only
Daisy-chain (chip 1 MAIN drives chip 2 as a downstream source)	One full hop of chip 1’s own relay/propagation path	A fixed, much larger delay added to every camera behind chip 2
Parallel-subordinate fanout (recommended)	Nothing extra, every chip receives the same external reference directly	Cross-chip alignment reduces to trace and cable length matching, not chip-to-chip relay delay

The daisy chain is also fragile in a way that is easy to miss during bring-up. If deserializer 1 ever glitches, resets, or briefly loses lock, every chip behind it loses sync at the same time, because they were never independent from deserializer 1’s health. A topology should not have a single point of failure sitting in the middle of the timing path.

The correct topology: parallel-subordinate fanout

The fix is to stop treating any deserializer as the source for another deserializer. Instead, pick one shared reference, generated once on the host side by a hardware timer or PWM peripheral, and fan it out on length-matched PCB traces (or equal-length cable runs, if the fanout point is off-board) to the sync input of every deserializer in the array, in parallel.

Host hardware-timer / PWM GPIO
        |   (one source, length-matched fanout)
   +----+----+ ... +
   v         v      v
 Deser 1   Deser 2  Deser k     <- each configured independently
 (subordinate)  (subordinate) (subordinate)   as a delay-compensated subordinate
   |          |       |
 <=4 cams   <=4 cams  <=4 cams    (each chip still handles its own cameras)

Every deserializer in this diagram is configured the same way: it receives an external reference and distributes it to its own cameras. None of them generates the pulse, and none of them relays it to a sibling chip. Because every chip sits directly on the shared source rather than behind another chip, cross-chip skew should collapse to two things you control directly on the PCB and in the harness: how well you matched the trace lengths in the fanout, and how well you matched the cable lengths running out to each deserializer. Neither of those is a chip-to-chip propagation delay, and neither compounds as you add more chips. That’s the design rationale for why this topology is sound, and it’s worth being direct that it’s rationale: the achievable cross-chip skew with real trace and cable mismatch on a specific board is a hardware validation question, not something to assume from the architecture alone. Measure it on your own layout before you commit to it in a spec.

This is also why parallel-subordinate fanout scales cleanly and daisy-chaining does not. Going from an 8-camera array (two chips) to a 12 or 16-camera array (three or four chips) means adding another branch to the fanout, not another link in a chain. The reference source does not care how many chips are listening, as long as it can drive the electrical load, which at higher chip counts may mean a buffer or repeater stage on the fanout network rather than a longer chain of relays. The alignment story stays the same for every chip you add: distance from the same source, not distance from the previous chip.

One requirement applies regardless of how you wire the chips: the shared reference itself has to come from a hardware timer or PWM output, not a GPIO toggled from a software loop. A software-driven GPIO carries scheduling jitter that lands in the microsecond-to-millisecond range depending on system load, which is the same order of magnitude as the daisy-chain penalty you were trying to avoid in the first place. Fixing the topology and then feeding it from an unstable source solves nothing.

Verifying the array is synchronized

Do not trust the wiring diagram. Verify the array after every board revision, cable change, or chip swap, using both of these checks:

1. Read back the chip’s own alignment measurement. Most deserializers in this class expose a runtime register that reports the measured difference between the earliest and latest sync arrival across their own links. Treat that readback as ground truth immediately after enabling sync on new hardware, before you assume the topology diagram matches what got built.
2. Compare host-side timestamps across chips, not just within one chip. Capture frames from at least one camera behind each deserializer at the same time and compare arrival timestamps the way you would for a single-chip array. A small, fixed offset that holds steady across a long capture points to trace or cable length mismatch, which is fixable in hardware. An offset that grows over time, or jumps unpredictably between chips, points to a topology problem, most often a daisy-chain link that got wired in somewhere without anyone deciding it should be there.
3. Confirm the source, not just the fanout. Before debugging anything downstream, check that the shared reference is coming from a hardware timer or PWM peripheral and not a software GPIO toggle. This single check rules out the most common root cause we see on arrays that fail sync past four cameras.
4. Re-run all of the above after any physical change. Trace and cable length matching is a property of that specific harness, not a permanent property of the schematic. A cable swap during a later production run can reintroduce a mismatch that the original design review never had to account for.

Skipping this verification step is how “islands of four” ship. The two halves of the array each pass every test you run on them individually, because each half really is internally synchronized. The only way to catch the missing cross-chip relationship is to test across chips deliberately, not just within each one.

Frequently Asked Questions

Can a single GMSL2 deserializer synchronize more than 4 cameras?

No. GMSL2 deserializers in common use cap out at four camera inputs per chip. Once a system needs five or more synchronized cameras, you need multiple deserializer chips, and frame alignment becomes a topology decision between those chips rather than a single-chip configuration setting.

Why does daisy-chaining GMSL2 deserializers break frame sync?

Daisy-chaining has one deserializer generate the sync pulse and relay it to the next deserializer over a GPIO link, instead of both chips receiving the reference directly from a shared source. That relay adds a full extra hop of propagation delay before the signal reaches the second chip’s cameras, a delay that is orders of magnitude larger than the tight single-chip skew budget. Cameras behind the second chip end up capturing measurably later than cameras on the first chip, on every frame.

What is the correct way to synchronize multiple GMSL2 deserializer chips?

Use a parallel-subordinate fanout. Generate one shared reference on the host with a hardware timer or PWM peripheral, then distribute it on length-matched traces or equal cable runs directly to every deserializer’s sync input at the same time. Configure each chip independently as a subordinate; none of them should generate the pulse or relay it to another chip.

Can a software GPIO toggle work as the shared sync reference for multiple deserializers?

No. A GPIO toggled from a software loop carries scheduling jitter in the microsecond-to-millisecond range, which is large enough to defeat the entire purpose of hardware sync. The shared reference needs deterministic, low-jitter timing from a hardware timer or PWM source. Fixing the topology does not help if the source feeding it is unstable.

How do I verify that a multi-deserializer camera array is synchronized?

Read back each deserializer’s own measured sync-alignment value after any wiring change, then separately capture and compare host-side frame timestamps from a camera behind each chip. A small, steady offset points to a cable or trace length mismatch. A growing or unpredictable offset between chips usually means a daisy-chain link exists somewhere in the topology that should have been a parallel fanout instead.

---

ProventusNova helps hardware startups solve embedded systems problems fast. Talk to us about GMSL2 multi-camera bring-up.