CX3: receiving max speed (2.4Gbps) bursts

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
NiMa_2741046
Level 1
Level 1

Hi,

with my CX3-based board and my FW I'm currently able to receive bursts (lines, or HS packets) at 2.4Gbps, which is the maximum nominally supported by the 24-bits 100 MHz max parallel interface, but only as long as the burst size (HS packet payload) is less than around 9 kB.

This makes some sense because so far I've not been able to use the maximum clock speed on the parallel interface, as I'm stuck with the following somehow working configuration, that results in a parallel bus clock of 96 MHz:

CyU3PMipicsiCfg_t cfg;

cfg.dataFormat = CY_U3P_CSI_DF_RGB888;

cfg.numDataLanes = 4;

cfg.pllPrd = 2;

cfg.pllFbd = 119;

cfg.pllFrs = CY_U3P_CSI_PLL_FRS_250_500M;

cfg.csiRxClkDiv = CY_U3P_CSI_PLL_CLK_DIV_4;

cfg.parClkDiv = CY_U3P_CSI_PLL_CLK_DIV_4;

cfg.mClkCtl = 0;

cfg.mClkRefDiv = CY_U3P_CSI_PLL_CLK_DIV_2;

cfg.hResolution = 0;

cfg.fifoDelay = 0;

CyU3PMipicsiSetIntfParams(&cfg, CyFalse);

In my understanding in this configuration the FIFO slowly fills up (as it is filled at 100 MHz and emptied at 96 MHz) and it overflows when the burst/line/packet payload is too big. Please note that I did not find, experimentally, any influence of the hResolution (BYTE_COUNT) parameter: any value there leads to a working case.

On the other hand I verified experimentally that the fifoDelay parameter has the expected effect: I need to use low values to keep the configuration working, otherwise I observe silently corrupted captured data, the same problem that I see when I increase the payload size.

So I have a qualitative explanation for this somehow working configuration, even if I'm still struggling with the quantitative part (but the size of this FIFO is not well described in the available documentation). I'm also not sure that there is no way of being notified of a FIFO underflow/overflow (rather than checking the captured data), but this is my understanding as of now.

This said, my current problem is that the following very similar configuration is not working at all:

CyU3PMipicsiCfg_t cfg;

cfg.dataFormat = CY_U3P_CSI_DF_RGB888;

cfg.numDataLanes = 4;

cfg.pllPrd = 2;

cfg.pllFbd = 120;

cfg.pllFrs = CY_U3P_CSI_PLL_FRS_250_500M;

cfg.csiRxClkDiv = CY_U3P_CSI_PLL_CLK_DIV_4;

cfg.parClkDiv = CY_U3P_CSI_PLL_CLK_DIV_4;

cfg.mClkCtl = 0;

cfg.mClkRefDiv = CY_U3P_CSI_PLL_CLK_DIV_2;

cfg.hResolution = 0;

cfg.fifoDelay = 0;

CyU3PMipicsiSetIntfParams(&cfg, CyFalse);

The only difference, in my understanding, is that I'm trying to use a 96.8 MHz clock rather than a 96 MHz one, so that the FIFO should still be slowly filling up, but slower than in the working configuration. I would expect this slower filling rate to increase the maximum payload size.

Unfortunately in this second configuration I'm not able to receive a single byte: nothing happens and a time-out gets triggered at application level (PC-side) without anything being signaled on the CX3 side (I don't have any watchdog there). The pllFbd value is the only difference in the entire application comparing the two configurations.

My sensor is clocked autonomously, so I'm not using MCLK.

Please note that my original goal was using pllFbd = 125, for obtaining the targeted 100 MHz clock, but in that case the behavior is identical to the 120 case described above; actually I landed on the 119 value by experimenting and on top of unexplained failures with higher values.

Any clue of what is happening here ?

Thank you and best regards, Nicola.

0 Likes
1 Solution

Hi Nicola,

The MIPI CSI configuration tool will calculate the bandwidth requirement from the parameters that you enter in the "Image Sensor Configuration" Tab.

Also the tool will calculate the minimum parallel clock required to transfer the data without any data loss (FiFO overflow). If you configure the the MIPI bridge such a way that the parameters are within the range, then it is unlikely that FIFO overflow occurs.

View solution in original post

0 Likes
6 Replies
KandlaguntaR_36
Moderator
Moderator
Moderator
25 solutions authored 10 solutions authored 5 solutions authored

