I use CSI-2 aggregators to merge multiple cameras onto a limited number of MIPI ports, while keeping bandwidth and frame integrity under control for the ADAS SoC or accelerator.

• Merge 6–12 camera streams into 1–2 MIPI CSI-2 ports safely.
• Plan bandwidth so critical views do not suffer random frame drops.
• Match aggregator capabilities to my SoC or accelerator interfaces.

What this block solves

In a real ADAS project it is common for me to have six to twelve cameras but only one to three MIPI ports on my SoC. If I try to wire everything directly, the total bandwidth can spike, frames start to drop at random and different resolutions and frame rates begin to fight for the same link. A CSI-2 aggregator gives me a link-level traffic manager that turns many camera streams into one or two well-behaved outputs with controlled frame drops and clear priorities.

For example, a surround view system with four 2 MP cameras at 30 fps already pushes several gigabits per second of raw data. If I add a higher frame rate front camera or a DMS camera, the combined load can easily overrun a single MIPI port unless I plan the bandwidth and arbitration. I treat the CSI-2 aggregator as a hard-wired traffic manager at the link layer, not as a magic ISP box or a depth engine, so I stay focused on who sends data, in what order and under which overload rule.

• Limited MIPI CSI-2 ports on my ADAS SoC.
• Mixed resolutions and frame rates across cameras.
• Need deterministic behavior under overload conditions.
• Critical views must keep their frame rate even when others drop.

System context and signal flow

In my mental picture, the CSI-2 aggregator sits between the camera deserializers and the ADAS SoC or accelerator. Cameras send image data through FPD-Link or GMSL, the deserializers turn those links back into CSI-2 streams, and the aggregator is the first place where I can merge, arbitrate and monitor all of those streams together. Beyond the aggregator, the SoC or vision processor handles ISP, HDR and algorithms, while PCIe switches and data loggers take care of recording.

When I sketch the pipeline, it is always cameras → serializers → FPD-Link or GMSL → deserializers → CSI-2 aggregator / bridge → SoC or accelerator. The deserializers simply recover the CSI-2 links; the aggregator performs multi-camera merge and traffic control; and the downstream SoC and storage blocks work on processed pixels or logged data. Keeping this boundary clear helps me avoid mixing ISP or time-sync topics into what should stay a pure link-level traffic function.

• Upstream: FPD-Link or GMSL deserializers producing CSI-2 streams.
• Middle: CSI-2 aggregator / bridge merging and arbitrating cameras.
• Downstream: ADAS SoC or accelerator consuming CSI-2 inputs.

Traffic and bandwidth planning

Before I pick a CSI-2 aggregator, I turn every camera idea into a rough bandwidth number. Resolution, frame rate and pixel depth translate into gigabits per second per stream, and the sum of those streams has to sit well below the aggregator’s data sheet limit. If my math already pushes the link to the edge, I know random frame drops and corner-case overloads will be waiting for me later in the project.

In practice I only use these bandwidth numbers as an engineering estimate, not as a signal-integrity simulation. I add up the contributions from each camera, include protocol overhead and then keep at least 20–30% headroom for bursts, duty-cycle changes and unexpected features. Event-style or low-duty cameras can look harmless on average, yet still line up with my main front camera at exactly the wrong time if I do not plan for them.

Burst-heavy and low-duty cameras need special attention. A lane-assist or parking camera that only wakes up occasionally can still collide with my front camera at the worst possible moment. When overload is inevitable, I decide up front whether I will drop entire frames on secondary cameras or step down their resolution so that my safety-critical views stay within their minimum frame rate.

• I try to keep total estimated load under 70–80% of the aggregator spec.
• I group cameras with similar resolution and frame rate into the same arbitration group.
• I lock in a minimum FPS for critical views first, then share whatever is left with side and helper cameras.

Arbitration policies and QoS

Once I understand my bandwidth numbers, the next question is who gets served first when the link is stressed. CSI-2 aggregators often offer fixed priority, round-robin or weighted arbitration, but the data sheet labels alone do not tell me how my front, rear and side cameras will behave when the bus is close to saturation. I translate each mode into real frame-rate consequences before I commit to a specific device.

Fixed priority keeps one or two critical views at the front of the line and lets less important cameras starve if necessary. Round-robin or time-slice modes try to share bandwidth evenly, which sounds fair but can drag my safety-critical front camera down along with everything else. Weighted or conditional schemes sit in between: they let me assign more slots to the cameras that matter most, sometimes based on vehicle state or driving scenario.

