<GitHub-m-labs>
[artiq] jordens commented on issue #1068: Yes. But please don't go overboard with the generalization and interdependency of that code. Abstracting the over the register map and feature sets of those chips won't work. https://github.com/m-labs/artiq/pull/1068#issuecomment-396520981
<GitHub-m-labs>
[artiq] hartytp commented on issue #1068: > Yes. But please don't go overboard with the generalization and interdependency of that code. Abstracting the over the register map and feature sets of those chips won't work.... https://github.com/m-labs/artiq/pull/1068#issuecomment-396521966
<GitHub-m-labs>
[artiq] jordens commented on issue #1068: I'm fine with merging this if you either revert the "...done"/"...locked" change or also change the one on the hmc7043 "...done". And please fix the conflict. https://github.com/m-labs/artiq/pull/1068#issuecomment-396553491
<GitHub-m-labs>
[artiq] hartytp commented on issue #1068: @jordens / @sbourdeauducq can you repeat that without the RTM connected? That will tell us if this is related to any RTM-based noise source.... https://github.com/m-labs/artiq/pull/1068#issuecomment-396556532
<hartytp>
looking again at the HMC7043 data sheet while investigating noise on Sayma, it occurs to me that we should not be using the output dividers when f_out = f_in
<hartytp>
(which is how we should be using it in the long run)
<hartytp>
as bypassing the dividers reduces noise and power consumption
<bb-m-labs>
build #2442 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2442 blamelist: hartytp <thomas.harty@physics.ox.ac.uk>, ion <thomas.harty@physics.ox.ac.uk>
<_florent_>
hartytp: i'm fine with your divider change on hmc7043
<rjo>
hartytp: please be a bit more careful with the commit history. don't just commit stuff blindly. those reverse merge commits are unreadable and annoying.
<rjo>
hartytp: maybe it is better if you do PRs so we can talk about them before that lands in master.
hartytp_ has joined #m-labs
<hartytp_>
rjo: yes, apologies, that was bad, I realized after committing
<rjo>
hartytp: up to the "capture" part dozens of times.
<hartytp>
okay, so the expectation is that it probably won't work
<hartytp>
and you want the scope trace
<rjo>
my money is on: 30% the board stuffing/rework (in the sayma-2-hk case the CCLK and DIN resistors), 30% noise, and 40% something else. the scope trace has high likelyhood of helping with all those hypotheses.
<hartytp>
fine
<hartytp>
I should be able to do that tomorrow
<rjo>
from what i can see remotely, the rtm fpga does not see the sync sequence 0xaa996655 (or sth like that) which is at the start of the bitstream.
<rjo>
yes. i want r122, r116 such that m[2:0] == 0b111 (they are on sayma-2-hk) and R176-R180 DNP, R200-R204 0R (at least prog, done, init are correct on sayma-2-hk).
<hartytp>
did greg give you a diagram showing R176-180 and R200-204?
<hartytp>
anyway, on the plus side, it's refreshing to see sawg working really well from an analog perspective (module the dying synth I happened to pick out of the pile)
<hartytp>
oops, "sayma" not "sawg" testing that next :)
<rjo>
ack. looking forward to the noise spectrum there.
<bb-m-labs>
build #2443 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2443 blamelist: Thomas Harty <thomas.harty@physics.ox.ac.uk>, ion <thomas.harty@physics.ox.ac.uk>
<sb0>
rjo, hartytp, need to recheck the population on the board currently in the lab
<sb0>
rjo, do I understand it right, that the BIOS is crashing and the SDRAM test fails after merging Tom's pull request that doesn't touch the BIOS or the SDRAM?
<rjo>
no indication that this is related to that change.
<sb0>
pristine master@a9d97101fc isn't crashing
<rjo>
crashed in 1/10 cases when i tried it. see the issue.
<sb0>
did the sdram scan also look intermittently bad on some reboots?
<rjo>
sb0: sure.
<sb0>
so far the worst scan I get is 00101010101111111111111111111111111111111111111 ...
<sb0>
and no crash yet
<sb0>
that's 11 reboots
<sb0>
jesd sc1 also looks good
<sb0>
by "reboot" I mean reloading the bitstream. did you power-cycle instead?
<rjo>
artiq_flash load
<sb0>
ok, same
<sb0>
er
<sb0>
no
<sb0>
i use artiq_flash start
<sb0>
and I keep the same rtm bitstream loaded
felix[m] has quit [Remote host closed the connection]
marbler has quit [Read error: Connection reset by peer]
jfng has quit [Remote host closed the connection]
<rjo>
i don't think openocd checks whether the bitstream load works. i.e. the rtm could be undefined and the hmc7043 going crazy for those cases.
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #794: HK board with pristine master at a9d97101fc. Board rebooted by artiq_flash start while keeping the RTM bitstream loaded. Here are the phases at 9MHz:... https://github.com/m-labs/artiq/issues/794#issuecomment-396647669
<rjo>
without reloading the rtm gateware this happens 0/40
<GitHub-m-labs>
[artiq] jordens commented on issue #813: I think this won't work because FPGA_CFG_DIN (on RTM) is not connected to IO_L1N_T0_D01_DIN_14 (L17) but to IO_L1P_T0_D00_MOSI_14 (K16). That's close but not close enough.... https://github.com/m-labs/artiq/issues/813#issuecomment-396677246
<GitHub-m-labs>
[artiq] jordens commented on issue #813: I think this won't work because FPGA_CFG_DIN (on RTM) is not connected to IO_L1N_T0_D01_DIN_14 (L17) but to IO_L1P_T0_D00_MOSI_14 (K16). That's close but not close enough.... https://github.com/m-labs/artiq/issues/813#issuecomment-396677246
<GitHub-m-labs>
artiq/master a9a25f2 Robert Jördens: sayma_rtm: drive ref_lo_clk_sel, and set clk muxes early
<GitHub-m-labs>
[artiq] jordens commented on issue #813: I think this won't work because FPGA_CFG_DIN (on RTM) is not connected to IO_L1N_T0_D01_DIN_14 (L17) but to IO_L1P_T0_D00_MOSI_14 (K16). That's close but not close enough.... https://github.com/m-labs/artiq/issues/813#issuecomment-396677246