cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
djuara
Observer
Observer
777 Views
Registered: ‎11-18-2019

Constrain input delay on MIPI RX lanes

Hi all,

We've a video system which captures video from a MIPI sensor (Emerald 5M - Teledyne) using the MIPI CSI-2 RX IP. We're using 2 lanes and the data rate is 1200 Mbps. The FPGA used is a zu4ev.

We're experiencing some problems in the video at certain temperature ranges. Vivado reports that no input_delay constraints have been applied to the MIPI lanes. We want to add this constraint to the design in order to discard this is the root of our problem. I've been searching for these values on the sensor datasheet but they aren't shown there. Don't know if these values are fixed by the MIPI standard.

Do you have any idea on how can I get the data to constraint this input delay?

Thank you very much in advance.

Diego.

Tags (2)
0 Kudos
10 Replies
karnanl
Xilinx Employee
Xilinx Employee
724 Views
Registered: ‎03-30-2016

Hello @djuara 

MIPI D-PHY has setup/hold time requirement on RX pins as clearly mentioned in the spec.
Please see also picture below:

DPHY_rx_setup_hold.png

So, as long as your system is following this requirement, input_delay constraints is not required in Xilinx device.

If you see some issue in the video at certain temperature ranges,
a. First you may need to check your design if design timing is clean, especially if the issue occurs on some builds and does not occur on others builds.
    Also, perhaps you may need to check if timing constraint in user XDC is not overwriting Xilinx IP timing constraint.
    Please check also if report_methodology and report_drc in your design does not show any critical warnings.