Here is the info. regarding FIFO Delay:

FIFO delay:

It is necessary that the output data rate should be greater than or equal to the input data rate to prevent data loss.

When you are keeping the Pixel clock same as minimum suggested by the tool the output and input data rate will be equal. There is a chance that the output parallel pixel clock is set higher than the minimum value suggested by the tool. In this case fifo delay is necessary.

                              pastedImage_0.png

Fifo delay adds delay to the parallel output at the beginning of each line. Minimum value of the fifo delay is calculated as follows:

Hactive (MIPI CSI-2)- Hactive (parallel).

The maximum value of the fifo delay time will account the internal line buffer as well. The tool will automatically take care of this calculation.

FIFO delay parameter should be carefully chosen such a way that the current MIPI Line data should be sent out completely over the parallel interface before the next MIPI line data arrives. If this rule is violated, vertical splits can be observed in the video frame.

When you increase the pllfbd to 120 MHz or higher, the PCLK is increasing beyond 96 MHz.

Please set clockConfig.setSysClk400 = CyTrue in Main function ad check.

Ok, by setting clockConfig.setSysClk400 = CyTrue I have been able to overcome the limitation to 96 MHz on the parallel bus, but I still have problems:

  1. if I set pllFbd to 124 (maximum theoretical value, leading to 100 MHz PCLK) I'm still not able to sustain a 12 KB line payload (@ 2.4 Gbps); streaming apparently works, but I get corrupted data on the PC over USB
  2. if I set pllFbd to 125 (outside specs, leading to a 100.8 MHz PCLK) I'm able to sustain a 12 KB payload, but not a 12.3 KB one; in the second case, again, streaming apparently works, but I get corrupted data on the PC over USB

My final target would be to sustain a line payload of 24 KB, so I'm still quite far ...

Please note that with any frequency that I tested I obtained the larger working payload by setting fifoDelay = 0, so it seems that for some reason my fifo is still always filling up.

Is it possible to know

  1. how long this FIFO is (in 24-bits words, I guess) ?
  2. whether the fifoDelay value is expressed in 24-bits words or something different ?
  3. which clocks domains the two endpoints of this FIFO are connected to ?
  4. whether this is the only FIFO in charge of absorbing intra-line data-rates mismatches or there are other ones (either upstream or downstream) ?
  5. whether it is expected or not that the FIFO over/under-flows silently ?

Thank you and best regards, Nicola.

0 Likes

Hi Nicola,

1)The internal FIFO size is 511 words(32 bit)

2) The fifo delay value is expressed in 32 bit words.

3)The buffer is filled based on the CSI clock.

4)Yes. CX3 has additional DMA buffers to hold the video data before sending to the USB host.

The FIFO will temporarily store the line data before sending it to the GPIF II interface of CX3 (mainly during the serial to parallel conversion).

5)If there is any mismatch in the data rates then the FIFO will over/underflow.

Can you please provide the following details to debug further?

a)What is the resolution that you are trying to stream?

b)Can you please let me know the video format and the fps?

c)By HS payload size , do you mean the line size (i.e pixels/line * bytes/pixel)?

d)Can you please provide us the following : MIPI CSI clock value, number of data lanes and Horizontal/vertical blanking values?

0 Likes

Hi Keaj,

thanks for your reply. My fifo-overflow problem has been explained and solved recently, when I realized that the D-PHY receiver was receiving a 720 Mbps/lane transmission rather than a 600 Mbps/lane one; this was due to a mis-implementation of the sensor.

Anyway the first and the second run of clarifications that I obtained in this discussion were useful.

I think that my 5th question above is not yet fully answered as I was asking about the fact that FIFO over/underflows are not signaled when they occur: is this missing signaling expected or due to something that I did not manage to configure properly ?

Anyway this is not blocking me anymore.

Thanks again, Nicola.

0 Likes

Hi Nicola,

The MIPI CSI configuration tool will calculate the bandwidth requirement from the parameters that you enter in the "Image Sensor Configuration" Tab.

Also the tool will calculate the minimum parallel clock required to transfer the data without any data loss (FiFO overflow). If you configure the the MIPI bridge such a way that the parameters are within the range, then it is unlikely that FIFO overflow occurs.

0 Likes

Hi Keaj,

ok, I understand that it is confirmed that by design there is no way of being notified in case of over/underflows of that FIFO.

Thank you, Nicola.

0 Likes