DS90UB960-Q1: MIPI-CSI

Hi Juan,

Both architectures are supported by the DS90UB960-Q1. Our recommendations are below.

1. Routing and stream selection
The 960 provides independent forwarding controls for all four RX inputs. Register 0x20 selects each input’s destination, TX0 or TX1, and enables or disables its forwarding.
For Architecture A, enable only one RX toward TX0. For Architecture B, enable one RX toward each output. The other FPD-Link connections can remain running without forwarding their video.

2. VC configuration and camera switching
Present the selected stream using a consistent VC accepted by the receiver, such as VC0. Each physical output may independently use VC0. For CSI-2 inputs, per-RX VC remapping is available through register 0x72.
To switch cameras, disable the old input’s forwarding before enabling the new input. Disable forwarding before changing an input’s output assignment. Keep the CSI transmitter enabled where possible.
The receiver driver must tolerate the transition and wait for a complete valid frame; seamless switching is not guaranteed. Matching camera formats simplifies switching. Changes in resolution, data type or bit depth may require receiver/ISP reconfiguration.
If a camera itself outputs multiple image VCs, such as HDR exposures, those streams require separate consideration.

3. Recommended automotive SerDes options
DS90UB953-Q1 + DS90UB960-Q1: The FPD-Link III line rate is up to 4.16 Gbps per link. The serializer accepts up to four CSI-2 data lanes at 832 Mbps per lane. The deserializer provides two D-PHY CSI-2 outputs, each supporting 1, 2, 3 or 4 data lanes. The maximum output rate is 1.6 Gbps per lane with a 25-MHz reference clock, or 1.664 Gbps per lane with a 26-MHz reference clock.
DS90UB971-Q1 + DS90UB9702-Q1: The FPD-Link IV line rate is up to 7.55 Gbps per link. The serializer accepts up to four CSI-2 data lanes at 1.5 Gbps per lane. The deserializer provides two main D-PHY CSI-2 outputs, each supporting up to four data lanes at 2.5 Gbps per lane, plus an additional replication output. This combination offers greater bandwidth for higher-resolution or higher-frame-rate cameras.

4. Resolution, frame rate and pixel formats
The maximum operating mode depends on bandwidth, packet size and timing rather than resolution alone. Documented examples include 2.3 MP/60 fps and 4 MP/30 fps for 953, while 971/9702 targets 8-MP-and-higher applications. These examples require confirmation against the actual sensor configuration.
RAW8/10/12 and other supported CSI-2 formats can be transported without image-format conversion. The SerDes does not scale images or encode/decode JPEG. NV12/NV21 are generally processor-side memory layouts.
JPEG transport requires confirmation of the camera’s CSI-2 encapsulation and the module driver’s support. Similarly, the module’s 21-MP snapshot capability does not independently establish that a particular sensor mode fits the SerDes link.

5. Output configuration and module compatibility
960 supports 1, 2, 3 or 4 data lanes per output; 9702 supports up to four per main output. Both use D-PHY for this connection.
Both 960 CSI-2 outputs share the same PLL rate setting, while their lane counts can be configured independently.
Confirm the module’s supported lane rates, clock mode, data types and calibration behavior. For 9702, specifically verify its D-PHY v2.1 transmitter configuration against the module’s D-PHY v1.2 receiver requirements.
For Architecture B, also confirm simultaneous dual-interface capture and processing. Higher SerDes bandwidth does not remove SDK or ISP limitations.

6. Information needed to finalize selection
Please provide each sensor’s transmitted resolution, frame rate, bit depth, data type, VC usage, lane count and lane rate, including HDR or embedded data. Please also confirm the acceptable switching interruption.
These details will determine whether 953 + 960 is sufficient or the higher-bandwidth 971 + 9702 solution is needed, and allow us to define the corresponding configuration.

Best regards,

Yue

Hi Yue,

Following our previous discussions regarding the SerDes solutions, we would like to explore an additional architecture for our automotive multi-camera system.

