sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined #m-labs
rohitksingh_work has joined #m-labs
hartytp has joined #m-labs
<hartytp>
rjo: going back to our conversation yesterday morning about getting deterministic latency between separate Sayma cards (i.e. syncing Sayma RF to the RTIO clock)
<hartytp>
I think I'm correct in saying that the method I proposed where the SI5324 feeds the HMC7043 RFSYNCIN input will be tricky to get working at max speed
<hartytp>
the HMC7043 is fed from the HMC830 output, which is the DAC clock so up to 2.4GHz (not 1GHz max)
<hartytp>
the sync signal that synchronises that to the RTIO clock is sampled from the DAC clock
<hartytp>
so, it doesn't matter what the DACs themselves do, if we can't meet S/H on the 2.4GHz clock then that scheme will not provide deterministic latency between cards at max clock speed
<hartytp>
with a 416ps clock period and ~300ps S/H that's a tough ask. with 200ps tase resolution on the Si5324, I'm not sure we'll get that to work reliably
<hartytp>
although, I still think it's the best way of getting things going for a quick demo
<hartytp>
for Sayma v2.0 we'd either need to:
<hartytp>
1. not support max DAC clock (no interpolation at max data rate). I don't want to do this
<hartytp>
2. add a better phase shifter between the ref/RTIO clock and the RFSYNC in
<hartytp>
3. switch to HMC7044 so that the 7044 is fed from the RTIO clock and the SYNC input is sampled from that
<hartytp>
2. could work, but still scares me
<hartytp>
3. is definitely the best way in principle -- let HMC take care of all the really hard RF issues -- but needs rework on the board and firmware changes. Not sure if there is sufficient appetite for that, but it could save some serious pain in the long run
<hartytp>
anyway, I'd be interested to hear your thoughts
<hartytp>
rjo: also, can you remind me how the m-labs bb works. Do you have an up to date build of Sayma (not fussed about whether it has Sawg or not) that I can flash to my board to check I'm not doing something daft in my build
hartytp has quit [Ping timeout: 260 seconds]
sb0 has joined #m-labs
hartytp has joined #m-labs
<hartytp>
rjo: I don't think my current serwb issues are due to a fw/gw mismatch
<hartytp>
I've been deleting all outputs before each build and always rebuilding AMC + RTM gw/fw each time. After each build I run "artiq_flash -t sayma --srcbuild ./artiq_sayma" followed by "artiq_flash -t sayma --srcbuild ./artiq_sayma load"
<hartytp>
so I think everything is properly loaded
<hartytp>
I also added a pull-up to the HMC7043 reset pin to prevent noise issues during flashing
<hartytp>
and checked the builds for errors/suspicious warnings
<hartytp>
anyway: _florent_ can you think of anything else I should try to get this working?
<hartytp>
I'd like to run some more tests on my board and play with the HMC830 settings
<hartytp>
the error I'm seeing is 838861 errors on AMC to RTM Link test
<hartytp>
are there any other diagnostics we can add to help pin this down?
<hartytp>
currently rebuilding without the scrambler to recheck that
<rjo>
hartytp: i'll try today to figure out the sysref timing options.
<hartytp>
cool
<rjo>
bb-m-labs: force build --props=package=artiq-board,artiq_target=sayma_amc,artiq_variant=standalone artiq-board
<bb-m-labs>
build forced [ETA 35m54s]
<bb-m-labs>
I'll give a shout when the build finishes
<hartytp>
for the demo for Joe or for v2.0 plans?
<rjo>
hartytp: ^^ should work but might not due to rtm gateware build
<hartytp>
thx
<hartytp>
where do the outputs of that end up?
<rjo>
hartytp: no. to answer your question. i don't know what joe's plans. i only know ken's and jungsang's.
<rjo>
hartytp: conda packages
<hartytp>
aah
<rjo>
my second build yesterday also failed to bring up serwb (initialization failed).
<rjo>
larsc: sysref is sampled by device clock. ergo it needs to meet s/h only w.r.t. to the device clock. but the ad9154 can multiply the device clock using its internal pll to generate a faster dac clock. still, sysref only needs to meet s/h w.r.t. to the slower device clock, right?
<larsc>
good question
<rjo>
larsc: i don't understand the datasheet in that point. rev c, page 39: "The SYSREF± signal is an active high signal sampled by the"
<rjo>
but also page 8 table 5 "SYSREF TO DAC CLOCK TIMING SPECIFICATIONS"
<larsc>
it's not clear to me either
<larsc>
but I believe the uncertainty goes up when using the internal PLL
<rjo>
ah. i guess device clock == DAC CLOCK == DACCLK. may be implied by the wording on page 72 top.
<rjo>
so the timing is always w.r.t. the fastest clock. whether that's at CLK or after the PLL.
<rjo>
The AD9154 DAC sample clock or device clock (DACCLK) can
<rjo>
be sourced directly through CLK± (Pin 2 and Pin 3) or by using
<rjo>
on-chip clock multiplication with the same CLK± differential
<rjo>
input serving as the reference.
<larsc>
the problem with setup and hold specifications if it is to a internal clock is that it is completely useless since you don't have the phase of theat clock signal
<rjo>
the way i see it, it the constraint doesn't need to be that strict: since the interpolation has constant latency (it's a FIR) and happens after all the jesd stuff sysref would only need to meet s/h w.r.t. the "data clock" (i.e. before interpolation).
<rjo>
larsc: ack that.
<larsc>
rjo: that gives you deterministic latency in terms of samples, but you might still get a phase offset at the DAC output
<larsc>
unless the filter counters/dividers are all reset at the same time
<larsc>
rjo: table 7
<larsc>
I'd guess that means there is a non-determinisitc cdc transfer somewhere
hartytp has joined #m-labs
<hartytp>
rjo: hmmm.... the JESD clock is generated by dividing the DAC sample clock
<hartytp>
that divider needs to be reset to give deterministic latency
<rjo>
larsc: re table 7: ack.
<hartytp>
and that reset signal has to be generated by something that's sampled from the DAC clock (the one that goes up to 2.4GHz)
<rjo>
larsc: but interpolation is all deterministic. it's a fir, maybe a cic. i can't see how they manage to make that variable phase.
<hartytp>
rjo: even if the interpolation is deterministic, there is still a problem, isn't there?
<rjo>
hartytp: yes. if the jesd stuff derives from the dac clock then sysref needs to be w.r.t. that as well.
<hartytp>
the data clock on the DAC can start up with one of two possible phases w.r.t. the DAC clock. If sysref is sampled from the data clock then there is still a phase ambiguity
<hartytp>
right
<rjo>
ok. i'm mostly convinced that sysref needs to be w.r.t. dac clock.
<hartytp>
afaict, HMC7044 using WR as the reference and driving SYNC (sampeld from the RTIO clock) from the FPGA seems like by far the easiest way of doing this
<rjo>
the clock recovery and locking subset of WR. yeah
<rjo>
bb-m-labs: force build --props=package=artiq-board,artiq_target=sayma_rtm artiq-board
<bb-m-labs>
build forced [ETA 35m54s]
<bb-m-labs>
I'll give a shout when the build finishes
<hartytp>
I thought AMC to RTM link test was first, or am I misremembering
<sb0>
hartytp, yes, it's failing right after "waiting for AMC/RTM serwb bridge to be ready..."
<hartytp>
okay
<_florent_>
sb0: ok so the solution i see for today is reverting to 125Mhz while i investigate
<_florent_>
sb0: if this is related to the logic, i think the issue is related to the flow control i introduced to use only sys_clk
<rjo>
sb0: i can wait. unlocked now.
<rjo>
sb0: did you try your own build?
<_florent_>
rjo: what have you done to unlock it?
<rjo>
_florent_: referring to the flock
<sb0>
rjo, yes, own build
<rjo>
sb0: ok. then it wasn't my env or build.
marmelada has joined #m-labs
<_florent_>
rjo: sorry?
<sb0>
_florent_, the lock file
<rjo>
the sawg waveform issue looks like what i would expect from too large amplitude (maybe caused by 2's complement or wide rtio) and subsequent cordic divergence. the actual rtio_output_wide is not used by #1039, but the rtio channel itself is wide nonetheless.
<_florent_>
ah ok
<rjo>
_florent_: i terminated my flock to unlock the sayma.
<rjo>
decoupling the issues sounds good. let's get serwb into some working state so that i can look at sawg.
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1044: I don't see any symptoms on my board suggesting JESD204b problems. I do see reproducible nonsense out of SAWG. Please take a look @jordens on Sayma in HK. Some additional examples...... https://github.com/m-labs/artiq/issues/1044#issuecomment-395450506
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
<bb-m-labs>
build #2434 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2434 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<sb0>
what in the hell? now nothing on UART after the 125M serwb commit
<sb0>
ffs
Gurty has joined #m-labs
sb0 has quit [Ping timeout: 255 seconds]
sb0 has joined #m-labs
<sb0>
of course I had underestimated again how treacherous that board is, and didn't keep the previous bitstream
<hartytp>
sb0: i've seen that too
<hartytp>
but the lack of uart just makes no sense to me
<sb0>
yes, i remember
<hartytp>
that's a pretty profound level of messed up
<hartytp>
nb if you don't have a recent RTM bitstream loaded then the HMC7043 spits out noise during flashing
<hartytp>
not sure if that's a prob or not, but seems nasty
<sb0>
does the hmc7043 spit out noise at all after it has received a reset pulse?
<sb0>
maybe it just needs a power-on reset, otherwise it's "undefined behavior"
<hartytp>
it must be held in reset
<hartytp>
once it's outside the reset state it oscillates unless a valid input is applied
<hartytp>
just built with florent's latest comit and it works again for me
<hartytp>
do you want me to send you my build?
<hartytp>
well, serwb hangs often
<hartytp>
but other than that no issues ;)
<sb0>
the datasheet does say that it should be powered up with the reset asserted, and then the reset must be deasserted "after all supplies are stable"
<hartytp>
well, it might depend on how sensitive ones design is to having clock sources oscillating
<hartytp>
most data converters don't care since they're reset after the clocks are stable
<hartytp>
FPGAs are different
<hartytp>
anyway, just reporting what I see
sb0 has quit [Quit: Leaving]
<rjo>
hartytp: noise during flashing is not an issue. we check and reabdack the data flashed. that would fail.
<rjo>
it's not nice but there are no hidden failures due to that.
<hartytp>
ack
<hartytp>
so, what could cause silence on the uart?
<rjo>
i'd go through the usual suspects. check leds, power supplies, clocks, usb hung.
<hartytp>
rjo: here is an observation, I can reliably switch between builds with artiq_flash
<hartytp>
before _florent_'s recent comit reverting serwb all my builds gave silence
<hartytp>
building after that it works
<hartytp>
without power cycling the board, I've flashed both builds repeatedly and once gives nothing on the uart, while one gives an output
<hartytp>
that rules out USB, power etc (I've also checked that all power leds are lit)
<hartytp>
there are no clocks involved in misoc boot
<rjo>
hartytp: why does it rule out power? the power supplies seem to be self-healing.
<hartytp>
so, I can't explain it, but it does seem that -- for whatever reason -- it's the files we're flashing that are the issue
<rjo>
there are a lot of clocks involved in misoc boot
<hartytp>
nothing external
<rjo>
but yes. power supplies are unlikely.
<rjo>
sure. the external oscillator.
<hartytp>
supplies not likely to change in the few min between flashing the different builds
<rjo>
and several internal plls.
<hartytp>
ack
<rjo>
hartytp: maybe try with a different vivado version.
<hartytp>
well, it only meets timing on 2018.1 unless we remove the LOCs
<hartytp>
so I'm not keen to look at 2017.x where it doesn't meet timing
<hartytp>
are those really needed for ethernet, or can they be replaced with proper constraints?
<rjo>
IME LOCs are a major headache. they are unmaintainable, unportable, need to be hand-check each time something changes, are always a suspect (like now). and i have no idea whether they are needed in this case.
<hartytp>
ack
<hartytp>
well, removing them certainly made 2017.4 happier, but I'm not saying that's a component of the present issues
hartytp has quit [Quit: Page closed]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
cjbe_ has quit [Remote host closed the connection]