cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
545 Views
Registered: ‎07-02-2019

Vivado XCVR(transceivers) IP of Ultra scale is having timing failure paths internal to its module

Hi All,

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.

 

Regards

Y.Arora

 

 
 

 

 

 

path report.PNG
Device routing.PNG
0 Kudos
7 Replies
Highlighted
Contributor
Contributor
480 Views
Registered: ‎12-27-2018

Re: Vivado XCVR(transceivers) IP of Ultra scale is having timing failure paths internal to its module

Hi、

  1. Is the example design timing met ??
  2. I see that your constraint has 2ns == 500MHz. Are you sure that GT logic can run that fast in US+ -2L device ?

 

Best regards.

Highlighted
Guide
Guide
430 Views
Registered: ‎01-23-2009

Re: Vivado XCVR(transceivers) IP of Ultra scale is having timing failure paths internal to its module

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...

Avrum

Highlighted
Contributor
Contributor
398 Views
Registered: ‎12-27-2018

Re: Vivado XCVR(transceivers) IP of Ultra scale is having timing failure paths internal to its module

Kudos for @avrumw,

I also suspect some constraint from example design is missing or overwrite.

Best regards.

0 Kudos
Highlighted
Visitor
Visitor
379 Views
Registered: ‎07-02-2019

Re: Vivado XCVR(transceivers) IP of Ultra scale is having timing failure paths internal to its module

Hi All,

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.

 

Regards

Y.Arora

 

path report1.PNG
timing report.PNG
path report2.PNG
Device report worst slack.PNG
0 Kudos
Highlighted
Visitor
Visitor
378 Views
Registered: ‎07-02-2019

Re: Vivado XCVR(transceivers) IP of Ultra scale is having timing failure paths internal to its module

Hi , 

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.

 

 

0 Kudos
Highlighted
Visitor
Visitor
376 Views
Registered: ‎07-02-2019

Re: Vivado XCVR(transceivers) IP of Ultra scale is having timing failure paths internal to its module

Hi,

 

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.

 

0 Kudos
Highlighted
Visitor
Visitor
239 Views
Registered: ‎08-26-2019

Re: Vivado XCVR(transceivers) IP of Ultra scale is having timing failure paths internal to its module

Hi yashu,

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.

0 Kudos