03-18-2020 07:59 AM
I am facing timing problem with modules internal to xcvr IP of Vivado, The FPGA that I am using is xcvu37p-fsvh2892-2L-e,
and right now using 48 transceiver lanes each running at 28Gbps , so using 12 quads, each having 4 lanes.
Currently in the design I included only xcvr IP and data generator connector to it , so after implementation I see so many intra clock paths which are inside the module power_good_delay.
Clock in which the design(xcvr) running is 437.5 MHz, time period - 2.285 ns
routing delay coming is around - 3.25 ns
Very strange behavior , as two flops are placed adjacent but routing delay is more than 3 ns,
Please help me with any logical reason to understand this situation and to move ahead using the vivado xcvr IP further for my design.
Below is the snapshot of the path report,
also snapshot of "the placement of the logic related to this path is shown"
Also see in the picture below how two flops are placed adjacent to each other.
Please respond as early as possible.
03-19-2020 04:10 AM
03-19-2020 10:11 AM
The image you posted is chopped off on the right - specifically we need to see the "clocked by ?????" for the source and destination.
However, the problem is probably a hold time problem. When there is a hold time problem between two flip-flops, the tool tries to fix it by inserting routing delay on the net between them. Each path is timed at both slow process corner and fast process corner. What happens is that the tool needs to insert enough delay to fix the hold time at both corners, which implies a lot of routing as fast process corner. However, this long route is now very long at slow process corner (usually there is a 3:1 variation from slow to fast), so this violates the setup check. This explains the very long route between two adjacent flip-flops.
As to why you have hold time problems, there may be multiple problems. The first one, though, is fairly obvious - you have no clock buffer on the clock; you are driving flip-flops directly from the GTY output (I can't tell which one - I presume RXCLKOUT) with no buffer. This means that the clock is locally routed, which results in large clock skews. You should be using a BUFG_GT for buffering this clock.
The second potential problem is that this is constrained by a set_max_delay exception. I have no idea why. If this is a clock domain crossing path (which it may be since I can't see the "clocked by" then it needs a clock domain crossing circuit with an appropriate timing exception; the set_max_delay (without the -datapath_only) is not appropriate for a clock domain crossing path. If this is supposed to be a synchronous path (i.e. from the same clock or from two related clocks) then it should not have an exception on it...
03-19-2020 06:23 PM
03-19-2020 09:52 PM
Thanks for replying.
I think it is not something related to constraints that are internal to my design, to prove it , let us focus on the example design of xcvr IP only provided by the vivado,
so implemented the example design provided by the xilinx for two options , that is for 64 bit user width and 128 bit user width, knowing that XCVR IP is running on 28Gbps and has 48 lanes , 64 bit gives clock out as 437.5 MHz and 128 bit user interface as 218.75 ,
but let me specify this that both the options after implementation has timing failures, they have quite a few intra paths related to the module power good delay.
what I believe ,if the example design provided by the Vivado is not timing clean with respect to implementation ,then ideally we cannot use that IP in the design.
Please find below the snapshots of the path report of the example design and the placement of the paths
Please help to solve this , as I wish to use this IP in my design.
03-19-2020 09:55 PM
May be you are right due to hold path this being routed like that , but same timing failure paths are coming in the example design as well,
I attached the full snapshots the timing failure path, Now the images are not chopped off.
03-19-2020 10:00 PM
No ,the timing of example design is not met, same paths are coming , i posted some snapshots for the same in the last reply.
Please do have a look at them.
The design is running on 2.85 ns (437. 5 MHz)period not on 2 ns , may be that max delay constraint took you wrong , but looking to the example design , it seems problem is something else,
Also if the provision for 28 Gbps has been given in the IP , and also for the user width 64 and 128 both , then the logic should be timing clean for the clock 437.5 MHz and for this FPGA part number , thats what I can point ,
Please help to comment more on this.
03-26-2020 08:11 PM
One way to check if the large routing delay you are seeing is due to hold time fix (as avrum correctly pointed out) is to run report_design_analysis for this path and check if the "Hold fix detour" column has a value of 1 or not.
You can also turn on the routing resources in device view to be able to see the more realistic routing for this path, which probably has a serpentine shape.