<GitHub38>
[artiq] jonaskeller commented on issue #902: I've been continuously monitoring since the last post and haven't seen a single coredevice panic. Occasionally (~2 times a day), connections are refused for a brief period of time, and that might have been what I described above (just being too impatient and hitting reset before it resolved itself). These are quite different symptoms though, so it seems very likely that the
<rjo>
sb0: the opticlock example works. just change the device-db (kc705-nist_clock for ref).
<sb0>
rjo, no it doesn't, I get an assertion error on "assert 12 <= pll_n <= 127"
<sb0>
(after simply changing ad9912 to ad9910)
<rjo>
sb0: yes. look at the device-db.
<rjo>
sb0: it does work.
<sb0>
so what am I supposed to change?
<rjo>
sb0: look at the device-db. that's not to difficult.
<sb0>
do you have a full ad9910 example somewhere? I could go ahead with the crate assembly and testing, otherwise I have to figure out how the PLL works first
<rjo>
sb0: if it is only the pll multiplier take 32 (from 125M, div-by-4, mul-by-32, 1 GHz pll)
<bb-m-labs>
build #2134 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2134 blamelist: Robert Jordens <rj@m-labs.hk>, Robert Jordens <jordens@gmail.com>
<rjo>
sb0: could you check the resistors right of J5 on sayma-1-AMC? and you removed R112 on sayma-1-RTM (the lower one) and shorted the left pad with the left pad of R116 (the upper one)?
<rjo>
sb0: i really don't get why rtm loading is not working on sayma-1 other than the resistors or the mode pins. could you help me?
<rjo>
maybe DONE needs a stronger pullup than the AMC internal one, ug470 has 330R. OTOH it is high when the bitstream is loaded through JTAG.
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub-m-labs>
artiq/master de63e65 Robert Jordens: kasli/si5324: lock to 100 MHz with highest available bandwidth
<rjo>
whitequark: why doesn't the compiler emit 'l.sw 4(r8),r3' instead of 'l.ori r12,r8,0x4; l.sw 0(r12),r3'. even if the answer is "wait states", there would be less code and presumably better caching.
<whitequark>
for some reason it pessimized some of the tests, and we didn't have performance counters then
<whitequark>
(and we don't have them anymore again, right?)
<rjo>
ah. right. i vaguely remember
<rjo>
enabling them is just one line of code (i disabled them because of timing issues on kasli and them not being used). i think you fixed the PCU verilog.
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #908: @enjoy-digital Could you post your patch with eye scan for current versions of sdram firmware I'd like to test it per @hartytp suggestion? https://github.com/m-labs/artiq/issues/908#issuecomment-369613154
hartytp has joined #m-labs
<hartytp>
rjo: do you think you could have a play with Kasli DRTIO and try to reproduce some of our observations?
hartytp has quit [Client Quit]
sb0 has joined #m-labs
<sb0>
rjo, you removed R112 on sayma-1-RTM (the lower one) and shorted the left pad with the left pad of R116 (the upper one)? << yes
<sb0>
what should I do with the resistors right of J5?
<marmelada>
rjo: sorry, i forgot again, urukul on kasli is on eem4 and 5?
<rjo>
sb0: make a photo and figure out with greg what the state and what the desired config is.
<rjo>
hartytp: i only have one kasli and little time.
hartytp has joined #m-labs
<hartytp>
ack
<hartytp>
well, I'm thinking of asking Weida to take the notes about WR and use them to design a replacement for the Si5324
<rjo>
marmelada: irclog.whitequark.org has long term logs. i think it is eem5 and eem4 (due to cabling). the code is authoritative.
<hartytp>
along the lines of what I sketched out on the wiki
<hartytp>
issue I mean
<rjo>
what do you want reproduced?
<hartytp>
the timing instabilities
<hartytp>
the phase shifts on reset
<rjo>
lack of deterministic phase between resets? or the low-f noise?
<hartytp>
i.e. put the master and recovered clocks on a scope
<hartytp>
and see if they're stable with respect to each other
<hartytp>
both
<hartytp>
or, equivalently, look at TTL outputs from the master and slave
<rjo>
i had seen the low-f noise a month ago iirc. in standalone. does that help?
<hartytp>
yes
<hartytp>
that already shows there is a problem
<hartytp>
IIRC the issues are all much worse on the slave because the dividers in the Si5324 are set to crazy high values on the slave but not on the master
<rjo>
that just shows that 9 Hz bandwidth is "low".
<hartytp>
all our tests were done with max BW
<hartytp>
(which the current DRTIO slave configuration uses)
<rjo>
the dividers can be low. free_run mode is not needed for a drtio slave.
<hartytp>
no?
<hartytp>
how does the init work?
<hartytp>
thought you needed the hitless switching
<sb0>
free_run means connecting the xtal to clkin2
<hartytp>
right
<sb0>
on kasli we can put an external clock on clkin2 which has a friendlier frequency, perhaps
<hartytp>
aah
<hartytp>
okay, yes, you can do that
<hartytp>
but, it kind of goes against the idea of DRTIO doesn't it if we have to start supplying clocks everywhere.
<hartytp>
not really time transfer if it needs a clock input
<sb0>
clkin2 is only used for the link initialization
<sb0>
it can be a local oscillator
<sb0>
but yes, this si5324 turns out to be a very poor choice.
<hartytp>
there are several problems afaict. You can fix one of them by adding a cyrstal at, say 25MHz, to the clkin 2 input to use as an init clock
<hartytp>
or, better, by replacing the Xtal on Kasli with a 125MHz XO
<hartytp>
but, that still leaves several other problems
<sb0>
not 150?
<hartytp>
sure, or that
<rjo>
i thought i had read that the si5324 can even (sorry for the rudeness) be configured to emit something useful without a clock in ckin1 and without anything on ckin2 just off the crystal. and then do auto-switching.
<hartytp>
either way you run the PFD at the highest frequency you can
<hartytp>
rjo: as I understand it (see my post) the auto switching works by picking PLL settings that work for both clkin1 and clkin2
<sb0>
hartytp, yes, that's how I understand it as well
<hartytp>
you then use the input dividers to reduce both inputs down to the same frequency at the PFD
<rjo>
hartytp: yes. but in !free_run, those can be low dividers.
<hartytp>
depends on your XTAL frequency
<sb0>
note: the si5324 also has a bypass bit, if we need to get rid of it completely and access the GTP clock
<rjo>
i am referring to the xa/xb xtal that we have.
<hartytp>
right, so that's at an odd frequency, chosen not to have a simple relationship to the input clock
<hartytp>
as a result, to reduce the dividers have to be high to get that to the same frequency as the input clock
<hartytp>
low dividers requires a simple relationship between input clock and the Xtal/Xo
<rjo>
that's not what i mean.
<rjo>
no
<hartytp>
explain?
<rjo>
they don't look at the opticlock configuration. that's with 2 MHz f_PFD
<sb0>
also, the auto-switching doesn't work very well if your clock is glitchy (I tried to use it before, but it caused all sorts of problems so the artiq firmware is switching manually after the transceiver RX becomes stable)
<rjo>
i think (but haven't tested it and can't find the words in the DS) that without free_run (XA/XB not "connected" to CKIN2), i.e. nothing connected to CKIN2, and CKIN1 (from GTP) not yet doing anything, it can still output a useful clock that can be used to init drtio.
<rjo>
it's testable with opticlock. just change the configuration enabling all auto-switching behavior and those "always-emit something on the output" modes and see if it does. without a referenc on ckin2.
<rjo>
sb0: even changing the various history and window settings which are supposed to deal with that?
<hartytp>
rjo: okay if that works, why are we using the "freerun" mode and corresponding crazy dividers rather than just doing that?
<hartytp>
if that works, what's the point of free run mode at all?
<sb0>
the si53xx manual has this note:
<sb0>
about the 5324
<sb0>
External circuitry is required to control the input-to-output skew. Contact Silicon Labs for further information
<rjo>
hartytp: on the first q, afaict because auto-switching is frowned upon, and on the second q, i think because it is easier to understand conceptually. but i might be wrong.
<sb0>
the kc705 is using a 20ppm xtal
<rjo>
hartytp: but that line of questioning is probably as useful as asking the reverse: why shouldn't it work?
<hartytp>
well, we're finding that the clocks on Kasli are wandering all over the place
<hartytp>
even at max bw
<hartytp>
the high divider values seem to be a large part of the issue
<hartytp>
if there is a different way of configuring the chip that removes them then great
<hartytp>
but, someone needs to test that
<hartytp>
because atm it's not really useable
<hartytp>
anyway, I'm new to all these discussions and trying to catch up on what the decision making progess was and what our options are
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: FWIW, this seems to work absolutely fine with 32-bit SDRAM. Not a proper long-term solution, but should allow me to make some progress.... https://github.com/m-labs/artiq/issues/908#issuecomment-369630080
<rjo>
yes. someone should test it...
<hartytp>
anyway, that asside:
<hartytp>
even with a really good Xo
<hartytp>
max bw
<hartytp>
and 2MHz PFD
<hartytp>
we saw several ns timing fluctuations
<hartytp>
(just touch the XO lightly)
<hartytp>
for small temperature changes
<hartytp>
that concerns me as a DRTIO user and makes me think that we need a better HW solution
<hartytp>
(the XO being chosen for OCXO-level performance)
<rjo>
i am pretty sure the si5324 is a no-go for deterministic phase and putting a fpga pll in front of it (as an open loop or closed loop phase shifter) doesn't work at all or doesn't help.
<hartytp>
okay, so we agree that hw changes are needed?
<hartytp>
basically, we probably have BW to do some design work to try to find a proper solution
<hartytp>
so long as it will actually be adopted (providing we find a good solution)
<rjo>
sure. for deterministic phase that's needed imho.
<rjo>
i'd shy away from implementing the WR PLL. i am scared of the DMTD design (and its aliasing properties) and the DAC-associated sensitiviey/complexity/fragility. i have the feeling that a "deterministic phase jitter cleaner based on a narrowband pll" (this is all there is afaik) must be possible with the available integrated PLLs.
<hartytp>
ack
<hartytp>
i agree on that
<hartytp>
I'm open to using a DAC and digital LF
<hartytp>
because, we may need quite a high-order lf to achieve the phase control we need, given the finite BW
<hartytp>
that's much easier in digital
<rjo>
but yeah. that research and decision should be left to the ones actually doing the design.
<hartytp>
but, a nice PLL IC, DAC + ADC doesn't seem too bad IMHO
<hartytp>
right
hartytp has quit [Quit: Page closed]
<sb0>
the si3xxx manual says that the narrowband parts have deterministic (and tunable) skew
<rjo>
i-o or just o-o?
<sb0>
i-o
<sb0>
the si5324 already does o-o (and tests showed that i-o was stable), which is why we made that stupid mistake...
<sb0>
let me try contacting them as they suggest about deterministic i-o on the 5324 ...
<sb0>
the best thing would be a pin-compatible narrowband part
<sb0>
putting a fpga pll in front of the si5324 should help with non-deterministic skew at power-up, but not with skew fluctuations, yes
<rjo>
i can't see how the fpga pll will hold lock if the si5324 is in the loop
<sb0>
yes, that technique is just a brainstorming idea that may not work, but the other two I posted in the issue should have the expected result
<sb0>
it could also be that Si is using 5326 dies as 5324 in some chips. the 5326 looks like a superset of the 5324
<sb0>
qfn36... I'm a bit hesitant to replace that myself, but mobile phone repair shops eat that for breakfast
<sb0>
yep, it's drop-in
<sb0>
cool
<sb0>
well I can try something: play with the "reserved" registers (that are documented in the 5326 DS) on the kc705 and on kasli, see if there is a difference
<sb0>
going to bed now, if no one objects to the si5326 I'll order one tomorrow