Dropping frames can also be global or per stream. Whole-frame drops on specific helper cameras are easy to reason about, while pattern-based schemes like “drop one out of every N frames” can smooth the frame-rate reduction but introduce subtle timing artifacts. I prefer per-stream policies that protect a minimum FPS for my front camera first and let side or rear views absorb more of the loss.

On a high-speed highway scenario, I might insist that the front camera stays at 30 fps while side cameras are allowed to drop to 15 fps. In that case fixed or weighted priority makes more sense than pure round-robin. If an aggregator only supports a single global scheme, I think carefully about what happens to my safety-critical views in the worst overload case.

Interfaces to SoCs / accelerators

I treat the aggregator output as just another CSI-2 camera in front of my SoC. That means its PHY mode, lane count, data rate, CSI-2 version and virtual channels must match what my SoC or accelerator actually supports. On paper many aggregators show four or eight lanes, but my effective bandwidth always depends on how many lanes my SoC input can lock and validate in real conditions.

If the aggregator only outputs C-PHY while my SoC accepts D-PHY, I have to change the device, add a bridge or limit operating modes. The same applies to virtual-channel support: if I share multiple camera streams on one physical link, my SoC or FPGA must be able to decode and route each virtual channel cleanly. These interface checks are often more critical than the number of cameras I feed into the aggregator.

Diagnostics and fail-safe hooks

The aggregator sees all incoming camera streams, so it becomes a natural point for checking link health. I rely on it to monitor lock status, loss-of-signal events, CRC/ECC error statistics and basic activity flags. If one input becomes noisy or silent, I want clear status bits and possibly an interrupt so the ECU can react.

In overload or fault situations, some devices let me disable a problem camera, switch to bypass mode or hold a fixed arbitration profile. These hooks do not replace system-level safety logic, but they give me usable signals and local fallbacks that help isolate link issues without dragging down the entire ADAS pipeline.

Implementation patterns

Before I pick a specific part number, I decide how I want to implement CSI-2 aggregation at the system level. Some projects are best served with a standalone automotive IC, some justify an FPGA or programmable logic, and others rely on aggregation that is already integrated inside a domain controller SoC. Each pattern trades off flexibility, cost, visibility and how tightly I am locked to a single platform.

A standalone aggregator IC feels like a fixed-function building block that I can drop into many boards. An FPGA gives me room to experiment with custom arbitration or diagnostics but costs more effort and power. When the aggregator is buried inside a SoC, my bill of materials gets simpler, yet my ability to debug and reuse the design on other platforms often goes down.

BOM & Procurement Notes

When I send an RFQ for a CSI-2 aggregator, I turn all the design decisions on this page into concrete fields. That way the supplier can sanity-check my camera mix, bandwidth plan and diagnostics expectations instead of guessing from a vague “multi-camera ADAS” description.

1. Planned CSI-2 inputs and outputs. I state how many camera inputs and how many aggregated outputs I really need (for example 6 inputs to 2 outputs).
2. Maximum resolution and frame rate per camera. I list each camera’s worst-case resolution and fps so the vendor can check total bandwidth and headroom.
3. Per-lane data rate and lane count at the SoC side. I describe what my SoC or FPGA can lock reliably, not just the aggregator’s absolute maximum numbers.
4. Total bandwidth target and desired headroom. I indicate that I want around 20–30% spare capacity for bursts and future options.
5. Required arbitration behaviour. I specify whether I need fixed priority for the front camera, round-robin, or a weighted scheme that protects a minimum FPS on key views.
6. Virtual channel count and mapping. I explain how many camera streams I plan to multiplex on one link and whether I need per-VC monitoring.
7. Diagnostics and watchdog features. I ask about per-input status bits, error counters, alive flags, timeouts and which interrupts are available.
8. Automotive grade and temperature range. I name the required AEC-Q level and operating temperature range for my target environment.
9. Package type and pin pitch. I mention assembly and PCB limits so the package and pitch fit my factory and layout rules.
10. Recommended companion parts. I invite suggestions for matching deserializer families, power and timing components that the vendor sees as proven.
11. Product lifetime and roadmap. I ask how long the part is planned to stay active and whether there are pin-compatible successors on the roadmap.

I treat the supplier as a second pair of eyes on my CSI-2 plan. If they cannot answer these items clearly, it tells me a lot about how the project will feel later when I need support.

