attie has quit [Remote host closed the connection]
sb0 has joined #m-labs
<sb0>
now the hmc830 has stopped working again
<sb0>
why is sayma always like this?
<sb0>
_florent_, I don't know if that's the source of the problem, but can you fix the serwb timing failure soon?
<sb0>
WTF? with a different *AMC* it locks
<sb0>
well. that could be the serwb failure.
<_florent_>
sb0: i'll look at serwb timing failure. But i don't think that's the issue with HMC830. Maybe we should configure the HMC7043 before the HMC830, to be sure it's not generating any broadband noise while HMC830 is configured?
<_florent_>
sb0: hmm maybe not possible if hmc7043 needs a valid input clock to be configured.
<GitHub-m-labs>
[artiq] hartytp commented on issue #997: @sbourdeauducq is it worth putting a bigger/faster FPGA on the RTM for Sayma v2.0? Obviously, it's best to use the cheapest FPGA we can, but I wonder if a bit more money on FPGAs will save us a lot of development time in the future? https://github.com/m-labs/artiq/issues/997#issuecomment-387988446
hartytp_ has joined #m-labs
<hartytp_>
_florent_ what's your model for how the HMC7043 could affect the 830?
<hartytp_>
my best guess is that the RTM FPGA is producing some glitch at startup which is upsetting the HMC830
<hartytp_>
would be good to get the RTM loading/serwb reliable before we dig too much into the 830 IMHO
<hartytp_>
anyway, I'm still waiting for my boards to arrive from Poland, so can't help atm
<sb0>
there should be no difference if it's loaded from jtag or from slave-serial
marbler has joined #m-labs
marmelada has joined #m-labs
hartytp_ has joined #m-labs
<hartytp_>
sbo: true, shouldn't matter. at one point I'd seen some issues to do with the timings of when the various bitstreams were loaded, but that's probably gone now
hartytp_ has quit [Client Quit]
hartytp_ has joined #m-labs
<hartytp_>
sayma here! Will test once gateware meets timing
marmelada has quit [Quit: Page closed]
hartytp_ has quit [Quit: Page closed]
rohitksingh_work has quit [Read error: Connection reset by peer]
<marmelada>
will artiq_flash (...) load work on rtm?
<whitequark>
yes
<marmelada>
ok, now it works
<marmelada>
hmc830 to lock needs to have 125 MHz reference clock on sma input of rtm, right?
<GitHub-m-labs>
[artiq] jbqubit commented on issue #998: Does it make sense for xxx.reset() to automatically include whatever delays are necessary? AFAICT resets are done at the start of experiment cycles where the simplicity of just-works (without fiddling with delays) is nice. https://github.com/m-labs/artiq/issues/998#issuecomment-388086483
rohitksingh has quit [Quit: Leaving.]
<sb0>
marmelada, 100MHz
<marmelada>
sb0: 10 dBm is enough?
<marmelada>
ok, so hmc830 fails to lock
rohitksingh has joined #m-labs
<marmelada>
strangely it did lock sometimes
<marmelada>
even with 125 MHz clock
<sb0>
marmelada, is your clock clean enough and within the specs of the input chip?
<marmelada>
Greg used the same generator to test with forth
<whitequark>
sb0: in migen.genlib.fifo, what is fwft?
<whitequark>
and do I understand it right that SyncFIFOBuffered only lets you do reads on alternating clock cycles?
<whitequark>
ah, first word fall through
rohitksingh has quit [Quit: Leaving.]
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 240 seconds]
<GitHub42>
[smoltcp] ProgVal opened pull request #207: Add support for IPv6 gateway, and use it to make examples IPv6-capable (master...ipv6-gateway) https://github.com/m-labs/smoltcp/pull/207