08-18-2015 06:57 AM
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.
08-18-2015 07:00 AM
08-18-2015 07:01 AM
08-18-2015 07:04 AM
Not 100 % certain any of that answers the question @balkris
08-18-2015 09:50 AM
08-18-2015 10:50 AM
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.
08-19-2015 02:16 AM
08-19-2015 04:37 AM
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 !
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,
08-24-2015 12:07 PM
08-27-2015 12:04 PM
08-28-2015 12:32 AM
warning still present.
I did what told to try, checked the 250 MHz was set in th egui
can you reproduce the warning,
09-01-2015 11:31 AM
09-01-2015 11:59 AM
might be correct re top level
but the aruroa has itsown constraints file , which the 250 mhz goes into automaticaly
09-01-2015 02:21 PM
[Constraints 18-1079] Register inst/aurora_64b66b_0_wrapper_i/rxresetfsm_i/time_o
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.
09-01-2015 11:18 PM
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.
02-27-2020 05:19 AM - edited 02-27-2020 05:20 AM
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.