<sb0>
hartytp: is it correct that, in the currently published Sayma AMC prototype, the plan is to implement the PFD between the WR PLL output and the RX recovered clock entirely inside the FPGA?
<sb0>
*Sayma AMC schematics
<sb0>
also that PFD is based on DDMTD and you are suggesting using external FFS in the next revision
<sb0>
those FFs are to be clocked by the helper DCXO, one of the FFs takes the main DCXO as input, and the other one takes the recovered clock via OBUFDS_GTE3
<sb0>
also we should test OBUFDS_GTE3 on the current hardware before committing to it. ultrascale doesn't always work as expected.
mini has joined #m-labs
mini has quit [Client Quit]
hartytp has joined #m-labs
<hartytp>
sb0: basically, yes
<hartytp>
comments:
<hartytp>
"also that PFD is based on DDMTD and you are suggesting using external FFS in the next revision "
<hartytp>
ideally, I would prefer to use IOB FFs inside the FPGA to minimize complexity. The suggestion of external FFs is based on your comments that you suspect that IOB FFs won't work on ultrascale
<hartytp>
(and when you say next revision, we mean next rc for Sayma v2.0)
<hartytp>
" also we should test OBUFDS_GTE3 on the current hardware before committing to it. ultrascale doesn't always work as expected. " yes, that or maybe use a mux to allow us to select between that and some other routing path
<hartytp>
also, worth noting that I still consider WR high-risk. I'm treating Sayma v2.0 as a prototyping platform for all of this, with the aim of getting something that works really well for v2.1
<hartytp>
on the KC705, weida played around with multiple ways of routing the recovered clock to the DDMTD input and didn't see any significant changes to performance with the loaded FPGA. YMMV though, so needs more testing with ARTIQ/Sayma
<sb0>
yes next rc
<sb0>
let's put the external FFs. then as I understand it, nothing precise or low-noise goes through the FPGA fabric, which is a plus.
<sb0>
the only big disadvantage I see is ensuring s/h for the FF outputs is met at the FPGA
<sb0>
(and testing that it is actually met)
<sb0>
AFAICT if it isn't met, DDMTD will still work but possibly with worse precision
<hartytp>
"the only big disadvantage I see is ensuring s/h for the FF outputs is met at the FPGA" yes, but that's the same situation for e.g. sampler
<sb0>
the only issue is generating the ISERDES high-speed clock, which bumps into the Ultrascale TPWS bug
<hartytp>
I'd assumed that at 125MHz, it should be fine to register them with an IOB FF driven from the helper clock. Any S/H violations either at the S/R inputs or at the FPGA will show up as errors in the recovered test pattern (although you won't know what the cause was)
<sb0>
hmm maybe
<hartytp>
anyway, I don't have a strong opinion about that, whatever is simplest
<sb0>
is synchronous S/R pins a common feature on fast FFs?
<hartytp>
my point is really that if specifying proper timing constraints isn't enough to get source-synchronous interfaces working properly at 125MHz
<hartytp>
then it's a problem that we're going to hit anyway e.g. due to the servo -- which we do plan to implement
<sb0>
the problem is, how do we know if it's enough?
<sb0>
the symptom of a failure will be a subtle DDMTD performance degradation
<hartytp>
"is synchronous S/R pins a common feature on fast FFs?" hmm...the ones I was looking at are asynchronous S/R
<sb0>
that's not usable
<hartytp>
so, you're right, that won't work
<sb0>
maybe we can oversample with the IDELAY
<sb0>
some Xilinx FPGAs support that. I don't know about Ultrascale
<hartytp>
for testing, what about just hooking the helper clock to a diff input, and doing an IDELAY scan. Veryify that always looks sensible and extrapolate that the other inputs are likely to work as well?
<hartytp>
otherwise, sure we can oversample, but I've lost track of what the IOSERDES clocking issues were
<sb0>
and what do you expect to see on a IDELAY scan?
<sb0>
the external FF already samples a glitchy signal.
<hartytp>
i was thinking of something else, but actually probably not a good idea
<sb0>
what can be done is sample two points with IDELAY + IDELAY bypass (Spartan-6 and 7-series support this) and check that they are always the same
<sb0>
if that also works on US then we don't need ISERDES and its clocking bugs
<sb0>
for SYSREF we're using the GTH to generate the ISERDES clocks, so we don't have the other problems
<hartytp>
using ultrascale for Sayma turned out to not be such a great idea. such a pita to have to reinvent everything that works fine on other FPGAs...
<sb0>
oh actually
<sb0>
the FF output is differential, right?
<hartytp>
yes
<hartytp>
aah, that's a cute idea
<hartytp>
you mean check that the two halves of the data are always invesrses to verify S/H?
<sb0>
yes
<sb0>
might need some tricks at the electrical level, but that should work
<hartytp>
I'm looking for an equivalent of UG471 fig 2-3 in UG 571 to check for the idelay BP on ultrascale
<hartytp>
sb0: but, am I wrong in thinking that if we add max/min input delay constraints and get something that meets timing but still has S/H violations then it's a gross miscompilation?
<sb0>
maybe, but those constraints can be wrong (e.g. because we put the wrong numbers in them) and then we have no way of telling
<sb0>
basically there are many things that can go wrong here, and the symptom of a problem isn't clear
<hartytp>
sure, but that's the same situation as, for example, suservo on Kasli (you just see worse noise if you mess up the constraints) or any other synchronous interface
<sb0>
corrupted ADC data will cause more serious symptoms I think
<hartytp>
anyway, I agree that more diagnostics are always good
<hartytp>
what about using a DDR input to latch the DFF output
<hartytp>
basically, just 2x oversampling?
<sb0>
that can work too, but that checks for a very wide timing margin
<hartytp>
yes, I would expect that to be fine for our 125MHz clock frequencies
<sb0>
maybe
<sb0>
can be tried
<hartytp>
well, I think we need some hw to play with to investigate this. So, I propose we do something sensible in the next HW rev, making sure to expose signals on TPs etc and have a play
<hartytp>
hmm...I wonder if there is a way of testing this on Sayma v1.0
<hartytp>
I'll have a look
<hartytp>
sb0: or idelay + IDDR. Sweep the idealy and find the points where the IDDR outputs differ
<hartytp>
anyway, lots of things we can try.
hartytp has quit [Quit: Page closed]
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
clock routing with ultrascale is such a PITA
<sb0>
removed all CLOCK_DEDICATED_ROUTE and LOCs, updated to v2 pin constraints, now nothing compiles anymore because the clock placer craps out with two screens of shitty error messages like
<sb0>
Rule Description: A BUFGCE with I/O driver driving a single MMCM must both be in the same clock region
<sb0>
if CLOCK_DEDICATED_ROUTE=BACKBONE is NOT set
<sb0>
BUFG (BUFGCE.O) is provisionally placed by clockplacer on BUFGCE_X1Y2
<sb0>
crg_main_mmcm (MMCME3_ADV.CLKIN1) is provisionally placed by clockplacer on MMCME3_ADV_X1Y0
<sb0>
and basically *every* clock is broken like that, even though we are using GC pins etc.
<sb0>
the documentation has just four pages of hand-wavy explanations about clocking (shorter than the vivado errors) and says vivado with handle it, except this shit doesn't work