03:19 <_whitenotifier-3> [smoltcp] Dirbaio synchronize pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/JffHD

03:26 <_whitenotifier-3> [smoltcp] Dirbaio synchronize pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/JffHD

03:27 <_whitenotifier-3> [smoltcp] Failure. The Travis CI build failed - https://travis-ci.org/github/smoltcp-rs/smoltcp/builds/676774637?utm_source=github_status&utm_medium=notification

03:35 <_whitenotifier-3> [smoltcp] Success. The Travis CI build passed - https://travis-ci.org/github/smoltcp-rs/smoltcp/builds/676775445?utm_source=github_status&utm_medium=notification

03:40 <_whitenotifier-3> [smoltcp] Dirbaio commented on pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/JfUO4

03:40 <_whitenotifier-3> [smoltcp] Dirbaio edited a comment on pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/JfUO4

16:48 <mtrbot-ml_> [mattermost] <dpn> @rjo Did you ever try to use AD9910 phase autoclear for glitch-free updating while the output is enabled? I am seeing an about SYNC_CLK-long glitch before it assumes the correct phase – looks almost like it first zeros the internal accumulator on reset and then applies the POW 4 ns later

16:59 <rjo> dpn: I had long suspected something like that from the datasheet of the good old AD9858 but never actually checked.

17:17 <mtrbot-ml_> [mattermost] <dpn> I just don't understand how that makes sense (i.e. is anything but an unintended latency mismatch), given that their block diagram shows the POW added to the MSBs of the accumulator output

17:52 <mtrbot-ml_> [mattermost] <hartytp> @dpn IIRC this is an unavoidable issue with the AD9910 (and other DDSs I guess). I hit something like that when trying to do pulse shaping with the AD9910 on mildown (the microwave eta was so low I needed more than the dynamic range of the vga to avoid spin flips). Every time I updates the asf I got a large glitch I couldn’t get rid of

17:52 <mtrbot-ml_> [mattermost] <hartytp> (Using phase tracking on the dogs)

17:52 <mtrbot-ml_> [mattermost] <hartytp> Fpga

17:58 <mtrbot-ml_> [mattermost] <dpn> @hartytp: But constantly updating the profile without autoclear (and to the same value) doesn't cause any glitches, so what would be the mechanism? Or did you have autoclear on as well?

18:34 <rjo> there is non-linear behavior in when pow or asf **change** and that can look like a "glitch" but if you update to the numerical same effective phase (old accu + old POW == new POW + FTW) or the same ASF (without phase autoclear) then there should not be a glitch unless there is a latency mismatch or a bad transient state in the io_update sequencer.

18:35 <rjo> make that "old accu + old POW == new POW"

18:36 <rjo> n.b. SAWG does not do this.

19:22 <mtrbot-ml_> [mattermost] <dpn> Yep, that's what I would have expected, but I'm seeing a glitch even though "old accu + old POW == new POW" (except for the 3 "invisible" lsbs).

19:24 <mtrbot-ml_> [mattermost] <dpn> (There is still the possibility that this is due to an issue with IO_UPDATE TTL alignment when the SERDES is driven from our WIP SUServo core – all this would be much easier to debug if our labs weren't on lockdown.)

21:20 <mtrbot-ml_> [mattermost] <hartytp> That's what I remember seeing as well. I didn't spend too much time on it so it's possible I was doing something daft however

21:23 <mtrbot-ml_> [mattermost] <hartytp> Also, IIRC, what I saw wasn't a step change in the phase (which I think is what @rjo is getting at) but more like it doing something crazy for a single cycle (can't remember if it was a return to zero, but that kind of thing). Anyway, this is a memory from a while back