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: 
Adventurer
Adventurer
433 Views
Registered: ‎06-25-2012

Ultrascale+ Aurora 64/66b fails timing in Vivado 2018.3 - missing false path in constraints?

Jump to solution

I had a design utilizing Aurora 64/66b IP working in Vivado 2017.4, but after migrating to Vivado 2018.3 it has started failing timing.

The timing failure is in the *async_default* group, and all 3 paths launch from the same location:

<location>/inst/aurora_64b66b_x0y4_core_i/aurora_64b66b_x0y4_wrapper_i/aurora_64b66b_x0y4_multi_gt_i/gtwiz_userclk_rx_reset_in_r_reg/C

The 3 ending paths are:

  • <location>/inst/aurora_64b66b_x0y4_core_i/aurora_64b66b_x0y4_wrapper_i/aurora_64b66b_x0y4_multi_gt_i/ultrascale_rx_userclk/gen_gtwiz_userclk_rx_main.rx_active_aurora_64b66b_x0y4_cdc_to_reg/CLR
  • <location>/inst/aurora_64b66b_x0y4_core_i/aurora_64b66b_x0y4_wrapper_i/aurora_64b66b_x0y4_multi_gt_i/ultrascale_rx_userclk/gen_gtwiz_userclk_rx_main.rx_active_stg2_reg/CLR
  • <location>/inst/aurora_64b66b_x0y4_core_i/aurora_64b66b_x0y4_wrapper_i/aurora_64b66b_x0y4_multi_gt_i/ultrascale_rx_userclk/gen_gtwiz_userclk_rx_main.gtwiz_userclk_rx_active_out_reg/CLR

I took a bit of look at the differences between the two cores and it appears that some of the related reset logic has been changed some.

In 2017.4 the design looked like this:

image.png

With the following constraint:

set_false_path -to [get_pins -hier *aurora_64b66b_x0y4_cdc_to*/D]

But in 2018.3 the design looks like:

image.png

But there is no corresponding constraint for this path.

Backing out a bit more, it turns out the net attached to CLR is responsible for all 3 timing failures:

image.png

This seems like a bug. Is this a known issue? What is an appropriate constraint for these paths?

I think in this limited case, the following constraint will do what I need:

set_false_path -through [get_nets -hier -filter { NAME =~ "*ultrascale_rx_userclk/gtwiz_userclk_rx_reset_in_r" }]
0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
247 Views
Registered: ‎03-30-2016

Re: Ultrascale+ Aurora 64/66b fails timing in Vivado 2018.3 - missing false path in constraints?

Jump to solution

Hello @kevinclaycomb , Hello @jsmithsrc

This issue has been fixed in 2019.1

Thanks & regards
Leo

5 Replies
Observer kevinclaycomb
Observer
324 Views
Registered: ‎12-19-2012

Re: Ultrascale+ Aurora 64/66b fails timing in Vivado 2018.3 - missing false path in constraints?

Jump to solution

Running into the same issue.  Did you ever get a response from Xilinx?  The hierarchy gets pretty messy so it isn't surprising this could happen with minor version changes, but it would be nice to hear from Xilinx that appling a false path constraint on these nets is the right thing to do.  Seems right to me, but would like confirmation.

I am on 2018.3 and a Zynq Ultrascale+ part.

0 Kudos
Adventurer
Adventurer
308 Views
Registered: ‎06-25-2012

Re: Ultrascale+ Aurora 64/66b fails timing in Vivado 2018.3 - missing false path in constraints?

Jump to solution

I have no received any other response from Xilinx on this issue.

0 Kudos
Highlighted
Observer kevinclaycomb
Observer
300 Views
Registered: ‎12-19-2012

Re: Ultrascale+ Aurora 64/66b fails timing in Vivado 2018.3 - missing false path in constraints?

Jump to solution

@karnanl would you be able to comment on the above timing issue we are seeing? 

Xilinx Employee
Xilinx Employee
291 Views
Registered: ‎03-30-2016

Re: Ultrascale+ Aurora 64/66b fails timing in Vivado 2018.3 - missing false path in constraints?

Jump to solution

Hello @kevinclaycomb , Hello @jsmithsrc

Thanks for sharing this post. Confirmed using Aurora 64B66B Example design. I see the same behavior.
Hmm, I believe you are correct that we missed false path contstraint. (Clock domain crossing between init_clk and rxoutclk )
For now please ignore this failed timing since it will do no harm to your design, or you can add false path constraint on your own XDC file.


-- I am a little bit confused since I cannot reproduce it using Transceiver GUI. (but reproducible using Aurora GUI)
    Let me talk with Aurora Expert/Developer team regarding this behavior and give you feedback on this post.

 

Thanks & regards
Leo
 

XF_Aurora_64B66B_needs_false_path_const.png
0 Kudos
Xilinx Employee
Xilinx Employee
248 Views
Registered: ‎03-30-2016

Re: Ultrascale+ Aurora 64/66b fails timing in Vivado 2018.3 - missing false path in constraints?

Jump to solution

Hello @kevinclaycomb , Hello @jsmithsrc

This issue has been fixed in 2019.1

Thanks & regards
Leo