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: 
Explorer
Explorer
130 Views
Registered: ‎10-12-2018

Aurora internal clock constraint missing

Jump to solution

The user_clk (aka. TXOUTCLK of the gt) has no constraint using Kintext Ultrascale, and the timing report is full of warning, like this:

Unconstrained Pins for maximum delay (11581)

image.png

This warning are appeare because the clock constraint cannot be found by the Vivado. (Not listed in the Timing -> Clock Summary)

So I have compared my 7-series design (which works correctly) this Ultrascale design, and I have realised that the constrainsts of the Aurora IP differ. The Ultrascale has clock constraint only in the *ooc.xdc, which isnt used by the later steps.

On 7-Series the IP generates the xdc with the following line:

create_clock -period 16.000 [get_pins -hier -filter {name=~*aurora_64b66b_x0y0_wrapper_i*aurora_64b66b_x0y0_multi_gt_i*aurora_64b66b_x0y0_gtx_inst/gtxe2_i/TXOUTCLK}]

 

The Ultrascale IP has no similar line like this.

 

Why the does Ultrascale's constraint lack of the clock constraint?

I have read this thread which lead me assume that this is a bug.

Is this bug fixed in newwer version like this?

How can it be solved? Should I write the constraint externally?

 

I use:

  • Win 10
  • Vivado 2017.4
  • Aurora
    • 64b66b
    • Simplex mode
    • Shared logic inside the core
    • 2 Gbps
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
94 Views
Registered: ‎05-14-2008

Re: Aurora internal clock constraint missing

Jump to solution

For Ultrascale devices, the GT output clocks are auto-derived like the MMCM output clocks as long as you create a clock for the GT reference clock. 

For 7-series devices, it is not auto-derived so you need the create_clock constraint for the GT output clocks.

Please check if you have create_clock constraint added for the GT reference clock in your design.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
Tags (1)
2 Replies
Highlighted
Xilinx Employee
Xilinx Employee
95 Views
Registered: ‎05-14-2008

Re: Aurora internal clock constraint missing

Jump to solution

For Ultrascale devices, the GT output clocks are auto-derived like the MMCM output clocks as long as you create a clock for the GT reference clock. 

For 7-series devices, it is not auto-derived so you need the create_clock constraint for the GT output clocks.

Please check if you have create_clock constraint added for the GT reference clock in your design.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
Tags (1)
Explorer
Explorer
84 Views
Registered: ‎10-12-2018

Re: Aurora internal clock constraint missing

Jump to solution

Thanks @viviany 

You are right, Ultrascale devices can derive clock from the gt_ref input. So I needed to add a constraint into my custom constraint file:

create_clock -period 10.000 [get_ports i_gt_refclk1_p]

And now everithing is perfect.


However there is a bit dissonance in IP's clock constraints. I have an 10G-ETH in this design also, which doesn't need any extra constraint. Ethernet IP defines the clock itself (automaticly) unlike Aurora.

I have printed out all clock definition of these IPs. Aurora has no (non out-of-context) clock definition. (All clock definition is commented out.)

betontalpfa@pc:aurora_ip$ grep create_clock -r --include=*.xdc --exclude=*_ooc.xdc
src/ip/aurora_64b66b_x0y4/aurora_64b66b_x0y4_clocks.xdc: #create_clock -period 64.0 [get_ports user_clk_out]
src/ip/aurora_64b66b_x0y4/aurora_64b66b_x0y4_clocks.xdc: #create_clock -period 40.000 [get_ports init_clk]

Ethernet has one clock definition:

betontalpfa@pc:10g_eth$ grep create_clock -r --include=*.xdc --exclude=*_ooc.xdc
src/ip/axi_10g_ethernet/bd_0/ip/ip_1/synth/bd_9a86_xpcs_0.xdc:create_clock -period 6.400 [get_ports refclk_p]


Note also, that Aurora's example design defines the reference clock. So again I recommend anyone to start from the example design all the time.