06-26-2018 11:48 PM - edited 06-29-2018 06:45 AM
I have ported a design from a Kintex-7 to a Kintex UltraScale device. I have changed the primitives but get now a huge delay in the OBUFTDS elements (see path analysis).
Additionally it seems, that the OSERDES component is not recognized correctly by the timing analyzer.
In the Kintex-7 the OSERDES clock is used, in UltraScale the driving register instead.
Note: The ODELAY is missing in the UltraScale, since I thought that this might cause the delay initially.
I have used Vivado 2017.4 and 2018.2.
Thank you already for your help,
07-03-2018 01:36 AM - edited 07-03-2018 05:26 AM
I have done some further investigations and found out, that the timing issue arises also with other primitives (IOBUFDS), as soon as the IO standard is set to LVDS. Am I missing something crucial or is this a bug in Vivado?
Update: Attached is the schematic of the above described circuit.
I'd really appreciate any comment :)
07-03-2018 05:34 AM
I will look into this issue.
This looks issue to me as 890ns huge primitive delay.
Are you getting expected results with 2017.4? Is this issue associated with 2018.2?
Can you please share the path report for 2017.4 and 2018.2 for cross check at my end? If possible is it possible to share the test case?
07-03-2018 06:07 AM
thanks for your reply.
The issue is in both versions. Attached are the path reports (first figure is 2017.4).
Another strange thing: If the T pin of the OSERDES is connected to something else (e.g. the clk), the path analysis is again different (third figure, Vivado 2017.4).
I'd prefer to send the test design via Email, if possible.
Thank you very much,
07-03-2018 06:09 PM
I am also seeing this same problem when using these primitives on a XCVU440. I see this with Vivado 2017.4 and 2018.1. I am very interested in the solution Xilinx provides.
07-03-2018 11:43 PM
07-09-2018 02:55 AM
Hi Sebastian, I tried to run synthesis and Implementation using the Vivado 2018.2 (As this is the latest version of vivado). Everything works well no issue while migration but when I try to find out the timing path mentioned in your earlier post there is no valid path available. I query for all OBUFTDS in the design no result found. I have attached the snapshot for your reference. Thanks, Yash
07-09-2018 05:41 AM
The code i've sent to you represents run_2 (with commented out IO standard LVDS attribute). There Vivado inserts a OBUFTDS_DUAL_BUF with default IO standard.
You can just open run_1 and have a look at the netlist for the leaf cell OBUFTDS_inst. Or comment in the lines 130-132 where the IOSTANDARD LVDS attribute is located and rerun implementation.
07-12-2018 09:11 AM
The Kintex UltraScale DS (DS892) (https://www.xilinx.com/support/documentation/data_sheets/ds892-kintex-ultrascale-data-sheet.pdf ), mentioned the IOB performance in Table 28, on page 29. The LVDS Toutbuf_delay_td_pad of 890.28ns for many of the speed grades.
07-12-2018 11:23 PM
thanks for your reply.
Why is there a factor of 1000 (!) compared to other IO standards?
It seems to be a general delay for all speed grades in the HP IOs. Even in the HR IOs it is way higher (105 ns) for the LVDS IO standard.
Are there (intended?) shift chains inserted or how is it possible to get these value?
07-13-2018 08:33 AM
The IO Standard delays are based upon measured characterization data for the device family. These values surprised me when I saw them in the datasheet for the first time. The silicon team did confirm that these values are correct and these IO Standards do have this much delay.
07-19-2018 11:01 AM
The LVDS Toutbuf_delay_td_pad of 890.28ns for many of the speed grades.
Really??????????? This is more than just a bit hard to believe...
This seems to be saying (essentially) - you cannot tristate LVDS signals. The existence of a tristate pin is there only for "long term power savings" - once you place an LVDS pin in High-Z mode, you need to wait a "looooooong" time before you can use it after taking it out of High-Z mode...
06-24-2019 07:21 AM
It is suprising that this IOSTANDARD has so much delay. Although, there is a necessity to use this exact IOSTANDARD for specific implementations like DP AUX.
Is there any root cause for it?
Could you help me with how I should constrain this IO pad so that this slack does not show up/ is accounted for in the timing. I have four digit slack violation because of this IO.