<GitHub-m-labs>
artiq/master e21b796 Robert Jördens: sayma_amc: change test patterns for 'without-sawg'
hartytp_ has joined #m-labs
<hartytp_>
sb0: what's the plan + timeline for Sayma?
<hartytp_>
I can see two pressing issues
<hartytp_>
1. serwb doesn't work on either my board or yours
<hartytp_>
needs fixing as it makes everything else a pita to fix
<hartytp_>
2. you should probably do the HMC7043 reset rework on your board if possible before doing much more debugging
<hartytp_>
3. Now that the JESD looks fixed, what about the "sawg issues"
<hartytp_>
rj0: let me know if there is anything else you want me to test with a scope for that
<hartytp_>
rjo
<hartytp_>
^
<rjo>
hartytp_: getting scope screenshots of ch0 and ch1 from that last commit (without-sawg) would be great.
<hartytp_>
ack will do
hartytp has quit [Quit: Page closed]
<rjo>
hartytp_: thanks. and if ch1 looks like 50MHz, a spectrum analyzer shot 0-600 MHz.
<hartytp_>
ack
<rjo>
_florent_: how is stpl coming?
marmelada has joined #m-labs
<hartytp_>
larsc: thanks for the info
<hartytp_>
so, if we want to hit 300ps setup and hold with a 2.4GHz DAC clock (416ps period) we have to be aligned to better than 100ps
<hartytp_>
so, the Si5324 isn't a good enough phase shifter if we want to work at max DAC clock
<hartytp_>
not an issue for testing v1.0, but we add a better phase shifter for v2.0.
<hartytp_>
still though, it's going to be tight!
<rjo>
i think the data clock is the one.
<hartytp_>
?
<hartytp_>
hmmm...maybe we should have used the 7044 after all
<hartytp_>
from a quick skim over the data sheet, it looks as though the sync mechanism for that is *much* easier because is does both the PLL and the sync stuff
<hartytp_>
from a quick skim over the data sheet, it looks like the SYNC input there only needs to meet s/h w.r.t. the reference clock, and then it takes care of syncing the DAC clock to the reference clock
<hartytp_>
i.e. with a HMC7044 driven from a good reference, it looks like multi-board DAC sync becomes trivial
<hartytp_>
(i.e. we could drive the sync pin from an FPGA pin without issues)
<hartytp_>
would need to read the data sheet more carefully
<rjo>
i thought we were feeding dacs with the data clock (not dac clock) and the s/h timings are w.r.t. that.
<hartytp_>
I don't think so
<hartytp_>
SYSREF needs to pick out a particular edge of the DAC clock to reset the JESD LMFC on
<rjo>
and maybe the 7044 also has surpassed that anachronistic "internal" spi bus that doesn't do readback.
<hartytp_>
right
<hartytp_>
basically, in the current arrangement, multi-board sync scares me. even if we try to feed HMC7043 RFSYNCIN from a phase-shifted WR clock, the timing window we have to meet for a 2GHz+ DAC clock is tiny
<hartytp_>
but, if we move to the 7044, we just have to meet s/h on a 150MHz/125MHz reference clock, which is trivial
<hartytp_>
well, based on my initial reading of the data sheet
<hartytp_>
if we want to consider this seriously, I'll buy an eval board and prototype it
<hartytp_>
anyway, food for thought
<rjo>
technically for jesd204b you don't need that. the interpolation happens after all the non-deterministic stuff. but i haven't looked at it in a while.
<hartytp_>
okay, maybe that's correc then
<hartytp_>
so, it's a 1ns window, which isn't too bad
<hartytp_>
maybe it's not worth changing hw then. still in hindsight the 7044 with WR would have been the way to go
<rjo>
i.e. using the "dac pll" sysref clearly needs to meet timing only w.r.t. the clock that is coming into the chip.
<hartytp_>
so, we feed the DAC with, say a 2GHz clock. It internally divides that to generate the JESD204B clock (it doesn't use CDR)
<hartytp_>
we feed it a SYSREF signal from the HMC7043 which has a deterministic phase w.r.t. the DAC clock
marmelada_ has joined #m-labs
<hartytp_>
that's sampled on the DAC clock? or on the divided clock?
<hartytp_>
(divided=data)
<rjo>
hartytp_: out of curiosity: i guess you have a couple of dlc pros from toptica around. have you ever asked them for the complete and corresponding source code for the gpl items on there?
<rjo>
hartytp_: i should look at it again.
<hartytp_>
gpl items?
<rjo>
well. it's a complete linux system
<rjo>
hit system info -> legal info
marmelada has quit [Ping timeout: 260 seconds]
<hartytp_>
oh, you mean the DLPro itself, not the SDK
<hartytp_>
I haven't
<rjo>
DLC pro.
<hartytp_>
cjbe has used them more than me, but I wouldn't have thought so
<hartytp_>
fwiw, they've hit a few nasty bugs in the interface for at least some software versions
<rjo>
there might be a lot of gpl stuff in their host side software as well. but that's another question.
<rjo>
hartytp_: yes. the interface is a bit irritating and i have also seen bugs.
<rjo>
but the programming api is tidy and well done. if it wasn't for that melody that plays each time you connect to the thing.
<GitHub-m-labs>
[artiq] jordens commented on issue #1054: IMHO it would be better to seize the opportunity to change the API into a single method `select(bitmask)` (plus `set(channel)`: `select(1 << channel)` for backwards compat). That's less code for more feature and additionally represents the underlying protocol.... https://github.com/m-labs/artiq/pull/1054#issuecomment-394742393
<sb0>
I see technosystem are flashing kaslis with artiq now ...
<rjo>
my guess is that's marmelada_
<marmelada_>
yup, that me
<marmelada_>
sb0: is something wrong?
<sb0>
no, that's good :)
<rjo>
marmelada_: in case the burden of testing the EEMs etc is still on you, we have a test infrastructure now to help with that. and there is also tooling for kasli deployment and testing in case you didn't see that.
<marmelada_>
I used memtest from artiq, it's simpler and faster than using xilinx ipcore ;)
<hartytp>
so, building with latest artiq master, I'm getting nothing out of my UART on Sayma
<hartytp>
reverting to an older build I see the normal boot messages
hartytp_ has joined #m-labs
<marmelada_>
rjo: I saw it, but I already have my own scripts for testing most things
<rjo>
hartytp: i managed to get that with kasli as well a few times. always either trying to run two builds in the same directory or bad versions.
<hartytp_>
_florent_: "WARNING: [Vivado 12-4174] DIFF_TERM is not supported in UltraScale devices. Automatically translating DIFF_TERM of TRUE to DIFF_TERM_ADV=TERM_100. Refer to UG571: UltraScale Architecture SelectIO User Guide for more detail. "
<hartytp_>
hmm still nothing on the UART
sb0 has quit [Quit: Leaving]
<hartytp>
okay, checked my conda environment and everything looks up to doate
<hartytp>
but, I get silence
<hartytp>
so can't look at DAC outputs atm
<hartytp>
(feel free to send me binaries if you want, otherwise, not sure how to debug this)
hartytp_ has quit [Quit: Page closed]
<_florent_>
rjo: stpl is implemented and is done at each jesd init
<_florent_>
rjo: EBs are now between the link layer and phy, so CGS/ILAS/STPL/DATAs all go through them
<_florent_>
sb0: difference of latency in the EBs is now compensated by the DAC, so i don't thin we need a single EB
<rjo>
_florent_: ok. then the only part of the jesd core not tested by STPL is the framer?
<_florent_>
rjo: the framer should also be covered by the stpl
<_florent_>
rjo: at least i mean, when using data from the swag we have: swag --> transport --> link --> eb --> phy
<_florent_>
rjo: with stpl we have: stpl --> transport --> link --> eb --> phy
<rjo>
_florent_: ack. i see. that's good. then let's wait for data.
rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo>
_florent_: and just to confirm again: the sample order in jesd.core.sink.convert? is Cat(oldest/earliest ... newest/latest) right?
<rjo>
s/convert/converter/
<rjo>
_florent_: and one other thing: the EBs should only be brought out of reset when the phase between their two sides is stable. afaict that means bringing keeping at least one of the two CDs involved in reset until after the phys have locked.
<rjo>
otherwise the EB head and tail trample on each other.
<hartytp>
_florent_ my previous tests of serwb didn't use the latest migen, so I didn't have the diff_term entry
<_florent_>
rjo: for the EB, we wait until the phy initialization is done to release the phy reset that is used in the EB, so that's fine no?
<_florent_>
hartytp: yes
<hartytp>
_florent_: what about the warning I posted?
<hartytp>
_florent_: okay, building with that
<_florent_>
hartytp: vivado is able to translate it, but yes we should fix it
<rjo>
hartytp: the steps are expected. as i said it's a sampled system.
<rjo>
_florent_: and "phy initialization is done" includes the clocks that ultimately drive the phy-side of the EBs being in lock and maintaining lock after that?
<_florent_>
rjo: yes
<rjo>
_florent_: ack.
<_florent_>
rjo: in case there are still some doubts about the eb, one test we could do is increase the depth of the EB,
<rjo>
hartytp: what "noise" are you referring to?
<_florent_>
rjo: we should be able to visualize that the behaviour is different with various EB depth
<rjo>
_florent_: yes. but if the clocks are not phase stable then more depth will only lower the probablility of the problem.
<hartytp>
rjo: by noise, I mean the steps and noise arround them (which I assume is ringing in my cabling).
<hartytp>
I know it's a sampled system
<_florent_>
rjo: so once gth initialization is done
<hartytp>
not saying it's unexpected, I just haven't looked at what sample rate/clock speed we're using
<hartytp>
so haven't got well-defined expectations
<rjo>
hartytp, _florent_: thanks a lot. that looks good to me. now someone with a working sayma needs to look at the sawg outputs.
<rjo>
hartytp: but the steps are just 600 MHz. they are expected.
<rjo>
hartytp: the noise around them is a bit weird but could be cabling. it's certainly not the data or jesd.
<rjo>
marmelada_: yes. please file an issue in artiq. forget sinara#539
<hartytp>
rjo: looks better with a balun, but I'd guess it's just reflectiosn
<marmelada_>
rjo: ok
<hartytp>
rjo: "now someone with a working sayma needs to look at the sawg outputs." marmelada did that, right?
<rjo>
hartytp: yes. and just to ddx what marmelada_ is describing: that pattern on ch0 and ch1 is stable over tens of seconds and it is reproducible across restarts (2 reproductions is fine for now, i know testing this hurts a lot).
<sb0>
_florent_, what do you think of a simpler serwb?
<_florent_>
sb0: i think the issue you were having were related to the low speed version
<sb0>
focused on robustness (crc, timeouts, etc.)
<_florent_>
sb0: yes why not, but i don't think i'll have time now to do that
<GitHub-m-labs>
[artiq] jordens commented on issue #1058: Well. 301 MHz is Nyquist + 1 MHz. I would expect full scale AM at close to 1 MHz. Maybe that's aliased with the scope trigger rate to what you are seeing.... https://github.com/m-labs/artiq/issues/1058#issuecomment-395086546
<sb0>
_florent_, fixing the current code is faster?
<_florent_>
sb0: what were the issue you recently had with serwb?
<sb0>
I've seen lockup during "wishbone test", and also sometimes when reloading the AMC it would not establish the link
<sb0>
this was before the 7043 rework, though
<_florent_>
sb0: the low speed version has some corner case initialization issue i'm aware, but not the high speed
<hartytp>
sb0: seems like a shame to go to a very low line rate if we don't need to
<sb0>
I mean the 7043 is happy
<sb0>
the DACs get clocked etc.
<hartytp>
but, crcs/timeouts/other ways of making it more reliable sound like a good idea
<_florent_>
sb0: for now i suggest you regenerate with 1gbs serwb and we'll advice if we still have issues
<sb0>
_florent_, ok, will do
<sb0>
rjo, do you have better suggestions or should I hook up microscope to the SAWG outputs?
<rjo>
sb0: better than?
<sb0>
than looking at the SAWG outputs (before the jesd core) with microscope
<rjo>
isn't that the same?
<sb0>
same as?
<rjo>
you seem to be asking "(bettern than A) or A".
<rjo>
no. as i said. right now i'd like someone to look at the rf output and check whether the issues are still there.
<rjo>
from the looks of it they are gone.
<sb0>
rjo, since the JESD core EB update?
<sb0>
that did not fix them
<sb0>
I have 4.0.dev+1114.g988054f4 and latest JESD, and the issues are ther
<hartytp>
rjo/sb0: am I missing something, or should we be using DIFF_TERM on all the LVDS EEM lines on Kasli?
<rjo>
sb0: do you have scope screenshots (without clipping, proper resolution, useful persistence value)
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #1058: @jordens For every frequency above 300 MHz the effect is the same. Well if Sayma doesn't support frequencies above 300 MHz then there's nothing to talk about. https://github.com/m-labs/artiq/issues/1058#issuecomment-395093932
<hartytp>
100/100 successful inits (without SAWG, and no power cycles)
<bb-m-labs>
build #2430 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2430 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<marmelada_>
if I synthesize without-sawg then I'll always get sawtooth on dacs or do I have to run some experiment?
<rjo>
marmelada_: output is independent of everything.
<rjo>
marmelada_: thanks for doing that. should look like the pictures tom posted earlier.
<hartytp>
am I right in thinking that joe is expecting 2 Sayma synchronised together for next week?
<hartytp>
with sawg working?
<marmelada_>
yup
<marmelada_>
if I'm correct it's next Tuesday
<hartytp>
but, the synch *between* the sayma
<hartytp>
because no one has started on that yet
<hartytp>
IIUC
<hartytp>
that seems like a long shot to get working for tuesday
<sb0>
where is that tuesday coming from?
<hartytp>
review meeting
<hartytp>
keeps the money coming in
<hartytp>
but, this is all second hand, I'm not sure of what the expectations are
<hartytp>
if we can get SAWG on sayma reliable by then, I'll be very happy
<sb0>
yea...
<hartytp>
SC1 on a single board would be amazing
<sb0>
sc1 doesn't seem so far from working
<hartytp>
but, who knows, if we do the SC1 my way with teh Si5324 it may work with some simple fw
<hartytp>
between boards as well
<sb0>
yeah, who knows. the main issue with sayma isn't designing or coding things, it's debugging. things never work and almost all the time is spent chasing obsure issues...
<hartytp>
well, after the HMC7043 init, things have seemed to make sense
<sb0>
the SAWG is still producing broken waveforms, and #998 is inexplicable
<hartytp>
sb0: just installed a fresh conda environment, it's still pulling in migen 6425844
<rjo>
sb0: was phaser (kc705) ever tested since sed?
<hartytp>
not ca28...
<sb0>
rjo, no
<sb0>
rjo, but at least one of the SAWG bugs is triggered by changing the amplitude, which would be only RTIO data that is opaque for SED, right?
<rjo>
sb0: was sed tested with wide rtio?
<rjo>
sb0: not if sawg is the only one exercising rtio_output_wide for example.
<rjo>
what do you want to ask me about that issue?
<sb0>
the only thing that changes between the sine and the broken wave is the value in "self.sawg1.amplitude1.set(0.5)"
<sb0>
can the broken wave be produced by sawg if the amplitude data word is corrupted?
<rjo>
yes.
<hartytp>
_florent_: stpl error about 1% of the time. other than that 200 successful boots in a row wihtout sawg
<sb0>
okay let's check that then
<rjo>
if the amplitude word is above the 1/cordic_gain then the first cordic will produce something that can look like what we are seeing.
<sb0>
and yes, only coredevice/spline.py is using rtio_output_wide()
<rjo>
sb0: i have a few other shots (work around for potential simulation mismatches) in the blue that i'll apply. could you look at rtio_output_wide and sed downstream from it?
<rjo>
i'll also look at the sawg and coredevice code. the two scope shots are precisely the ones in #1039?
<sb0>
yes
<sb0>
(re scope shots)
marmelada_ has quit [Quit: Page closed]
<sb0>
looking into it I'll try, but I have a number of other things in the next days (one kasli system to finish, then a meeting and a conference in china)
<rjo>
i also have a pile of other and more interesting things to do. let's at least take care of the code we wrote.
<rjo>
sb0: i found the redpitaya. what does the connectivity look like? which sayma?
<sb0>
there's only one sayma connected
<sb0>
channels are on the two different dacs (should be sawg0 and sawg4 but I'm unsure)
sb0 has quit [Quit: Leaving]
<hartytp>
sb0: FWIW, none of the work I've done on Sayma was something I've wanted to do, or really have time for (I have an ion trap to get running that is quite behind schedule)
<hartytp>
getting things working for review meetings is important if we want to keep a key source of artiq funding good
<rjo>
right.
<hartytp>
rjo: out of curiosity, should we be using DIFF_TERM on Kasli LVDS inputs? AFIACS, we're only using it for the servo
<rjo>
hartytp: last i checked we were doing it everywhere needed.
<rjo>
hartytp: it can be set either in the xdc or in the I{O,}BUF{T,}DS{_INTERMDISABLE,}
<rjo>
hartytp: but the answer is yes. when an lvds is an input we need termination.
<rjo>
hartytp: if someone has time to double check that that would be great.
<hartytp>
rjo: aah I'd missed that it's done in the phys at the IBUFs
<hartytp>
from a quick spot check of a few phys everything seems to be there
<hartytp>
thanks!
<rjo>
the suspects would be spi2, ttlinout, suservo adc, urukul sync
<rjo>
grabber!
<rjo>
and the clock inputs of the fpga
<hartytp>
_florent_: flashing with sawg now
<hartytp>
without sawg, 239 fpga loads (2 power cycles)
<hartytp>
236 successes
<hartytp>
3 stpl errors
<hartytp>
haven't looked at issues that didn't cause a panic, but can upload the log if that's helpful
<GitHub91>
[smoltcp] squidarth commented on issue #83: hi @whitequark! I'm new here and v. interested in contributing to this library! I want to confirm what needs to happen here before diving in:... https://github.com/m-labs/smoltcp/issues/83#issuecomment-395225183
<GitHub178>
[smoltcp] whitequark commented on issue #83: Hi @squidarth! The challenge here, first and foremost, in figuring out what logic exactly should be followed here. I didn't really have much time to put into this issue myself. Do you think you could look at other TCP/IP stacks and see what sort of logic they use for the neighbor table? https://github.com/m-labs/smoltcp/issues/83#issuecomment-395230094
<GitHub127>
[smoltcp] dlrobertson commented on issue #83: @squidarth You might also check out the [NDISC] RFC. It has some good info about the Neighbor Cache. I can't remember if it says anything about evicting entries from the cache though.... https://github.com/m-labs/smoltcp/issues/83#issuecomment-395240450