<GitHub135>
artiq/rtio-sed faf5412 Sebastien Bourdeauducq: rtio/sed: remove VCD fine in unittest
<_florent_>
sb0: I already validated everything on the KCU105, the test I'm going to do is just to be sure code is not broken
<_florent_>
sb0: it's still working fine with KCU105
<sb0>
_florent_, ok
<sb0>
btw did you test the bridge and rust clock config code?
<sb0>
we still don't have rtm hardware ...
<_florent_>
sb0; I'm going to do that in the next days
<_florent_>
sb0: I received my ethernet media converter, do you want me to have quick a look at the rgmii phy? (don't know if it will unlock things on your side)
<sb0>
sure
<rjo>
sb0, _florent_: imho we need to focus on jesd more. even if it is only to give something to greg to work on.
<rjo>
without jesd this entire exercise (rgmii, the bridge, etc) is pointless.
<rjo>
_florent_: what can we do to help you?
<rjo>
what can greg do?
<rjo>
at least for the bridge and rgmii we could think of temp workarounds. for jesd there is no such thing.
<sb0>
doesn't it look like a hardware issue?
<_florent_>
rjo: I agree, I'm testing jesd right now
<_florent_>
rjo: with reordering the initialization sequence as suggested by larsc
<_florent_>
rjo: but what can I do if it's an hardware issue?
<rjo>
sb0: we need to find out whether it is one.
<_florent_>
rjo: with the KCU105, prbs is always errors are always 0 at 5gbps/10gbps
<_florent_>
rjo: serdesplllock is also always 1
<_florent_>
rjo: I still don't understand why one of the dac seem to work and the other not
<_florent_>
rjo: and it's not the same between the board I have and the board greg has
<_florent_>
rjo: different results with the same bitstreams
<rjo>
_florent_: i understand.
<rjo>
_florent_: it's been a while since i looked at all the supporting docs. how do ADI or Xilinx recommend verification of a JESD link? AFAIK (and correct me if i am wrong). the dependency chain is: (1) SERDES PLL lock on all channels (2) CGS (3) PRBS etc etc
<rjo>
do we have reliable (1)? and does (3) depend on (2)?
<_florent_>
3 does not depend on 1, PRBS is really here to test the lanes
<rjo>
_florent_: what would you recommend? should we have greg try to generate a Xilinx JESD core to test? should I insist that he does IBERT scans with a loopback adapter?
<_florent_>
once SERDES PLL is lock, you can use PRBS
<rjo>
so PRBS does not work on top of 8b10b?
<_florent_>
that's all
<_florent_>
no
<rjo>
ok. then do you get reliable (1)? i remember reading something in the ad9154 datasheet that says that SERDESPLLLOCK can be false positive if there were errors (or something along those lines).
<_florent_>
based on the results I have with the KCU105, we always have SERDESPLLLOCK to 1 when working
<_florent_>
not on the sayma board
<_florent_>
one of the DAC never sets SERDESPLLLOCK to 1
<_florent_>
DAC0 on my board
<_florent_>
DAC1 on greg's one
<_florent_>
that's the first thing I would investigate
<_florent_>
because getting SERDESPLLLOCK only depends on SPI, DACCLK, SYSREF and not the lanes
<_florent_>
at least that's what I concluded from the work I did with the KCU105
<sb0>
didn't greg find some issue with clock termination?
<_florent_>
sb0: yes, but it does not seem to improve things
<rjo>
_florent_: SERDESPLLLOCK is quite far down the initialization if i look at the datasheet.
<rjo>
_florent_: looking at page 78, is the DAC PLL locked reliably? Table 83. Configure DAC PLL
<rjo>
_florent_: or do we skip that?
<_florent_>
rjo: I'll look at that
<rjo>
_florent_: if this is a SI issue, then the equalizer should change something (EQ_BIAS_REG) either make it worse or better. that would be a pretty quick stab at it.
<larsc>
I've got a bunch of boards here, SERPLLLOCK is never 0
<larsc>
at least when things work
<rjo>
_florent_: you are pretty good at guessing where the problem is. what should we have greg do?
<_florent_>
rjo: yes I can try that
<rjo>
larsc: ;) but the observation that it is 1 might be a red herring...
<rjo>
larsc: where should we look when SERPLLLOCK is not always 1?
<_florent_>
larsc: interesting
<larsc>
rjo: when I disable the clock it goes to 0
<larsc>
;)
<larsc>
the refclock
<rjo>
_florent_: and you are using the HMC830 and you are positive that it locks stably and reliably?
<_florent_>
rjo: I'm not using the HMC830
<larsc>
I'm using a ad9152, but I believe the digital IP is the same
<rjo>
_florent_: ok.
<rjo>
larsc: is my understanding correct that the SERPLL needs correct refclk and a signal on the lanes (on all lanes? just any one of them?) and correct settings.
<rjo>
and then it locks. or does it just generate the local serdes clock from the refclock (without needing anything on the lanes)?
<rjo>
... i might be asking things that i can also find out by looking at the datasheet.
<larsc>
rjo: let me try to kill the link and see what happens
<larsc>
still locked
<_florent_>
rjo/larsc: I think SERPLLLOCK is not related to what you have on the lanes
<_florent_>
at least that's what I observed while doing the core
<larsc>
I'd say it only depends on the refclock
<larsc>
do you set all the recommended PLL settings?
<_florent_>
yes I think, at least KCU105 + AD9154 FMC seem happy with that
<rjo>
_florent_: and you have also added the termination resistors on the clock?