<larsc>
if you clock internal logic it does not matter since the delay will be the same starting at the BUFG
<larsc>
but if you try to sample an external signal it does
<sb0>
hm, yes
<sb0>
that's pretty annoying
<sb0>
it would be interesting to get a more precise characterization of this. it impacts white rabbit too, but last time I asked another similar picky question, the answer was pretty much "we don't know/we live with it"
<larsc>
one thing that can be done to slightly improve things, at least for sysref, sampling is to use an BUFH instead of a BUFG, and if the sysref input is not in the same clocking region use a MMCM
<larsc>
while it does not remove the uncertainty from the IBUFDS_GTE2 it removes the uncertainty from the BUFG and the clock net to and from the BUFG
fengling has quit [Ping timeout: 240 seconds]
kyak has joined #m-labs
kyak has joined #m-labs
sb0 has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
sb0 has joined #m-labs
<sb0>
if the IBUFDS_GTE2 does give you 1ns, it's already over
<larsc>
for you maybe
<larsc>
I mean for your usecase
<larsc>
for jesd204 sysref sampling it is ok
<larsc>
but if you factor in the slow and fast corners plus the net delays you end up with almost 3ns variance
<larsc>
I guess the question really is what causes this large delay uncertainty and can it be controlled
<larsc>
but good luck finding that info
<sb0>
larsc, where do you see 1ns in that timing report?
<sb0>
why wouk
<sb0>
sorry
<sb0>
why would y
<larsc>
between the two highlighted numbers
<sb0>
why would you use the GTE clock pins if you're just sampling sysref at ~300MHz?
<sb0>
what is "incr"?
<larsc>
increment, I guess
<larsc>
yes
<larsc>
that is the increment of that element
<larsc>
path is total length up to that point
<larsc>
the GTE clock pins are used for both as the PLL reference and the sysref sampling clock
<larsc>
to be honest I don't want to use it for sysref sampling
<larsc>
I want to use a normal IBUFDS
<larsc>
but I have systems which dont have a separate clock input on a IBUFDS
<sb0>
yes. so why exactly does it give two different values there for the IBUFDS_GTE2 delay?
<larsc>
one is for the destination clock, the other for the source clock
<sb0>
ok but why?
<larsc>
source uses maximum delay, destination uses minumum
<sb0>
ah
<larsc>
for internal signals this gets removed again
<sb0>
this is quite some guesswork...
<larsc>
this is accounted for in the pessimisem column
<larsc>
what is guesswork?
<sb0>
how to get the xilinx tools to tell you the min/max delay of some element
<sb0>
what is the ISE command again to dump the timing model parameters?
<sb0>
there was some partgen or xdl command
<larsc>
that gives you min/max delay for all components?
<sb0>
it gives you delays for many components, yes
<larsc>
the more I talk to people about jesd204b the more I feel nobody actually fully understands it
<larsc>
yeah, those are the numbers I'm seeing as well
<larsc>
or at least similar
<larsc>
which device is this?
<larsc>
ah, different speedgrade
<larsc>
if I run speedprint with the correct speedgrade I get the same numbers as in the timing report
<larsc>
Tibibo (441/732) (1418/2355)
<larsc>
would it help if we assume that this is the difference between the fastest and the slowest IBUFDS_GTE2 that you can find on device at a specific process corner?
<larsc>
like a single IBUFDS_GTE2 would no vary that much, but if you tried to compare two of them there could be that much delay between them
<larsc>
doesn't help of course if you try to sample external signals
<larsc>
the delay could be anywere between 441 and 2355
bentley` has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Quit: Leaving.]
cr1901_modern has left #m-labs [#m-labs]
cr1901_modern has joined #m-labs
mumptai has quit [Remote host closed the connection]