cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
570 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
534 Views
Registered: ‎05-14-2008

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.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------

View solution in original post

Tags (1)
2 Replies
Highlighted
Xilinx Employee
Xilinx Employee
535 Views
Registered: ‎05-14-2008

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.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------

View solution in original post

Tags (1)
Explorer
Explorer
524 Views
Registered: ‎10-12-2018

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.