Due to PCB scalability requirements, we are considering a modular camera architecture. Some customers will require camera functionality, while others will not. Therefore, we would prefer to keep the main PCB common across all product configurations and implement the camera system through external modules.

1. Proposed modular architecture

Our idea is to develop an external camera module consisting of:

• One deserializer.

• Up to four cameras, each connected to its corresponding automotive serializer.

• The deserializer would aggregate the camera connections and provide a single output.

This output would then be connected to an additional serializer, which would transmit the aggregated camera data to another deserializer located on our main PCB.

The main PCB deserializer would receive the data from the external module.

Our intention is to support up to four of these external camera modules, each containing one deserializer and up to four cameras with their corresponding serializers.

Each external module would connect to one of the four inputs of the central deserializer on the main PCB.

Conceptually, the architecture would look like this:

External camera module (up to four cameras):

Camera 0 → Serializer 0 ──┐
Camera 1 → Serializer 1 ──┤
Camera 2 → Serializer 2 ──┼── External Deserializer-----External Serializer-----Automotive link-----Main PCB:
Camera 3 → Serializer 3 ──┘

                     Central Deserializer
                     ┌──────┼──────┬──────┐
                     │      │      │      │
                   RX0    RX1    RX2    RX3
                     │      │      │      │
                  Module  Module  Module  Module
                     0      1      2      3

This would allow us to connect up to four external camera modules, potentially supporting a total of sixteen cameras, while keeping the main PCB design independent of the number of cameras installed.

2. Technical feasibility

We would appreciate your engineering team's assessment of whether this cascaded SerDes architecture is technically feasible using TI automotive serializer/deserializer devices.

In particular, we would like to clarify the following:

1. SerDes cascading: Is it possible to connect the CSI-2 output of an external deserializer to a serializer and then transmit the aggregated camera data to a second deserializer located on the main PCB?

2. Multiple camera streams: Can the first deserializer aggregate the video streams from up to four cameras and forward them through a single serializer-to-deserializer link without losing the individual camera streams?

3. Virtual channels: Can the camera streams maintain their individual VC-ID assignments throughout both SerDes stages? Are there any limitations concerning VC-ID remapping or the number of virtual channels supported across cascaded devices?

4. Camera selection: Would it be possible to select and forward individual camera streams at either the external module or the main PCB deserializer, while keeping the other camera connections active?

5. Bandwidth limitations: What would be the bandwidth limitations of this architecture? Would the second serializer/deserializer link be able to transport the aggregated data from four cameras simultaneously? How should the bandwidth be calculated across both SerDes stages?

6. Electrical and physical compatibility: Are there any electrical, signal-integrity, clocking, synchronization or PCB layout limitations associated with cascading these devices? Are there any particular requirements concerning CSI-2 clock modes, lane configurations or reference clocks?

7. Latency and image quality: Would this architecture introduce any significant additional latency or affect the original image quality? Can the video data be transported through both SerDes stages without image compression or format conversion?

3. Recommended TI solution

We initially considered the DS90UB953-Q1 + DS90UB960-Q1 combination, as well as the DS90UB971-Q1 + DS90UB9702-Q1 combination.

However, considering this new modular architecture, we would appreciate your recommendation regarding the most suitable automotive-qualified serializer/deserializer components.

In particular, we would like to know:

• Whether any of the aforementioned devices support this cascaded architecture.

• Whether you recommend a different serializer/deserializer family for this application.

• Whether there are dedicated CSI-2 aggregation devices, camera hubs, CSI-2 controllers or other solutions that would be more suitable than cascading two SerDes stages.

• Whether a different architecture would offer better bandwidth, scalability, latency and image quality.

Our objective is to develop a reliable and scalable automotive camera platform that can support up to four external modules, each potentially containing four cameras, while maintaining the highest possible image quality and minimizing the complexity of the main PCB.

We would greatly appreciate your technical recommendations and any reference designs or application notes related to this type of architecture.

Thank you in advance for your support.

Best regards,

Juan