Virtual CSI, IE splitting 4 Lane CSI to 2x 2 Lanes to run 4 cameras IMX95

Technical Support
, , ,
1

Hi its been a while but I’m looking at this topic again.

We’re looking at the next version of our product and I wanted to investigate this feature again and how to implement it.

I understand the 2 quad lane CSI ports on the imx95 can be split to run 2 cameras per port. But how does this work in practice? And how do you split the CSI CLK diff pair?

My understanding is that the cameras provide the clk and data for each stream. So how does 2 cameras sink their clocks to some how run down 1 CSI CLK line?

Is there any middle hardware required for this kind of wire up?

I’m also taking some assumption that the built in ISP can handle 4 1080P streams at around 30 FPS?

And as well, what changes do I need to make to the DTS or other config software to enable this virtual csi splitting feature?

If you can let me know that would be great. As we will be ordering an aquila dev kit soon.

Kind regards

Simon

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Multi-Camera Setup on i.MX95 with Virtual CSI Splitting

Hi Simon,

Based on the available documentation, I can provide some insights about multi-camera configurations, though the specific details about i.MX95 virtual CSI splitting aren’t fully covered in the current sources.

Multi-Camera Configuration Concepts

From the community discussions, there are several approaches for connecting multiple cameras to Toradex modules (1):

  1. USB cameras: Multiple USB cameras can be connected if there are sufficient USB ports and system bandwidth
  2. CSI cameras: Limited by the number of available CSI interfaces on the SoM
  3. Bridge/MUX solutions: Using external hardware to connect more cameras to MIPI CSI interfaces (1)

Hardware Requirements for CSI Splitting

You’re correct that additional hardware is typically required for splitting CSI interfaces. The documentation mentions that you can use “some kind of bridge/MUX” to connect more than two cameras to MIPI CSI interfaces (1).

For the clock synchronization challenge you mentioned, this would indeed require specialized hardware that can:

  • Manage clock domain crossing between multiple camera sources
  • Multiplex the data streams appropriately
  • Handle the MIPI CSI-2 protocol requirements

Device Tree Configuration

For device tree modifications, you would need to follow the standard Toradex device tree customization process (2) (3):

  1. Choose the base device tree that matches your hardware platform (3)
  2. Customize the device tree to reflect your specific hardware configuration (2)
  3. Compile and deploy the modified device tree (3)

The device tree customization would involve creating custom camera nodes and configuring the CSI interface mappings according to your specific hardware setup (2).

Limitations of Available Documentation

The current documentation doesn’t provide specific details about:

  • i.MX95 ISP performance specifications for 4x 1080P@30fps streams
  • Exact virtual CSI splitting implementation details
  • Specific bridge/MUX hardware recommendations
  • Detailed device tree examples for multi-camera configurations

Recommendation

Since you’re planning to order an Aquila dev kit, I’d recommend:

  1. Testing with the standard supported camera configurations first
  2. Investigating the specific bridge/MUX hardware solutions that are compatible with your requirements
  3. Consulting the i.MX95 reference manual for detailed ISP capabilities

The community has discussed similar multi-camera scenarios (1), but the implementation details would depend heavily on your specific hardware choices and performance requirements.

Best regards, Toradex AI Assistant.

3

Hello @Simon_RN,

In fact the MIPI-CSI interfaces of the i.MX95 support up to 4x cameras per port.
For a total of 8x cameras.
This is done with MIPI-CSI Virtual Channels.

The MIPI-CSI virtual channels are effectively tags that are added to the MIPI-CSI data indicating which camera they came from.
You cannot have virtual channels just by routing some lanes to one camera and some lanes to another camera.
To use virtual channels you need a virtual channel aggregator.

Most use cases use an IC that combines virtual channel aggregation with deserialization from a coax transmitter, for longer distance installations.
In such setup, you could use, for example, a serializer connected to each camera: https://www.ti.com/product/DS90UB953-Q1
And a deserializer + virtual channel aggregator on the main system: https://www.ti.com/product/DS90UB960-Q1

For the long range enablement, there are other solutions similar to TI’s FPD Link, such as GSML.
I expect that there are similar ICs in the GSML ecosystem for such aggregation.

However, if you need to deal with dissimilar cameras or have no need for the longer range provided by the approaches above, a virtual-channel aggregator IP in a small FPGA may be an alternative: https://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/ReferenceDesigns/ReferenceDesign04/Nto1

I hope this helped clarify the topic of MIPI-CSI Virtual Channels.

Best Regards,
Bruno

4

Hi Bruno thanks for getting in touch. That indeed does clear things up a lot. Ill look into the ICs now. In our case for the V2 of the project, itll be like what we’re currently doing 4 camera to two verdins. But with the new version to a single SOM. Likely the Aquila.

We dont need coax in this case, but would one of these ICs (still to look at them) work for the csi combination? So it can then go to the csi port?

5

Hello @Simon_RN,

If you don’t need the extra range, these ICs would still be suitable.
I am not 100% sure they are the most cost-effective solution in this case, but they can perform the job.
You could have:
4x (MIPI-CSI Camera → DS90UB953) → 1x DS90UB960 → 1x or 2x MIPI-CSI on the SoM

The number of MIPI-CSI channels (1x or 2x) used will depend on the required bandwidth for your cameras.

Best Regards,
Bruno

6

Ok so the 960, can split to 2 mipi ports So I connect 4 cameras to the 953 in 2 lane mode, and 960 to all 8 lanes of both ports? And write some driver to configure those chips i assume?

7

Hello @Simon_RN,

When talking about virtual channels, lanes are only relevant for bandwidth.
For example, if you have 4x cameras that each need 1Gb of bandwidth, you could connect the DS90UB960 to a single MIPI-CSI interface (with 4x lanes) on the SoM.
The cameras would would connect to the DS90UB953 with any number of lanes.
Due to Limitations on the DS90UB953 (832Mbps per lane), you would actually need at least two lanes for each of the 1Gb cameras on the example above, so you would have “8x or 16x camera lanes” turning into 4x lanes from the DS90UB960.
Between the DS90UB953 and the DS90UB960 what is serialized is mainly the video data, not the MIPI-CSI lanes.
The DS90UB960 will take the video data, package it back to MIPI-CSI and tag it to the respective camera so that the SoC can differentiate between the virtual channels.

Best Regards,
Bruno

8

Do the serialiser/deserliser chips also handle the I2C to each camera as well? Targeting each camera paired with each lanes…

I still need to look at the chips in depth, not had a chance yet.

At the moment we cant set camera addresses so they’re fixed.

9

Hello @Simon_RN,

Yes, at least for the mentioned parts here I2C goes over the serialized connection as well, being available to the OS as a virtual I2C interface.

Best Regards,
Bruno