b. If you can ensure that MIPI CSI-2 RX IP does not output a correct video data at certain temperature ranges (while device support this temp ranges)
    Could up please check these two things ?
    (1) Please share the oscilloscope waveform shot of MIPI clock-lane and data-lane during from your system.
          Please ensure that setup/hold requirement above is followed.
     (2) MIPI_DPHY_DCI IO standard requires one reference resistor per bank, 240Ω to GND on the VRP pin.
          Could you please check if the HP IO bank for MIPI IP has VRP pin is connected to 240ohm resistor ?
          ( If this is not the case, please see AR#67565 for a workaround )


Thanks & regards
Leo


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------
0 Kudos
djuara
Observer
Observer
710 Views
Registered: ‎11-18-2019

Hi @karnanl 

Thanks a lot for your answer.

A. We've no timing violations in our design, neither we've added any timing constraint in our user XDC file. Report_methodology and report_drc is giving no critical warnings neither. However, We did see that different builds, changing nothing in the design, generate bitstreams with different behaviour, some works fine, others generate tiny errors on the image, others start failing at 70 ºC, others fail from 40 ºC to 65 ºC and then start to work fine...

B. Right now I can't share the snapshot of the scope, but we've check that requirement before and it was fulfilled. What worries me is the point 2 of your answer. We have the VRP resistor placed with the correct value, however, we beleive it's not working.

As we saw this problem with temperature the first thing we thought was that maybe there is a problem with this VRP resistor. So we test three cases, VRP resistor placed, not placed and VRP pin shortcircuit to GND. What we saw is no matter which design we use (a functional or one with the temperature error), the behaviour was completly the same as if the VRP resistor was placed (The design that worked with the VRP resistor, continued working identically than without it or with the VRP pin shortcircuit to GND, the one that failed continues failing in the same way...).

That make us thing that the VRP pin is not being used for temperature compensation as stated in the Xilinx documentation.

Why do you thing we see that behaviour? Is it normal?

Thank you very much!

Diego.

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
679 Views
Registered: ‎03-30-2016

Hello Diego @djuara 

Noted on issue behavior on your system.

>That make us thing that the VRP pin is not being used for temperature compensation as stated in the Xilinx documentation.

My understanding on DCI calibration :
DCI calibration is done during the device start-up sequence (after configuration process), by default no calibration process run when the device is running.
So DCI calibration will turning on/off DCI transistors to calibrate internal resistor value to match external VRP resistor value during device start-up only.

>Why do you thing we see that behaviour? Is it normal?

I will say this result is possible.

If you are using IO standard with DCI, 240ohm VRP resistor is a must, so internal resistor calibration can be successfully (for MIPI_DPHY_DCI it will be 100ohm).
If you did not connect an expected 240ohm VRP resistor (which mean VRP has unexpected big value), DCI calibration will try to match this big VRP resistor value, it will eventually failed and quit.
Fortunately internal resistor will have a specific range for each IO standard, so even if DCI calibration process failed , the internal resistor value will still near expected result. We do not expect that internal resistor calibration result will be a big value, or zero ohm if you connect VRP pins to the GND.


BTW, you might want to rent an oscilloscope to debug this issue to check if your system is following setup/hold spec requirement.

Is this occurs on your custom board or Xilinx evaluation board ?
Are you able to port your design into ZCU102 board and see if the same behavior observed ?
Does MIPI CSI-2 RX IP register reports error when your system failed ?
-- If MIPI CSI-2 RX IP does not report any error, this is not a MIPI IP issue. You might need to check other modules on the Video pipeline.

Thanks
Leo


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------
0 Kudos
djuara
Observer
Observer
655 Views
Registered: ‎11-18-2019

Hi @karnanl 

Thank for you reply!

I understand from UG571, page 25 "This compensates for changes in I/O impedance due to process variation. It also continuously adjusts the impedances to compensate for variations of temperature and supply voltage fluctuations" that the VRP is used continuously during operation, not only at start. Thats is why we think the behiviour we see is strange.

It occurs in our custom board. We've no access to a ZCU102, but well try it on ZCU106.

On MIPI register dump we get no error flags, but when the system fails, the line length detected by the MIPI CSI Controller is not correct, so explicitly it's not an error but the MIPI IP is failing. Also I have test a design with only the MIPI CSI-2 RX and the framebuffer to store the frames in the DDR, and checking the frames obtained they present the same error.

BTW, the error we're having is that MIPI IP lose lines, then these lost lines are "taken" from the next frame, so we get half the frame rate, and when there are too many errors, the image obtained is kind of sliced and duplicated.

One thing we realised reading the Pin assignment rules of MIPI is that we're not placing the lanes consecutively on the HP bank pins, and this is a recommendation from Xilinx. Could it be root cause of our problems?

Thanks a lot for your help.

Diego

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
622 Views
Registered: ‎03-30-2016

Hello @djuara 

>"It also continuously adjusts the impedances to compensate for variations of temperature and supply voltage fluctuations"

My understanding is with default setting DCI calibration is done during the device start-up sequence only.

>"On MIPI register dump we get no error flags, but when the system fails, the line length detected by the MIPI CSI Controller is not correct, so explicitly it's not an error but the MIPI IP is failing."

AR_65242.png

We have a known issue list for MIPI CSI-2 Receiver Subsystem. Please see also : https://www.xilinx.com/support/answers/65242.html
    If you are using Vivado 2019.2 , please install IP patch from AR#73100.
    If you are using Vivado 2020.1 , please install IP patch from AR#75325.

This behavior could happens if you are using MIPI CSI-2 RX IP from 2019.2 without AR#73100.
MIPI CSI-2 RX IP from 2020.1 also has a known issue (TUSER port is reporting false CRC, ECC and Frame number), it seems not related with the behaviour you see now,
but I would recommend to install patch (AR#75325) and retest your system if you are using 2020.1


>"the line length detected by the MIPI CSI Controller is not correct"

So are you seeing a shorter line-length (than expected), while sensor is sending a fixed line length for a whole frame ?  Could you please elaborate more ?
If this is the case, perhaps your video_aclk frequency is not following PG232 guidance.

Could you please share your MIPI CSI-2 RX usecase ? I can double check for you.
   Line Number = 2-lane
   Line-rate = 1200Mbps
   Pixel Mode = RAW8 ?
   Pixel-per-clock = 1 ?
   video_aclk frequency = >300 ??? MHz

>One thing we realised reading the Pin assignment rules of MIPI is that we're not placing the lanes consecutively on the HP bank pins, and this is a recommendation from Xilinx. Could it be root cause of our problems?

I don't think so. We do suggest to place IO pins consecutively to avoid bg*_pins generation (so pins are not wasted).
I believe there is a performance degradation if you are not following this consecutive placement recommendation.

Thanks ,
Leo


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------
0 Kudos
djuara
Observer
Observer
357 Views
Registered: ‎11-18-2019

Hi @karnanl 
I have already installed the patch AR#75325 and the failing behaviour continues.
Our MIPI CSI-2 RX usecase is:

   Line Number = 2-lane
   Line-rate = 1200Mbps
   Pixel Mode = RAW8
   Pixel-per-clock = 1
   video_aclk frequency = 300 MHz

We've had a sensor sending always the same line length (thus resolution). What we see in the MIPI dump register is when errors occurs, the line length detected by the MIPI RX IP is smaller than the expected, so the result in the image is a lost of lines, which are taken from the next frame, dividing by two the frame rate and creating a sliced image (due to the lost of lines) and doubled (due to the MIPI IP is taking these lost lines from the next frame). I attach an image to clarify (system configured at 20 fps in the image).

What worries us is in our system we have two MIPI sensors, each conected to its MIPI CSI-2 RX, both MIPI IPs and sensors have the same configuration, but we only see the failing behaviour in the same video chain, the other works perfect. So in our system we have the MIPI_interface_0, which is the one that is failing, and the MIPI_interface_1, the one that we haven't seen fail.

To clarify:

Default configuration:

Sensor0 -> Interface0 -> MIPI_IP_0 (fails)

Sensor1 -> Interface1 -> MIPI_IP_1 (works fine)

We've tried to switch the pins used by the MIPI IPs between them, so the interface used by each chain is switched between them.

Test switching MIPI IPs pin configuration results in this setup:

Sensor0 -> Interface1 -> MIPI_IP_0 (works fine)

Sensor1 -> Interface0 -> MIPI_IP_1 (fails)

So it suggests us that the problem is in the interface configured by the MIPI IP.

Hope this info helps.

Thanks a lot.

Diego

mipi_problem-3.JPG
0 Kudos
djuara
Observer
Observer
597 Views
Registered: ‎11-18-2019

Hi @karnanl 


I have already install the patch AR#75325 and the failing behaviour continues.


Our MIPI CSI-2 RX usecase is:
  Line Number = 2-lane
  Line-rate = 1200Mbps
  Pixel Mode = RAW8
  Pixel-per-clock = 1
  video_aclk frequency = 300 MHz


We've had a sensor sending always the same line length (thus resolution). What we see in the MIPI dump register is when errors occurs, the line length detected by the MIPI RX IP is smaller than the expected, so the result in the image is a lost of lines, which are taken from the next frame, dividing by two the frame rate and creating a sliced image (due to the lost of lines) and doubled (due to the MIPI IP is taking these lost lines from the next frame). I attach an image to clarify (system configured to run at 20 fps, you can se how the framerate is divided by two).


What worries us is in our system we have two MIPI sensors, each conected to its MIPI CSI-2 RX, both MIPI IPs and sensors have the same configuration, but we only see the failing behaviour in the same video chain, the other works perfect. So in our system we have the MIPI_interface_0, which is the one that is failing, and the MIPI_interface_1, the one that we haven't seen fail.


To clarify:

Default configuration:

Sensor0 -> Interface0 -> MIPI_IP_0 (fails)
Sensor1 -> Interface1 -> MIPI_IP_1 (works fine)


We've tried to switch the pins used by the MIPI IPs between them, so the interface used by each chain is switched between them.

Test switching pin configuration between MIPI IPs, so the system is organized as follows:

Sensor0 -> Interface1 -> MIPI_IP_0 (works fine)
Sensor1 -> Interface0 -> MIPI_IP_1 (fails)


Hope this info helps.
Thanks a lot.
Diego

mipi_problem-3.JPG
0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
536 Views
Registered: ‎03-30-2016

Hello @djuara 

> Line Number = 2-lane
> Line-rate = 1200Mbps
> Pixel Mode = RAW8
> Pixel-per-clock = 1
> video_aclk frequency = 300 MHz

I do not see any issue with those IP configuration.

>Sensor0 -> Interface0 -> MIPI_IP_0 (fails)
>Sensor1 -> Interface1 -> MIPI_IP_1 (works fine)

>Sensor0 -> Interface1 -> MIPI_IP_0 (works fine)
>Sensor1 -> Interface0 -> MIPI_IP_1 (fails)

My understanding on "Interface1" is { Cable + Connector + Board + FPGA IO pins }.
I see now, I am pretty sure that this is not IP logic issue.

1. When MIPI CSI-2 RX received a shorted line than expected, could you please check video_out_tuser output value ? Is
      video_out_tuser[69:64] shows a correct Data Type value ?
      video_out_tuser[63:48] shows a correct Word Count value ?
      video_out_tuser[1] asserted ?
2. Are generated bg*_pins are left unconnected in your board ?
3. Are you able to choose another interface on your board (other than "Interface1") ?

Kind regards
Leo


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------
0 Kudos
djuara
Observer
Observer
492 Views
Registered: ‎11-18-2019

Hi @karnanl 

Our board is divided in two parts, one is the sensor board and the other is the fpga board. What I mean by interface is sensor connector of fpga board + fpga board + FPGA pins. MIPI lines on both boards (fpga and sensor) are equalized.

1. When the system fails, not always we get a wrong length line on the MIPI IP. Maybe it's only what we see in the register dump, and the line length changes faster than the registers refresh period we're using (watch command in linux). 

Sometimes the MIPI D-PHY is receiving the frames apparently correctly, but we still se some lost lines on the frame. 

TUSER[69:64] -> Is reporting data type 0x2a which is correct (8 bits)
TUSER[63:48] -> Is reporting 0x578, which is the line lingth configured (1400x1024).
TUSER[1] -> Always 0 so no errors are detected on the MIPI IP, however, the system is failing.

BTW, in one bitstream generation (without changing the design), we get the system working over all the temperature range without failing.

2. No bg*_pins are generated, we have all the MIPI pins all together in the bank, but they are not in order (I mean data0, data1, data2 and data3, although we are only using two lanes).

3. No, we only have interface0 and interface1.

Thanks a lot for your reply.

Regards.

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
439 Views
Registered: ‎03-30-2016

Hello @djuara 

Reading your explanation above, I am not sure if this is a MIPI IP issue.


>BTW, in one bitstream generation (without changing the design), we get the system working over all the temperature range without failing.

Fow now, I would suggest to LOC as many LUT/logic as possible so you can proceed with your system verification.

>the line length detected by the MIPI RX IP is smaller than the expected,

You can create a simple counter to measure the length of MIPI RX IP line data, to check if MIPI output is correct.


BTW, This may not a logical suggestion, but do you see any improvement if you try a or b ?
   (a) Are you able to test your system with video_aclk frequency>=301MHz ?
   (b) Are you able to increase "Line Buffer Depth" ?

Thanks & regards
Leo


------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs
Versal Example Designs : LINK
>>------------------------------------------------------------------------------------------------
0 Kudos