The HSB outputs two channels of camera data via the same MIPI interface, resulting in data interleaving when received by the host

Hi,

I have two cameras that use virtual channels to share the same MIPI interface. The HSB packages the data from both cameras and sends it to the host.

I have found that the data received by the host is a mixture of data from the two cameras. What could be the reason for this?

Hi Tom,

HSB doesn’t have native support virtual channels since it’s not a camera / mipi specific platform. The IP doesn’t decode the virtual channel number and split the data accordingly, hence, you see all camera data from different virtual channels packed into a single stream. There’re some simple modifications you can do outside of the HSB IP to demux the VC channels into two data streams.

Regards,

John

Hi wjohn,

Thanks for the clarification.

I have already implemented the VC-to-VP mapping outside the HSB IP. In my current setup, the MIPI virtual channel information is extracted and mapped to separate Virtual Port streams before reaching the HSB
packet logic, and the source identity is passed through to the frame header.

The VC-to-VP mapping is straightforward: VC = 0 is mapped to VP0, and VC = 1 is mapped to VP1.

However, the host still receives mixed/interleaved data from the two cameras that share the same MIPI interface. Since the HSB IP-side preparation is in place, I would like to ask for your support on the fol
lowing points:

  1. Does the HSB IP natively support two Virtual Ports originating from the same physical MIPI interface, or does it assume each VP comes from a separate sensor interface?
  2. Are there any HSB IP-side configurations (register settings, masks, routing tables, etc.) that must be set for this scenario?
  3. On the host side, what is the correct way to verify that the two streams are separated? Should I rely on the image_sensor_id field in the COE header, or is there additional metadata I should check?
    I can provide register dumps or capture logs if that helps with the diagnosis.

Hi Tom,

What specifically do you mean by “the source identity is passed through to the frame header”?

To implement the VC-to-VP mapping, I would do the following:

  1. In the Hololink DEFs file, instantiate two Sensor RX (SIF) interfaces.
  2. Demultiplex the MIPI stream upstream of Hololink.
  3. Send VC0 to SIF0 and VC1 to SIF1, preserving independent AXI-Stream framing, especially tvalid, tready, and tlast.

From there, software can configure the two sensors independently. Hololink does not require the two SIF inputs to originate from separate physical MIPI interfaces. Once the virtual channels are presented on separate SIF ports, they are treated as independent streams.

Packets from the two streams will be interleaved on the Ethernet link due to arbitration. This is expected, but data from different SIF inputs should not be mixed within a single packet, and the data will arrive in independent memory locations.

Hi, csimpson

Thank you for your reply. This solution is feasible.