cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
drjohnsmith
Teacher
Teacher
8,575 Views
Registered: ‎07-09-2009

Aurora 64:66 Kintex 70 T, one part of Vivado thinks I'm trying to use 12 Gbps , and issues warnings.

Is there a hard coded speed in the Aurora IP generated in vivado 2015.2 ?

 

I have just made a 6.25 Gbps Aurora 64:66 core, 

   and in the warnings I get

 

[Designutils 20-247] GTXE2_CHANNEL data rate of 12.5000 Gb/s is out of range. The valid Range is between 0.5000 - 6.6000 Gb/s for power estimation. Please check the configuration and clocking.

 

I double check and the ip block is set at 6.25 Gb;s, 

   my guess is this is hard coded some where,

 

as I'm using the Kintex 70T -2, the limit is 6.5 ish Gbps, 

    guess one part of the tools knows what the K70T parts GT speed is , the other part dosn't.

          

As I'm trying to prove a design for a customer, these sorts of warnigns are getting them worried.

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
17 Replies
balkris
Xilinx Employee
Xilinx Employee
8,570 Views
Registered: ‎08-01-2008

Th
e Aurora 64B66B protocol does not define the
electrical characteristics and is expected to
work at the maximum line rate supported by
the transceiver.
Refer to the respective GT family data sheet for the electrical specifications for the transmitter and receiver
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
balkris
Xilinx Employee
Xilinx Employee
8,569 Views
Registered: ‎08-01-2008

You can refer Transceiver guide here
http://www.xilinx.com/support/documentation/user_guides/ug476_7Series_Transceivers.pdf
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
drjohnsmith
Teacher
Teacher
8,567 Views
Registered: ‎07-09-2009

Not 100 % certain any of that answers the question @balkris

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
venkata
Moderator
Moderator
8,496 Views
Registered: ‎02-16-2010

Is this reproducible with the test case you gave me?

At what stage you are finding this warning?

Have you set period constraint on the REFCLK in your .xdc? Can you check if it is correct? This type of warnings come in implementation stage when the line rate is calculated based on the GT parameters and the REFCLK constraint.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
drjohnsmith
Teacher
Teacher
8,484 Views
Registered: ‎07-09-2009

Thank you @venkate

 

Think the test case was for a previous design,

     after you fixed my bug, I've deleted the zip.

 

Im back with customer tomorwo afternoon, I'll check it out then.

 

Its a simple K70T in a fbg package, set at 6.25 gbps

 

its 'only' a warning, but it explicitly says that the design can run at 12 something gbps.

 

Its strange, I do not put 12 in anywhere th design,

    and the Kintex GTX can run at 12 Gbps , apart from the K70T, which is in a FBG package, that supports up to 6.5 gbps.

      which is why were using 6.25 gbps.

 

so thought was, is the 12 gbps warning number comming in from the IP 

 

I seem to remember the warnign was commimg in in synthesis , no pin constraints set , and I dont think at that point any user clock constraints were set, just that the Aurora IP has itself.

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
venkata
Moderator
Moderator
8,421 Views
Registered: ‎02-16-2010

OK. Please check it further and share the example which shows the warning.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
drjohnsmith
Teacher
Teacher
8,411 Views
Registered: ‎07-09-2009

so attatched a real simple test case,

 

 

   just taken the aurora VHDL template  xilinx provide wehen one generates an Aurora IP.

 

 

Set the serdes at 6.25 gbps,  no other constraints set, 

 

from the log

 

WARNING: [Designutils 20-247] GTXE2_CHANNEL data rate of 12.5000 Gb/s is out of range. The valid Range is between 0.5000 - 6.6000 Gb/s for power estimation. Please check the configuration and clocking.

 

But I'm not setting 12.5 any where, im setting 6.25.

 

 

 

whilst i'm at it. other notes :

 

Why is there an async_reg placed here that is pbviously ignored, is it needed or not ?

 

[Constraints 18-1079] Register inst/aurora_64b66b_0_wrapper_i/rxresetfsm_i/time_out_wait_bypass_reg and inst/aurora_64b66b_0_wrapper_i/rxresetfsm_i/u_rst_sync_time_out_wait_bypass/stg1_aurora_64b66b_0_cdc_to_reg are from the same synchronizer and have the ASYNC_REG property set, but could not be placed into the same slice due to constraints or mismatched control signals on the registers.

 

 

 

 

this would be a design fail if it was one of the modules I wrote, all FSM's must have a others statment, or be full. 

   were going to have to look out for these in design reviews, Ihtink it should be promoted to warning not info.

 

[Synth 8-155] case statement is not full and has no default ["c:/for_xilinx/project_1/project_1.srcs/sources_1/ip/aurora_64b66b_0/aurora_64b66b_0/src/aurora_64b66b_0_tx_startup_fsm.v":414]

 

 

 

 

100 instances of un driven pin , such as below not nice in an ip block, how do we know if they are ok something wrong with the way we have implimented things.

 

[Synth 8-3295] tying undriven pin \inst/aurora_lane_0_i/lane_init_sm_i/u_cdc_rxlossofsync_in/s_out_d1_aurora_64b66b_0_cdc_to_inferred :in0 to constant 0

 

 

