<bb-m-labs>
build #1720 of artiq is complete: Failure [failed anaconda_upload anaconda_upload_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1720 blamelist: whitequark <whitequark@whitequark.org>
<whitequark>
sb0: ^ any idea where that comes from?
<whitequark>
bb-m-labs: force build --props=branch=master+rtio-sed artiq
<bb-m-labs>
build forced [ETA 8h32m20s]
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
whitequark, building artiq-board before artiq?
<sb0>
oh that's master
<sb0>
hmm
<whitequark>
sb0: hmmm, weird
<whitequark>
tests don't pass again
<whitequark>
I might have mixed something up, or buildbot reflashed the board while I was distracted
<whitequark>
sb0: I can reproduce the RTIO bug with master
<whitequark>
but not reliably and I cannot bisect it
<whitequark>
sb0: I figured it out
<whitequark>
I get zeros from rtio_get_counter() only while csr::cri_con::selected == 1
<whitequark>
any idea why?
<sb0>
uhm, what
<whitequark>
csr::cri_con::selected_write(1);
<whitequark>
let selt = rtio::get_counter();
<whitequark>
csr::cri_con::selected_write(0);
<whitequark>
let fint = rtio::get_counter();
<whitequark>
selt == 0, fint != 0
<whitequark>
this doesn't always happen
<whitequark>
it needs some other condition I wasn't able to determine
<sb0>
cri_con::selected is not used by the gateware to determine the value of the counter
<sb0>
look at artiq/gateware/rtio/cri.py
<whitequark>
wtf
<sb0>
CRISwitch
<sb0>
it could be the vivado garbage crapping out; maybe try with ISE?
<whitequark>
might be a backend bug too
<whitequark>
ok
<sb0>
backend?
<sb0>
llvm? migen?
<whitequark>
llvm
<whitequark>
i64's
<sb0>
ah, yes
<whitequark>
should be fine but who knows
<whitequark>
ok, I'll try ISE and see if anything changes
<sb0>
one of the three sayma boards loses its 1V8 supply after it's been running for a while and until it is power cycled ...
<GitHub193>
[smoltcp] phil-opp commented on pull request #57 a45e88c: Me too :). I think it's even necessary here because `transmit`/`receive` take `&'a mut self` to support tokens with a lifetime. Without the higher-ranked lifetime, `transmit` would always borrow for the fixed `'d` lifetime defined in `Interface`, which means that the borrow lasts for the whole device lifetime. So we could only `transmit` once. With higher-ranked lifetimes, arbitrarily
sb0 has quit [Quit: Leaving]
<GitHub93>
[smoltcp] phil-opp commented on pull request #57 a45e88c: The method is defined on `InterfaceInner`, which has no generic `DeviceT` type (since it's device independent). https://git.io/vdHHc
<GitHub142>
[smoltcp] phil-opp commented on pull request #57 a45e88c: Yeah, I thought so. Does it have to be thread safe (i.e. mutex or spinlock) or does a `RefCell` suffice? (I use a RefCell for now, but I'm happy to change it)... https://git.io/vdH5I
<GitHub131>
[smoltcp] phil-opp commented on pull request #57 42b3dc4: The `else` branch happens below. This is the case for when the packet should be dropped. The problem is that `consume` doesn't return a `Result` but a plain `R`, so we need some `R` to return. So we let `f` construct its packet in the junk buffer (which is thrown away afterwards) and return its return value. https://git.io/vdH5u
<GitHub64>
[smoltcp] phil-opp commented on pull request #57 42b3dc4: Because we want to return an `Err` from some middleware `consume` functions. One example is tap_interface:... https://git.io/vdHdF
<GitHub1>
[smoltcp] phil-opp commented on pull request #57 42b3dc4: As an alternative we could change the return type of `TxToken::consume` to `Result<R>` (like for `RxToken::consume`). Then we could return an `Err` without constructing a junk packet. https://git.io/vdHFt
<GitHub6>
[smoltcp] phil-opp commented on pull request #57 42b3dc4: This isn't present anymore in the latest revision. So it seems like githubs "outdated` marker was right once :D. https://git.io/vdHFl
<GitHub83>
[smoltcp] phil-opp commented on pull request #57 4525b9b: Makes sense! https://git.io/vdHFy
sb0 has joined #m-labs
FabM has joined #m-labs
<sb0>
anyone tried the transceivers on microsemi polarfire fpgas?
<sb0>
they're not super expensive...
<sb0>
oh and they don't have those stupid power sequencing requirements that xilinx has, so there is one less excuse to put complicated power supplies on the boards
<sb0>
on-chip oscillator... i like that too
<sb0>
hm. non-volatile but only rated for 1k cycles
Ultrasauce has quit [Read error: Connection reset by peer]