<GitHub-m-labs>
[artiq] hartytp commented on issue #801: > I'd like to hear from other users before cutting AM/PM, but it's fine from my vantage point especially if it makes resource counts go from 'more than we have' to 'workable'.... https://github.com/m-labs/artiq/issues/801#issuecomment-416872415
<GitHub-m-labs>
[artiq] hartytp commented on issue #801: > @hartytp This is actually to feed-forward frequency noise from the laser we use for our 2-qubit gates. We're correcting for acoustical noise in the laser cavity (dominant noise peaks are a few hundred Hz), not slow drifts (like the ones you mention) that we intend to address by recomputing.... https://github.com/m-labs/artiq/issues/801#issuecomment-416874751
sb0 has quit [Ping timeout: 244 seconds]
sb0 has joined #m-labs
attie has quit [Remote host closed the connection]
attie has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
sb0 has quit [Ping timeout: 240 seconds]
hartytp has joined #m-labs
<hartytp>
larsc: thanks
<hartytp>
I'd seen that about the JESD204B DACs
<hartytp>
but, we have a few use-cases that need a DAC that's DC precise/low-noise, but that has a sample rate of 10MHz or so, so a few times higher than SPI can provide
<hartytp>
in that case, JESD204B is overkill (and, in any case, most of those DACs aren't great at DC)
<hartytp>
so, it's really nice to have a parallel 16-bit DAC with decent noise/temp co etc, but it seems that ADI is moving away from providing those
<GitHub-m-labs>
[artiq] jordens commented on issue #1141: This is AD9910-specific. I have seen it as well. And we know that its bigger brother the AD9914 is equally easy to bring into a locked up state. I'd hypothesize that a multi-transfer SPI transcation is interrupted mid-way (due to an underflow or due to bad initialization or due to some other reason) and the AD9910 machinery is driven into a non-recoverable state by subs
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1141: > In this experiment we have a Kasli master and DRTIO satellite, with one Urukul on the master, and 2 on the satellite. We have seen channels on both the master and satellite lock up.... https://github.com/m-labs/artiq/issues/1141#issuecomment-416904872
<GitHub-m-labs>
[artiq] cjbe commented on issue #1141: @sbourdeauducq yes - we have two Kasli master-satellite DRTIO setups running at 125 MHz. They have both been running for several months without any problems. https://github.com/m-labs/artiq/issues/1141#issuecomment-416905765
<GitHub-m-labs>
[artiq] hartytp commented on issue #1141: @gkasprow better to make sure that the code doesn't put the AD9910 into this state to begin with (I've used AD9910s continuously updating for months without any issues, so I know that they can be programmed reliably). https://github.com/m-labs/artiq/issues/1141#issuecomment-416907482
<GitHub-m-labs>
[artiq] cjbe commented on issue #1141: @sbourdeauducq the legacy systems @hartytp is referring to just use an FSM that cannot be interrupted to generate the SPI transactions. I think the point is that it is the interruption of the SPI transaction in the middle of a multiword transfer that causes the DDS to misbehave, rather than an inherent bug in the DDS itself if one completes the transactions properly.
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1141: There is an inherent bug in the DDS chip if it doesn't recover from interrupted SPI transactions after a master reset. Resets ought to be able to clear any chip state that can be programmed from a digital interface. https://github.com/m-labs/artiq/issues/1141#issuecomment-416912406
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1141: And, while it is not strictly a bug, it is poor design that interrupted transfers put the chip into a broken state. Try breaking the Si5324 by comparison. But, at least the master reset on the AD9910 puts the chip into a working state, contrary to the AD9914 where everything is borked after a reset. Sigh...... https://github.com/m-labs/artiq/issues/1141#issuec
<GitHub-m-labs>
[artiq] jordens commented on issue #675: As this is exclusively monitoring and injection for the sum, there are 8 injection and 8 monitoring channels. that could still be doable with the current design. I should have numbers on the resource/routing impact soon. https://github.com/m-labs/artiq/issues/675#issuecomment-416933434
sb0 has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
rjo: manually, look where errors happen and put it in the middle of the working zone
<rjo>
errors == siphaser alignment failures?
<sb0>
no, drtio data corruption
<sb0>
this controls the skew between the noisy transceiver recovered clock and the si5324 output
<sb0>
the transceiver outputs data in its recovered clock domain, and it is re-registered into the si5324 output domain by RXSynchronizer
<sb0>
RXSynchronizer is a bunch of FFs placed next to each other, and has large data eyes. most SIPHASER_SKEW values work.
<rjo>
sb0: without a CDC?
<sb0>
CDCs don't have deterministic latency
<rjo>
or RXSynchronizer is a "CDC that assumes reasonably well aligned phase"
<sb0>
it's a data recapture in a phase-aligned domain. if you set it to None it gets replaced with an elastic buffer (useful for debugging if you suspect problems there)
<sb0>
an elastic buffer gives you latency non-determinism instead of data corruption when the phases aren't right
<rjo>
yeah. i get that.
<rjo>
coarse (1/rtio_freq) non-determinism.
<sb0>
if we start getting a lot of problems with this thing, we should write an autocal routine for it. send PRNG data through RXSynchronizer and scan the phases
<sb0>
btw, there are several WR implementations that have the transceiver elastic buffer enabled, and just assume that the clock phase is right for deterministic latency ...
<rjo>
hmm. you LOCed them. for async reset synchronizers which are the same structure (FFs close together) the recommended way is with ASYNC_FF and a timing constraint. just FYI. I am not keen on rewriting it.
<rjo>
or RLOC. well I guess that's fine.
<rjo>
and SIPHASER_PHASE is stable enough across rebuilds/logic added/removed?
<sb0>
on 7-series yes, but I'm not really sure on ultrascale
<rjo>
(SKEW, not PHASE) and you'd expect SIPHASER_SKEW to be a constant **delay** and not necessarily a constant number of PSINCDECs, right?
<sb0>
it is definitely not a constant number of PSINCDEC, since the latter depends on what skew the Si5324 has after locking
<sb0>
it is the target skew between the CDR output and the Si5324 output
<rjo>
i mean a constant offset of PSINCDECs from the 0->1 transition.
<sb0>
ah, yes
<rjo>
and finally: any reason to choose 1200 MHz for that second MMCM VCO and not something closer to the max int(1440 MHz/rtio_clk_freq)?
<rjo>
... i meant the divider closer to the max, which is int(...)
<rjo>
... in order to get max phase shift resolution.
<sb0>
no. afaict I just read the datasheet wrong and thought the maximum frequency was 1200, while it is 1440 for that speed grade
<rjo>
ok. SIPHASER_SKEW both 32 for kasli and sayma is that coincidence?
<rjo>
sb0: ah. i guess 1200 MHz because it is the max for our Sayma grade.
<sb0>
sayma is less tested, I just modified that value around a bit and the margins looked fine
<sb0>
I guess the best/rigorous way to do this is the autocal with PRNG. also helps with pinning down any P&R/P/V/T variations
<sb0>
it could scan around the programmed value and check the margins like the jesd204 sysref code
<sb0>
could be PRNG or just flip all bits on every cycle
<rjo>
can't we use the data strem from the master, i.e. assume mostly K
<GitHub-m-labs>
migen/master 97e2651 Robert Jördens: kasli: set USERID and USR_ACCESS...
<sb0>
the rx synchronizer is after 8b10b decoding
<sb0>
moving it before needs changing the code + breaks compatibility with potential transceivers with built-in 8b10b decoders that cannot be disabled
<sb0>
the K sequence is a much inferior test pattern than 0xffff / 0x0000
<sb0>
the rest of the stack needs to be disabled anyway while doing the calibration to avoid processing garbage data, so a gateware change is needed anyway
<sb0>
finally, assuming the K sequence from the transceiver increases fragility
<sb0>
(what if the master wasn't sending Ks, what if the receiver isn't working properly?)
<rjo>
hmm. why is it not sufficient to just use the noisy GT clock again and align to that? what am i missing.
<rjo>
wouldn't you be doing the same thing with 0xffff/0x0000?
<rjo>
btw. i noticed that all my cases where i had "nothin on the UART" with kasli bitstreams were simply due to v1.0/v1.1 mismatch. weren't hartytp and marmelada also reporting those?