this one gets us ! 

  • [Vivado_Tcl #UNDEF] Cannot write hardware definition file as there are no IPI block design hardware handoff files present

 

 

Any thoughts please.

 

Look at it as one trying to design SERDES first time,

    thye are making mistakes, and learning, 

       they are trying to find out is it what they have done, their mis understanding or what.

            any added snow is of no help.

 Its the warnings that people are looking at to get a clue as to what they have done wrong.

 

Any one of these questoins can be answered, 

  and personaly I'm quite confident with what I have, 

 

   but more than anything I'm hoping that Xilinx take this on board,

      update their docs to agree with the IP, 

         and get rid of these warnings, 

 

thanks

 

 

 

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
drjohnsmith
Teacher
Teacher
8,392 Views
Registered: ‎07-09-2009

Any thoughts please 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
venkata
Moderator
Moderator
8,271 Views
Registered: ‎02-16-2010

Please check if you set the GT refclk period correctly can stop giving the warning.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
drjohnsmith
Teacher
Teacher
7,919 Views
Registered: ‎07-09-2009

yep

 

clk ref is 250 MHz, 

   serdes speed is 6.25

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
venkata
Moderator
Moderator
7,885 Views
Registered: ‎02-16-2010

Do you mean that if the reference clock period constraint is set, the warning will not be observed?
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
drjohnsmith
Teacher
Teacher
7,878 Views
Registered: ‎07-09-2009

Hi Venkata

 

warning still present.

 

I did what told to try, checked the 250 MHz was set in th egui

 

can you reproduce the warning,

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
venkata
Moderator
Moderator
7,818 Views
Registered: ‎02-16-2010

There is no top level .xdc file in the design you shared. When I set the refclk constraint in a test .xdc file, I do not find the warning you mentioned.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
drjohnsmith
Teacher
Teacher
7,816 Views
Registered: ‎07-09-2009

might be correct re top level

 

but the aruroa has itsown constraints file , which the 250 mhz goes into automaticaly

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
avrumw
Guide
Guide
7,806 Views
Registered: ‎01-23-2009

[Constraints 18-1079] Register inst/aurora_64b66b_0_wrapper_i/rxresetfsm_i/time_out_wait_bypass_reg and inst/aurora_64b66b_0_wrapper_i/rxresetfsm_i/u_rst_sync_time_out_wait_bypass/stg1_aurora_64b66b_0_cdc_to_reg are from the same synchronizer and have the ASYNC_REG property set, but could not be placed into the same slice due to constraints or mismatched control signals on the registers.

 

This warning isn't telling you that the ASYNC_REG is invalid or ignored, just that the two FFs cannot be placed in the same slice.

 

The ASYNC_REG property on back-to-back flip-flops instructs the placer to put these flip-flops "as close together as possible". Under normal circumstances, this will mean that they will be placed in the same slice. However, all 8 flip-flops in the same slice must use the same control set - this means the same clock, reset, and enable. For a synchronizer, at least 2 of these three should (almost) always be the same - the synchronizer stages should (almost) always use the same clock, and you should never use the CE on a synchronizer (it should always be permanently tied high). However, there isn't really a hard and fast rule on the reset - in fact, most synchronizers don't need resets. So, if one of the two FFs uses a reset and the other doesn't then the two FFs cannot be packed in the same slice.

 

While unusual, it is possible to have a similar thing on the clock - for example on a slow clock, you could consider using the rising and falling edges of the clock for the two stages of the synchronizer in order to reduce the latency for the synchronizer. Again, these two FFs cannot be packed in the same slice.

 

When the ASYNC_REG Is applied and the FFs have different control sets, the flip-flops will be placed in adjacent slices (and you will get this warning). In this case, the synchronizer will be a little bit weaker (due to the extra propagation time between the flops), which will show up as a VERY SLIGHTLY decreased MTBF. But the ASYNC_REG is not ignored, and it is not necessarily invalid.

 

Avrum

 

0 Kudos
drjohnsmith
Teacher
Teacher
7,796 Views
Registered: ‎07-09-2009

thank you @avrumw

 

totaly agree about the async_reg point,

 

the point of this forum post was that I get a simple warning regarding the SERDES speed.

 

It just seemed strange to me that although I put in the serdes speed in Aurora GUI as 6.25 Gbps , 

    the tools still warn us that Im trying to run them over 12 somethign Gbps.

 

The question(s) regarding Aurora have expanded ovee the last week or two, as I explore more of the 'quirks' and differences between implimenting Aurora on one chip compared to another, 

 

Dont get me wrong, Aurora in Vivado GUI is a significant improvment on that in ISE GUI, 

   your getting the scripts right , but there are still bits that cause confusion to new users.

 

Remember , SERDES are probably the fasest  and most hard to debug part of a board design a user will do. 

    Aurora could be plug and play, and should be for the majority of users,  but its still a long way off that.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
hcommin
Observer
Observer
639 Views
Registered: ‎02-18-2020

Just in case anyone else finds this post as I did while looking for help with this warning:

WARNING: [Designutils 20-247] GTPE2_CHANNEL data rate of 5.0000 Gb/s is out of range. The valid Range is between 0.5000 - 3.7500 Gb/s for power estimation. Please check the configuration and clocking.

In my case, the problem was that different speed grades were somehow being selected in different parts of the build process. (Some time ago, I had changed from a -1 to a -2 part, but despite resetting all runs and deleting the IP cache, some stale settings somehow persisted). In the end, I did a text search through the whole project directory and managed to replace all the remaining instances of -1 with -2. After that, this warning (and some enormous timing failures, including weird MIN PERIOD pulse width violations) disappeared.