FAQs for CSI-2 aggregators

I use these twelve questions as my own checklist when I decide whether to introduce a CSI-2 aggregator, how to configure it and what to ask suppliers. Each answer is short enough to reuse in PAA snippets, internal notes or social posts, and it matches the FAQ structured data one to one.

When my SoC only has a single MIPI input, how do I decide whether I really need a CSI-2 aggregator?

I start by mapping how many cameras I want today and in the next product refresh. If a single MIPI port cannot carry the combined bandwidth with at least twenty percent headroom, or I must share different views and virtual channels on one link, I plan for a CSI-2 aggregator.

When I mix cameras with different resolutions and frame rates, how should I estimate the bandwidth budget for a CSI-2 link?

I approximate bandwidth by multiplying resolution, frame rate and bits per pixel, then adding protocol overhead and a safety margin. I repeat that for every camera, sum the loads, and compare the result against the aggregator specification. If my total math exceeds eighty percent of the limit, I assume the link is tight.

How does fixed priority arbitration versus round robin change the frame rate seen by my critical cameras when the link is overloaded?

With fixed priority, my critical front camera keeps most of the slots and helper cameras may look almost frozen under heavy load. With pure round robin, all cameras lose frame rate together, even the most important view. I choose based on whether fairness or protecting a single camera matters more.

How can I implement a strategy where my key camera keeps its frame rate while other cameras slow down or drop frames first?

I assign the key camera to the highest priority or highest weight and use per stream frame drop settings when the link is near saturation. I define a minimum acceptable frame rate for the key view and let the aggregator reduce frame rate on less critical cameras first until the bandwidth fits again.

In practice, how does the number of virtual channels limit what I can do in a multi camera CSI-2 system?

Each virtual channel is one distinct stream that my SoC must decode and route. If I run out of virtual channels, I cannot simply add another camera without changing the physical links. I also check that my SoC drivers and diagnostics truly support the advertised number of channels in real use.

When one camera link starts to lose lock or suffers from intermittent harness issues, what diagnostic signals can a good CSI-2 aggregator expose?

I look for per input lock and loss of signal status bits, error counters for CRC or ECC problems, and simple alive flags that show recent frame activity. An interrupt that fires when a link repeatedly unlocks or a counter passes a threshold makes it much easier to locate the bad path.

When does it make sense to build my own CSI-2 aggregation in an FPGA instead of buying a standard automotive IC?

I consider an FPGA when I need very custom arbitration or logging, expect the camera map to change often, or am prototyping several ADAS concepts on a single platform. If the architecture is stable and volumes are high, a standard automotive IC usually wins on cost, power and long term maintenance effort.

How does the FIFO depth inside the aggregator really affect system latency and the risk of dropped frames in my design?

A deeper FIFO smooths bursts and clock tolerances but inevitably adds latency between sensor and SoC. If the FIFO is too shallow, random bursts can cause frame drops when the link is almost full. I check that the depth is enough for my worst case bursts without breaking my end to end timing budget.

When I use FPD Link or GMSL to bring cameras into the ECU, what do I need to watch at the interface between deserializer and CSI-2 aggregator?

I check that the deserializer output timing, physical interface mode and data rate match the aggregator input limits and my layout constraints. I also confirm that error reporting and link health information from the deserializer remain accessible once the stream passes through the aggregator so I do not lose root cause visibility.

How do I evaluate the impact of a CSI-2 aggregator on end to end latency from the image sensor to my ADAS algorithms?

I add up the sensor exposure time, serializer and deserializer delay, aggregator FIFO and arbitration delay, and SoC input and processing time. Even if each stage adds only a small delay, the total must stay within my control loop budget. I prefer vendors that can share typical latency numbers and how they measured them.

On ASIL rated projects, what minimum level of diagnostic capability do I expect from a CSI-2 aggregator device?

I expect clear detection of loss of signal, lock instability and data integrity errors on each input, plus counters and documented reaction paths. The device should support interrupts for critical faults and provide guidance on how to integrate these diagnostics into my higher level safety concept and safety analysis.

When I send the first inquiry email to a supplier, which key parameters do I make sure to describe up front for a CSI-2 aggregator?

In my first email I describe the number of cameras, their resolution and frame rate, the SoC MIPI capabilities, the desired arbitration behaviour, virtual channel needs, diagnostic expectations and the required grade and package. That gives the supplier enough context to confirm feasibility and recommend a short list of parts.