UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Contributor
Contributor
993 Views
Registered: ‎04-10-2018

Clocking problems with Native Video MIPI CSI-2 Tx

Jump to solution

Hello Guys

 

I'm trying to send some videos from a Kintex 7 with the IP CSI-2 Tx. I'm using a native video generator to send a RAW12 pattern with 400 Mbps for 4 lanes.

 

Based on the clocking section from IP User Guide, the s_axis_clock I'm using is 165 MHz. However, this value "corrupts" my signal, and The signal has lost bytes. If I ignore the rule that the input bandwidth need to be 20-30% greater than output, and use a s_axis_clk of 133MHz, my signal works right.

 

Now, I'm trying to change my line rate to 800 MHz, which the s_axis_clk recommended is between 320 and 346 MHz, but without the margin is 266 MHz. But, for all of this values, my signal is corrupted.

 

How can I calculate my signal s_axis_clk? By the clocking section:

 

Note: For data type interleaving with native video interface, select data types with similar pixel widths to avoid under-run or line buffer full. For example, RAW8, RAW10

 

What is a "similar pixel width"? I don't understand what is the modification to native video.

 

Thank you for help.

 

Regards

 

Marcos

 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
907 Views
Registered: ‎10-04-2017

Re: Clocking problems with Native Video MIPI CSI-2 Tx

Jump to solution

Hi @marcos.bissiano,

 

Thank you for clarifying that you are using native mode. The calculation is not the same for native mode. Also, I do not recommend using native as the AXI-stream mode is simpler.

 

If you choose to use native mode, the ready signal does not exist please monitor the overflow and under run bits as they will tell you if you have an issue.

 

If you choose to use AXI-S. Please monitor the overflow, under run, and tready bits as they will confirm if you have an issue. If you are following the equation this should not happen. If it is happening, please include more information.

 

4. You are initializing your stream from TX back to RX and not in the other order. Let
I don't understand this question.

Let me clarify. The order of initialization should be the MIPI TX core first, followed by the TPG, then any other IP before the TPG. This is an output to input order of initialization. 

 

Regards,

Sam

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
4 Replies
Highlighted
Moderator
Moderator
930 Views
Registered: ‎10-04-2017

Re: Clocking problems with Native Video MIPI CSI-2 Tx

Jump to solution

Hi @marcos.bissiano,

 

The note you are referencing is for sending multiple data types, which does not apply to your system.

 

The formula you need is:

 

When the effective pixel width is less than or equal to (<=) 32, the s_axis_aclk should be
selected such that the input bandwidth is at least 20-30% more than the output bandwidth.
For example, s_axis_aclk*Pixel_width*Pixel_Mode > TxByteClk*No_Lanes*8.
Where s_axis_aclk*Pixel_width*Pixel_Mode is approximately equal to 1.2 or 1.3
times of (TxByteClk*No_Lanes*8).

 

In your case, Line rate is 400Mbps -> txByteclkhs = 400Mbps = 50Mbps

 

s_axis_aclk*Pixel_width*Pixel_Mode > TxByteClk*No_Lanes*8

s_axis_aclk*Pixel_width*Pixel_Mode > 50MHz*4(lanes)*8

s_axis_aclk*RAW12*(1,2,4)> 2000MHz

s_axis_aclk*(1,2,4)> 166MHz

 

You are left with your AXI clock * your pixel mode of 1, 2, or 4 needs to be greater than 166MHz.

 

If you are following this suggestion and you are still losing data, please check:

  1. That you are not losing data upstream. (Before it gets to the TX core)
  2. That the TX core is not reporting under-run 
  3.  TREADY does no go low on the AXI bus. Also reported as a buffer full condition.
  4. You are initializing your stream from TX back to RX and not in the other order.

If any of these happen, you can lose data.

 

Regards,

Sam

 

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
Contributor
Contributor
912 Views
Registered: ‎04-10-2018

Re: Clocking problems with Native Video MIPI CSI-2 Tx

Jump to solution

Hi @samk, Thank you for answer.

 

To your questions:

1. That you are not losing data upstream. (Before it gets to the TX core)
I'm using a video native interface between my test pattern and MIPI CSI-2 Tx IP core. The signal is looking right until the input of CSI IP core.

2. That the TX core is not reporting under-run
    I fixed some probes with the Vivado Analyzer internally the IP core. I discuss the results bellow.

3. TREADY does no go low on the AXI bus. Also reported as a buffer full condition.
Are you talking about the AXI-Streaming bus? When I was working with AXIS in the input of core, the TREADY of CSI always down to low during the line transmition.

4. You are initializing your stream from TX back to RX and not in the other order.
I don't understand this question.

 

As I sad, I monitored the signals in under-run and FIFO full. The under-run register still in silent for all my test, which makes me believe that is not the case. In the other hand, the FIFO full start to go high some clocks after the frame starts:

 

img_01.jpeg

 

Triggering the FIFO line full register, it's possible to see a sequence where the FIFO line full is practically constant high.

 

img_02.jpeg

 

In my oscilloscope, the lines are empty in the middle of the frame. Below, a zoon in the problematic part:

 

img_04.jpg

 

img_03.jpeg

 

Before this part, I was using an AXI-Streaming interface between the TPG and the MIPI CSI-2 Tx IP core. I remember the TREADY of the MIPI was being low during the line transmission, following the recommendation of the User Guide. In this case, the throughput of the input is greater than the output. Is safety to me follow this rule for the Native Video once the TPG cannot know if the CIS is ready or not to receive? Exists other calculus for this case?

 

Thank you for the help

 

Best Regards

 

Marcos

0 Kudos
Moderator
Moderator
908 Views
Registered: ‎10-04-2017

Re: Clocking problems with Native Video MIPI CSI-2 Tx

Jump to solution

Hi @marcos.bissiano,

 

Thank you for clarifying that you are using native mode. The calculation is not the same for native mode. Also, I do not recommend using native as the AXI-stream mode is simpler.

 

If you choose to use native mode, the ready signal does not exist please monitor the overflow and under run bits as they will tell you if you have an issue.

 

If you choose to use AXI-S. Please monitor the overflow, under run, and tready bits as they will confirm if you have an issue. If you are following the equation this should not happen. If it is happening, please include more information.

 

4. You are initializing your stream from TX back to RX and not in the other order. Let
I don't understand this question.

Let me clarify. The order of initialization should be the MIPI TX core first, followed by the TPG, then any other IP before the TPG. This is an output to input order of initialization. 

 

Regards,

Sam

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
Contributor
Contributor
855 Views
Registered: ‎04-10-2018

Re: Clocking problems with Native Video MIPI CSI-2 Tx

Jump to solution

Hello @samk

 

I'm using a Video Timing Controller IP core with a RTL to create a video native TPG. However, I think this IP core is not indicated to use in a large frame rate, once my MIPI core doesn't indicate its status to TPG.

 

I monitored the under-run and the FIFO-full status register, and when I reduce the axis_aclk, the first starts to occour, but the second one doesn't stop.

 

After a discussion with a work partner, and for my project specification, we intend to return to use the AXIS interface and the Xilinx TPG.

 

I'm confident this change will correct my problem.

 

Thank you for the help.

 

Regards.

 

Marcos