sb0 changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs :: Due to spam bots, only registered users can talk. See: https://freenode.net/kb/answer/registration
eyeoh24 has joined #m-labs
eyeoh24 has quit [Remote host closed the connection]
trewas14 has joined #m-labs
trewas14 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Read error: Connection reset by peer]
heinrich599115 has joined #m-labs
heinrich599115 has quit [Remote host closed the connection]
hartytp has quit [*.net *.split]
dallbee29 has joined #m-labs
dallbee29 has quit [Read error: Connection reset by peer]
rjo has quit [Ping timeout: 272 seconds]
<sb0> okay that wasn't a vivado bug after all, it just looked suspiciously similar to the DMA bug which was one
<GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to switching: https://github.com/m-labs/artiq/compare/b86b6dcc0965...53a979e74d8e
<GitHub-m-labs> artiq/switching 251d90c Sebastien Bourdeauducq: drtio: clear read request in satellite only after reply has been fully sent...
<GitHub-m-labs> artiq/switching 53a979e Sebastien Bourdeauducq: rtio: cleanup resets
<sb0> hartytp: it is done
<sb0> hartytp: I have only compile-tested sayma, please use kasli or expect problems
<GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to switching: https://github.com/m-labs/artiq/compare/53a979e74d8e...73f0de7c79a3
<GitHub-m-labs> artiq/switching 1b7f403 Sebastien Bourdeauducq: drtio: remove remote RTIO PHY resets
<GitHub-m-labs> artiq/switching 73f0de7 Sebastien Bourdeauducq: sayma: DRTIO master fixes
rjo has joined #m-labs
rohitksingh_work has joined #m-labs
futarisIRCcloud has joined #m-labs
<cr1901_modern> whitequark: You've stared into the conda abyss long enough, perhaps unwillingly. Have you ever seen an issue like this? http://ix.io/1n5I
<whitequark> cr1901_modern: yes
<whitequark> thesolution is to not use conda
<whitequark> you don't have any reason to do so, anyway, unlike m-labs
<cr1901_modern> I'm not using it willingly :). If it were up to me, I'd find some sort of generic SAT-solver-based package manager for the non-python based stuff, and use pip pointing to a custom package index for the rest.
<cr1901_modern> (and hope I can get the two to play nice when they interact, like with libboost-python)
<cr1901_modern> s/SAT-solver-based//
<cr1901_modern> (Not firing on all cylinders right now)
m4ssi has joined #m-labs
g3ntoo17 has joined #m-labs
g3ntoo17 has quit [Remote host closed the connection]
<GitHub-m-labs> [artiq] whitequark commented on commit fb1dfcf: This doesn't actually work because the cache is never cleared. In case there's ARP spam (like from those security tools at NIST), the core device will just crash. https://github.com/m-labs/artiq/commit/fb1dfcf3729d9bd4ebcfc16da0590a0ebde2ca39#commitcomment-30574272
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
MatCat20 has joined #m-labs
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq commented on commit fb1dfcf: You said it was OK for release-3. Can you fix it? https://github.com/m-labs/artiq/commit/fb1dfcf3729d9bd4ebcfc16da0590a0ebde2ca39#commitcomment-30575050
MatCat20 has quit [K-Lined]
<GitHub-m-labs> [artiq] sbourdeauducq closed issue #790: DRTIO switch support for complex Kasli trees https://github.com/m-labs/artiq/issues/790
<GitHub-m-labs> [artiq] whitequark commented on commit fb1dfcf: I meant that I will port it to release-3. I'm doing it right now. https://github.com/m-labs/artiq/commit/fb1dfcf3729d9bd4ebcfc16da0590a0ebde2ca39#commitcomment-30575108
<GitHub-m-labs> [artiq] whitequark pushed 2 new commits to release-3: https://github.com/m-labs/artiq/compare/fb1dfcf3729d...98e61e4d4d0d
<GitHub-m-labs> artiq/release-3 98e61e4 whitequark: firmware: update smoltcp....
<GitHub-m-labs> artiq/release-3 b91822f whitequark: firmware: migrate to Rust 1.28.0....
<whitequark> sb0: ^ should work now
<bb-m-labs> build #2608 of artiq is complete: Failure [failed lit_test] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2608 blamelist: whitequark <whitequark@whitequark.org>
evilroots has joined #m-labs
<GitHub-m-labs> [artiq] whitequark pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/da01a03a6e4c45b0a552b02dec23e0fdf9393707
<GitHub-m-labs> artiq/release-3 da01a03 whitequark: Fix b91822ff.
evilroots has quit [Remote host closed the connection]
jtdowney13 has joined #m-labs
jtdowney13 has quit [Remote host closed the connection]
<bb-m-labs> build #1867 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1867
<bb-m-labs> build #2609 of artiq is complete: Failure [failed python_unittest_3] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2609 blamelist: whitequark <whitequark@whitequark.org>
<GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/88e72a53f18a212f67ec8170a987e3147d9e7471
<GitHub-m-labs> migen/master 88e72a5 hartytp: Sayma RTM: expose clock mezzanine gpio as a connector (#134)
<bb-m-labs> build #315 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/315
<GitHub-m-labs> [artiq] whitequark pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/dbf4e78087999f7d492fd461be27eab58563611e
<GitHub-m-labs> artiq/release-3 dbf4e78 whitequark: Fix missing import.
<bb-m-labs> build #1868 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1868
<bb-m-labs> build #948 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/948
<bb-m-labs> build #2610 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2610
Renegade33411 has joined #m-labs
Renegade33411 has quit [Remote host closed the connection]
hartytp has joined #m-labs
<hartytp> sb0, _florent_: what causes bad CODEGRPSYNCFLG?
<hartytp> more generally: I want to do my synchronisation tests at 2GHz to check that my scheme really works at that frequency
<hartytp> I've implemented the changes I believe should be required on this branch: https://github.com/hartytp/artiq/tree/fast_sawg
<hartytp> all that is missing is programming the phase shifter during the DAC SYSREF alignment
<hartytp> however, the DAC doesn't boot up (even without SAWG) and just gives bad CODEGRPSYNCFLG errors
<hartytp> any ideas?
kepstin13 has joined #m-labs
attie has quit [Ping timeout: 240 seconds]
kepstin13 has quit [Remote host closed the connection]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<sb0> hartytp: no idea. didn't joe try 2GHz with interpolation?
<sb0> er, 1.2
<sb0> hartytp: are you getting this error with the original artiq code?
<hartytp> flashing to test that atm.
<hartytp> could be an issue with the board greg posted me
<hartytp> ffs
<hartytp> so, that still happens with current master
<hartytp> any ideas what could cause that?
<hartytp> sb0: to check I'm not being silly here: the standalone target needs a 100MHz clock applied to the RTM SMA and nothing else, right?
<sb0> yes
<hartytp> well that's borked then
<hartytp> there is a part of me that is tempted to just cut our losses and spin sayma v2.0 now
<hartytp> my guess is that a lot of these issues are due to each board having different reworks plus having been around the world 10 times and been a bit chewed up
<hartytp> and, if every time my board goes into the WUT vortex a different one comes out, it makes tracking issues quite hard
<sb0> yeah, I don't how many times I told them to be careful about this (and testing...)
rohitksingh has joined #m-labs
<hartytp> sigh...
<rjo> board testing, characterization, history, and each rework need to be tracked and documented end-to-end. it's not magic.
<hartytp> yes
<sb0> hartytp: do you know anything about the current board v2 status? I can't get a word from Joe about it
<hartytp> what about it?
<hartytp> funding?
<hartytp> timeline?
<sb0> yes
Polo692 has joined #m-labs
<hartytp> yes to which? both?
<sb0> hartytp: yes to both
<sb0> rjo: how does one get WUT to do that?
<hartytp> funding, afaict v2.0 hardware is funded
<hartytp> not sure about software (although, I assume the money is there)
<hartytp> timeline: asap afacit
<hartytp> but, I haven't caught up with joe about this for a while
Polo692 has quit [Remote host closed the connection]
<sb0> nothing is funded on software side so far
<hartytp> well, it doesn't really involve me, but that seems the right approach to me: finish the hardware design first then sort out the software contracts once we know what we're dealing with
<hartytp> keeps it less open-ended (although, I assume there will be some design contract for you guys, but as I said I haven't talked to joe about that yet)
Pinchiukas21 has joined #m-labs
Pinchiukas21 has quit [Remote host closed the connection]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
toksnes has joined #m-labs
toksnes has quit [K-Lined]
rohitksingh has quit [Quit: Leaving.]
<rjo> sb0: i would send them a log-sheet with the hardware, specify (in the order and in rework shipments) what they are supposed to do, and how they are supposed to track/document it.
<hartytp> rjo: yes, but even that kind of thing doesn't seem to work
<hartytp> cf booster. Why did I even bother writing up a detailed specification for the firmware?
<hartytp> must have asked 10 times "does your firmware match the specification on the wiki?" each time "yes" until I point out that it clearly doesn't
<hartytp> it's quite frustrating
<rjo> hartytp: yeah. it's annoying. i see a couple possible things: a) apply the usual fudge factor (2-3 in time and money) b) specify the tests, the setup, ask for a sign off and full report on the measurements/milestones/implementation, say that that's required in the contract/order, c) escalate contractually.
<hartytp> yes, I got to the point with Booster of threatening to withhold payment
<hartytp> but, it didn't do much good
<rjo> maybe a % cut for documented contractual failures works different.
<hartytp> yes, but Greg already charges well below market rate
<hartytp> reading between the lines, the reason for that discount is that he's doing it for fun and reserves the right to get distracted on other things that are more fun
<hartytp> at least that's how I read it
<rjo> agreed.
<hartytp> (d) pay the proper rates and use an industrial contractor for any project that's more complicated than an EEM
<hartytp> but, then, it's not that simple because Greg is *great* at working with physicists to understand what they want
<hartytp> and also quite good at getting stuck into issues that involve both hw and software
<hartytp> getting an industrial contractor to do that is also quite tricky
<hartytp> and, we've had issues with a Keysight contract where they also didn't do what was in the contract and moaned about it endlessly
ohsix has quit [Ping timeout: 272 seconds]
ohsix has joined #m-labs
mauz555 has joined #m-labs
<rjo> yep. i have also seen that from smaller but well known physics companies in funding consortia.
apmorton- has joined #m-labs
naeomee_5 has joined #m-labs
tcpdump4 has joined #m-labs
apmorton- has quit [Remote host closed the connection]
hartytp has quit [Quit: Page closed]
naeomee_5 has quit [K-Lined]
tcpdump4 has quit [Remote host closed the connection]
mauz555 has quit [Read error: Connection reset by peer]
m4ssi has quit [Remote host closed the connection]
mumptai has joined #m-labs
jl- has joined #m-labs
jl- has quit [Remote host closed the connection]
Ultrasauce has quit [Read error: Connection reset by peer]
Ultrasauce has joined #m-labs
Jare10 has joined #m-labs
Jare10 has quit [Remote host closed the connection]
ohsix has quit [Ping timeout: 252 seconds]
mauz555 has joined #m-labs
ohsix has joined #m-labs
<_florent_> hartytp: CODEGRPSYNCFLG error probably means that K28.5s are not received correctly by the DAC (first step of the JESD initialization)
mauz555 has quit [Ping timeout: 252 seconds]
Vornucopia has joined #m-labs
Vornucopia has quit [Remote host closed the connection]
bglod1 has joined #m-labs
bglod1 has quit [Remote host closed the connection]
ohsix has quit [Ping timeout: 240 seconds]
ohsix has joined #m-labs
xurious3 has joined #m-labs
xurious3 has quit [Remote host closed the connection]
ohsix has quit [Ping timeout: 252 seconds]
ohsix has joined #m-labs
mauz555 has joined #m-labs
futarisIRCcloud has joined #m-labs