<whitequark>
oh, I should've mentioned earlier, I managed to get sick again at sunday. third respiratory infection this winter... not sure what's going on
<whitequark>
anyway i feel much better today
<whitequark>
should be able to get things done
<sb0>
bb-m-labs: force build --props=package=artiq-kasli-satellite artiq-board
<bb-m-labs>
build forced [ETA 18m29s]
<bb-m-labs>
I'll give a shout when the build finishes
<GitHub60>
[artiq] enjoy-digital commented on issue #908: @marmeladapk: for a case that is failing like the last you posted, i also need the results with the patched bootloader. For example i see in your results that you have small delays intervals on module 4 and 1 and would like to see each tap results for them. https://github.com/m-labs/artiq/issues/908#issuecomment-367238738
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined #m-labs
mumptai_ has quit [Quit: Verlassend]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<GitHub60>
[artiq] sbourdeauducq commented on issue #908: Noisy IOs and/or non-monotonic delays? Needs some low-pass filtering of the working zones? Or longer tests to determine if the zone is working or not? https://github.com/m-labs/artiq/issues/908#issuecomment-367261339
<GitHub63>
[artiq] sbourdeauducq commented on issue #908: Noisy IOs and/or non-monotonic delays? Needs some low-pass filtering of the working zones? Or longer tests to determine if each point is working or not? https://github.com/m-labs/artiq/issues/908#issuecomment-367261339
<sb0>
rjo, starting to think about DRTIO switching now
<sb0>
how important is cut-through switching? I see it conflicting with distributed DMA, if we support DMA to a downstream non-local peripheral (which we probably want, for the RTM FPGA on Sayma)
<sb0>
though Sayma cannot use cut-through switching in any case, since the data rates are different between the backplane and RTM FPGA
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<GitHub-m-labs>
[buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vAEtA
<GitHub-m-labs>
buildbot-config/master 786314e whitequark: Enforce identical versions in artiq and artiq-win64-test builders.
bb-m-labs has joined #m-labs
<whitequark>
bb-m-labs: force build artiq
<bb-m-labs>
build #2076 forced
<bb-m-labs>
I'll give a shout when the build finishes
<GitHub13>
[artiq] enjoy-digital commented on issue #908: @marmeladapk: thanks that's interesting. Can you send me your bistream, i'd like to see if it's also failing on the HK's boards. If so i'll be able to try to improve the read-leveling algorithm and do tests.... https://github.com/m-labs/artiq/issues/908#issuecomment-367273717
<GitHub21>
[artiq] enjoy-digital commented on issue #908: @marmeladapk: thanks that's interesting. Can you send me your bistream, i'd like to see if it's also failing on the HK's boards. If so i'll be able to try to improve the read-leveling algorithm and do tests.... https://github.com/m-labs/artiq/issues/908#issuecomment-367273717
<GitHub125>
[artiq] jordens commented on issue #908: I would not invest too much time into workarounds using the algorithm but look at the hardware. Non-monotonic delays look unlikely (The jumps are as large as a a quarter of the entire range). Noisy signals and power supplies would be my suspects. Those won't be resolved by the algorithm. https://github.com/m-labs/artiq/issues/908#issuecomment-367297515
<sb0>
_florent_, your code looks ok at first sight
<sb0>
(gth multilane)
<sb0>
one thing I don't understand is there is also a RX buffer bypass multilane alignment procedure mentioned in the manual
<sb0>
how does that work? are you supposed to match the transceiver lanes outside the FPGA to < UI
<sb0>
(anyway, we shouldn't use that, unless I misunderstand what this does)
<GitHub168>
[artiq] sbourdeauducq commented on issue #908: Unless I'm misunderstanding something, it seems to me that there are sizable islands of stability: having an algorithm that can hit them despite the noise doesn't sound very complicated, and would allow us to move forward while the problem gets properly resolved. To help with that, maybe the diagnostics above can be printed at all times when running on Sayma. Getting th
<GitHub74>
[artiq] hartytp commented on issue #908: I agree, seems likely that there is a SI/PI/grounding issue that's hit when the FPGA load is high (which wouldn't have been spotted in the initial tests that @gkasprow did before shipping Sayma).... https://github.com/m-labs/artiq/issues/908#issuecomment-367306784
<GitHub33>
[artiq] hartytp commented on issue #908: @enjoy-digital I assume you have all the data you need on this thanks to @marmeladapk, but let me know if you want me to do anything else (I'm back on this now). https://github.com/m-labs/artiq/issues/908#issuecomment-367307157
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub112>
artiq/master afc16a6 Florent Kermarrec: firmware/liboard/sdram.rs: iterate read multiple times in read_delays to avoid false positives
<rjo>
and it works well at 62.5 MHz SPI clock.
<sb0>
rjo, where there solved by the new spi core, which would be an indication that the current one is buggy and could be the source of the hmc830 issues?
<GitHub102>
artiq/master 91a4a7b Robert Jordens: kasli: free run si5324 on opticlock for now
<GitHub102>
artiq/master 7a1d715 Robert Jordens: ttl_serdes_7series: drive IBUF and INTERM disables from serdes
<GitHub102>
artiq/master 476e4fd Robert Jordens: ttl_serdes_7series: disable IBUF and INTERM when output
<rjo>
i don't think they were solved by the core but by the usage pattern. but yes. we should really try the new one.
<GitHub51>
[artiq] whitequark commented on issue #883: I don't think this has anything to do with async RPCs. Even wrapping the offending line in `try`/`except` silences the bug (that is otherwise moderately easy to reproduce, it usually surfaces within ten iterations if running the test in a loop). Any attempts to observe t1/t2 also hide the bug. This seems to point to a miscompilation of some sort. https://github.com/m-lab
marmelada has joined #m-labs
<marmelada>
quick question: can I use artiq on kasli to control dio module?
<rjo>
marmelada: yes. both variants. i'll commit a better driver today.
<rjo>
marmelada: using artiq for testing the boards would be great.
<rjo>
marmelada: and you can use the usb-i2c stuff concurrently with artiq running. i.e. you can test/toggle the EEM DIO lines and switch termination via USB. artiq currently uses the I2C bus only during initialization to set up the Si5324.
<rjo>
marmelada: there is also code in my kasli-i2c repository to manage and comission the EEM eeproms.
<GitHub141>
[artiq] whitequark commented on issue #883: On second look, this does have *something* to do with async RPCs, but not at all clear what. The following experiment reproduces the crash, often at the first iteration:... https://github.com/m-labs/artiq/issues/883#issuecomment-367339578
<GitHub137>
[artiq] whitequark commented on issue #883: On second look, this does have *something* to do with async RPCs, but not at all clear what. The following experiment reproduces the crash, often at the first iteration:... https://github.com/m-labs/artiq/issues/883#issuecomment-367339578
<GitHub35>
[artiq] whitequark commented on issue #883: On second look, this does have *something* to do with async RPCs, but not at all clear what. The following experiment reproduces the crash, often at the first iteration:... https://github.com/m-labs/artiq/issues/883#issuecomment-367339578
<GitHub74>
[artiq] whitequark commented on issue #925: I don't think that should go into 3.5. It's not a bug but an artefact of how imported names are represented (they're basically just locals), and it's not trivial to change. https://github.com/m-labs/artiq/issues/925#issuecomment-367346656
<GitHub113>
[artiq] whitequark commented on issue #925: It's the same as (2). The compiler can see that the two functions are one and same, and types inferenced for the local name propagate to the non-local name. https://github.com/m-labs/artiq/issues/925#issuecomment-367348155
<GitHub141>
[smoltcp] phil-opp commented on issue #140: @whitequark I merged @dlrobertson 's improvements and rebased on master. I also squashed my commits. I left the new commits from @dlrobertson unsquashed to make the review easier and to keep the author information. https://github.com/m-labs/smoltcp/pull/140#issuecomment-367351132
hartytp has joined #m-labs
<hartytp>
rjo: we remeasured the Si5324 with a good XO instead of the Xtal. Performance doesn't change much
<hartytp>
so, it's a bit crappy
<hartytp>
:(
<hartytp>
thinking out loud, but what do you think of the suggestion of replacing the Si5324, HMC830 and HMC7043 all with the HMC7044
<hartytp>
?
<hartytp>
(the integration + performance arguments for the 7044 seem much stronger IMHO if we are proposing to use both loops)
<GitHub109>
artiq/master a63fd30 Robert Jordens: urukul: use spi2...
<rjo>
hartytp: are you sure the hmc7044 works for narrow bandwidth locks?
<hartytp>
I believe so. e.g. the datasheet shows plots for PLL 1 BW = 70Hz
<hartytp>
depends on how low
<hartytp>
obviously, this would need proper thought
<hartytp>
and would need to measure the CDR noise using Kasli first
<hartytp>
+ buy a 7044 and lock it to Kasli
<rjo>
for kasli we should look at sth like si5369 next time. much reduced jitter, more outputs, etc.
cr1901_modern has joined #m-labs
<rjo>
larsc talked to the hmc7044 designer a couple days ago. maybe we can quiz him on that (hmc7044 for narrow band CDR applications and as a jitter suppressor).
<hartytp>
sounds like a good plan
<hartytp>
larsc?
<rjo>
hartytp: to me that cascaded pll design of the hmc7044 looks exactly like what Si is talking about in their DSPLL appraisal material as the root of all evil in "regular" PLL designs. and i think i do understand their reasoning.
<rjo>
larsc: ping
<hartytp>
I like the HMC7044 over the Si chips because all the analog parts are *much* better specified.
<hartytp>
it actually gives one the data to make a decision
<rjo>
(our resident ADI expert)
<rjo>
hartytp: you are still buying eval boards and determine those analog specifications yourself.
<rjo>
well. the hmc7044 says jitter attenuator in the title. so i guess it can do that.
<hartytp>
the data sheet for the 44 has a lot of info and some helpful plots
<rjo>
that said. i like the idea of replacing the three chips with the 7044. the only unknows are (1) the same reasons Si is dissing that cascaded PLL idea (2) someone would have to look very closely at that design and do tests.
<rjo>
but e.g. specifically "jitter tolerance" is not specified for the hmc7044 while for the Si5324 it is.
<rjo>
that would be something very relevant for our application.
<hartytp>
larsc: thinking of recovering a clock from a MGT putting it through a HMC7044
<hartytp>
narrow band 1st loop with a decent XO
<hartytp>
to lock to the CDR clock from the FPGA
<hartytp>
wideband second loop
<rjo>
larsc: what's know about the jitter tolerance of the hmc7044? the Si5324 e.g specifies 5e-6/bandwidth pk-pk.
<hartytp>
to produce a 2.4GHz data converter clock
<hartytp>
rjo: what do you mean? You're worried about the PFD going non-linear?
<hartytp>
NB unlike the Si5324, we'd probably have to use the 1st PLL in integer-n mode, with a fixed-frequency XO. That limits the clock frequencies it can take from the FPGA
<rjo>
hartytp: it'll loose lock.
<rjo>
lose
<sb0>
hartytp, the si5324 is easy to program. can't say the same about the hmc chips, which are the usual mess.
<hartytp>
well, I was surprised how easy the 7043 was actually
<hartytp>
rjo: hmmm...will it? Loop filter should average most of that
<larsc>
could work
<larsc>
I guess the amount of jitter you can remove depends on the loop-filter bandwidth
<hartytp>
(i.e. AFAICT, it's not specified because it depends on the loop filter. It's a parameter that one designs/tunes using the PLL simulation tools.)
<sb0>
also we're using the si5324 hitless switching feature in drtio
<larsc>
but PLL1 is supposed to run with a very narrow loop filter
<hartytp>
IIRC, the ADI simulation tools tell one all of that
<rjo>
hartytp: is says so in the datasheet.
<hartytp>
remind me where?
<hartytp>
sb0: ack, but I think the 7044 supports that as well
<larsc>
the PLL1 has a 16-bit pre-divider, you can almost use it like a fractional pLL
<larsc>
the extra noise is not a problem I've been told
<larsc>
since the loop filter takes care of it
<rjo>
hartytp: si53xx family ref man, page 36, top.
<hartytp>
right, but I don't think that applies to the HMC7044
<hartytp>
it's a different topology
<hartytp>
the 7044 is a classic PLL.
<rjo>
maybe. but it would be nice to have that (that the tolerance continues to dive with 20db/decade) on paper.
<rjo>
or measured.
<hartytp>
larsc: if you use the prescaler then you run the PFD at a lower frequency. Doesn't that kill the noise? Remember that our reference is crap
<hartytp>
rjo: ack. But, IIRC, that's something we get out of the ADI PLL simulator once we've designed the loop filter (or, better, we design the loop filter to ensure an acceptable tolerance)
<larsc>
hartytp: I was told to not worry about it since it will not be the dominating noise
<larsc>
might be an issue if the reference is really bad
<larsc>
PLL sim might help
<hartytp>
okay, I can believe that on reflection. Argument is that close-in frequency noise is essentially just the Q of the reference oscillator one uses. Assuming the PFD/divider don't contribute noise then the output noise
<hartytp>
only depends on how good the Q of the XO is, not on its frequency
<hartytp>
(not the case for wideband noise)
<hartytp>
so, you're probably better off getting a really good 10MHx XO and using that as the first-stage reference
<hartytp>
(i.e. argument is that the close-in noise of XOs generall scales as 20log10(f) so, as long as the PFD/prescaler noise floor aren't a limitation then the XO frequency doesn't matter)
<hartytp>
hmmm...maybe the best thing to do is to measure the CDR noise with Kasli and then put that into the HMC7044 PLL designer and see what we can expect
<larsc>
my understanding is what matters for the final output is the noise of the vcxo
<larsc>
the loop filter is supposed to remove the noise from the reference
<larsc>
and the feedback path?
<hartytp>
right. but (1) you are using a lower frequency VCXO so you have to check that that still doesn't have worse noise (it shouldn't IIRC)
<hartytp>
(2) and that the prescaler/PFD don't contribute more noise at lower VCXO frequencies
<hartytp>
feedback path?
<larsc>
the recomendation is to run the vcxo as high as possible
<larsc>
to the limit of pfd2
<larsc>
which is 250MHz iirc
<larsc>
if you have a 125MHz reference use the frequency doubler
<hartytp>
hmmm...but our CDR frequency can be 125MHz or 150MHz
<hartytp>
(unless we can just change that using the FPGA PLL settings?)
<larsc>
the noise from the vcxo will be multiplied up by the N1 divider
<larsc>
but that goes to the PLL1
<larsc>
and the narrow loop filter
<larsc>
the noise of the clock to PLL2 should not be affected by the divider
hozer has joined #m-labs
<hartytp>
sb0/rjo: how flexible can we be with the clock output from the FPGA? Can we have the same frequency for all different RTIO frequencies?
<hartytp>
(then divide the HMC7044 VCO down to get the RTIO frequency)
<sb0>
the transceiver clock output is inflexible; iirc you get a divide-by-2 at best. other ratios need an additional PLL or divider inside the FPGA.
<hartytp>
okay, well it's either that or use a relatively low frequency VCXO for the first loop and use the prescaler in the HMC7044
<larsc>
what you care about is that the VCXO is an integer ratio of the final output clock
<larsc>
to keep N2 small
<sb0>
also FPGA PLLs are noisy
<larsc>
and R2
<larsc>
the frequency of the reference doesn't really matter that much
<larsc>
can be fractional
<hartytp>
k
<hartytp>
true
<hartytp>
so e.g. use a 100MHz VCXO
<hartytp>
for 125MHz use R1=5, N1=4
<rjo>
whitequark: hmm. that artiq-dev that is being used is exactly the one from five days ago when you and sb0 were working on the buildbot/conda.
<hartytp>
for 150MHz use R1=3, N1=2
<hartytp>
then lock the second VC0 to that with an integer-N lock
<hartytp>
that works
<hartytp>
nice
kaalia has quit [Remote host closed the connection]
<sb0>
hartytp, do you want me to reconnect the kasli to ethernet tomorrow?
<hartytp>
for?
<sb0>
drtio testing
<hartytp>
was planning to wait until ours arrives back from florent
<hartytp>
should be any day now
<hartytp>
local tests are easier
<sb0>
hartytp, okay. can you test the ad9910 with the hardware you already have?
<hartytp>
yes
<hartytp>
will do
<rjo>
hartytp, marmelada: do you guys have an update on the status of urukul, kasli, zotino, sample, grabber, dio-x?
<sb0>
whitequark, was there an issue with async RPCs or not?
<GitHub32>
[artiq] gkasprow commented on issue #908: For every board, before shipment I loaded Xilinx DDR reference design that writes memory and reads it back. I left for a few minutes to make sure no errors were detected.... https://github.com/m-labs/artiq/issues/908#issuecomment-367396291
<GitHub186>
[artiq] hartytp commented on issue #908: @gkasprow Is it possible that there are problems that only show up when the FPGA load is high (e.g. with the SAWG gateware etc)? If so, your test might have missed the problem? https://github.com/m-labs/artiq/issues/908#issuecomment-367396658
<GitHub46>
[artiq] hartytp commented on issue #908: Well, if you can do it without too much trouble, it might be worth making an eye measurement on a Sayma board with ARTIQ running (including SAWG). https://github.com/m-labs/artiq/issues/908#issuecomment-367397621
<GitHub48>
artiq/master be704b1 Sebastien Bourdeauducq: RELEASE_NOTES: mention short options for artiq_flash
<GitHub88>
[artiq] hartytp commented on issue #908: Why? Don't you just need to look with a scope? Is the issue that you need a fixed pattern of writes to the SDRAM to look at? Maybe @sbourdeauducq or @enjoy-digital can help you modifying ARTIQ to do that? https://github.com/m-labs/artiq/issues/908#issuecomment-367408388
<GitHub2>
[artiq] sbourdeauducq commented on issue #908: I don't see how the Xilinx core can do a full eye scan alone. Is there some hidden IOB feature that changes the threshold voltages with high resolution? https://github.com/m-labs/artiq/issues/908#issuecomment-367414886
<GitHub80>
artiq/master a5ad1dc Robert Jordens: kc705: fix sdcard miso pullup
<GitHub80>
artiq/master 0d81450 Robert Jordens: test_spi: move to new spi2 core
<GitHub80>
artiq/master 898bad5 Robert Jordens: spi2: fixes
X-Scale has joined #m-labs
marmelada has quit [Quit: Page closed]
reportingsjr has quit [Quit: WeeChat 1.4]
<GitHub167>
[artiq] gkasprow commented on issue #908: @hartytp We managed to trigger it twice. I mean it happened in the night when nobody was looking. I could only check that it was caused by overvoltage.... https://github.com/m-labs/artiq/issues/908#issuecomment-367435026
<bb-m-labs>
build #1246 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1246 blamelist: Robert Jordens <rj@m-labs.hk>, Robert Jordens <jordens@gmail.com>
<bb-m-labs>
build #2085 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2085 blamelist: Robert Jordens <rj@m-labs.hk>, Robert Jordens <jordens@gmail.com>