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
<GitHub190> [smoltcp] dlrobertson commented on pull request #59 723226c: Added tests for the added logic. https://git.io/vdM6J
<GitHub69> [smoltcp] dlrobertson commented on pull request #59 723226c: Added documentation about the added logic and updated documentation about the default value. https://git.io/vdM6U
Gurty has joined #m-labs
<sb0> are 19-inch subrack card guides standard, or do the expensive schroff card guides only work with expensive schroff enclosures?
<GitHub172> [artiq] whitequark commented on issue #834: Here's the test code I wrote so far:... https://github.com/m-labs/artiq/issues/834#issuecomment-336772051
artiq__ has quit [Remote host closed the connection]
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
Ishan_Bansal has quit [Ping timeout: 255 seconds]
mithro has quit [Ping timeout: 255 seconds]
kuldeep has quit [Ping timeout: 269 seconds]
mithro has joined #m-labs
kuldeep has joined #m-labs
<rjo> there are incompatible combinations. why don't you spend hours trying to gobble together crappy cheap chinese parts instead.
<GitHub4> [misoc] enjoy-digital pushed 1 new commit to master: https://git.io/vdMNm
<GitHub4> misoc/master 2412271 Florent Kermarrec: targets/sayma_amc: add missin false paths on ethernet clocks
<bb-m-labs> build #261 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/261
Ishan_Bansal has joined #m-labs
<rjo> _florent_: do you need assistance with artiq/sayma?
<GitHub55> [nu-servo] jordens pushed 1 new commit to master: https://github.com/m-labs/nu-servo/commit/213e57cfdce6b046e058c44fff689377b11ad6bf
<GitHub55> nu-servo/master 213e57c Robert Jordens: kasli
<_florent_> rjo: thanks, that's fine for now, i'm able to build design, build firmware, load it
<_florent_> rjo: for now it seems ddr3 is not working correctly when serwb is integrated (i think sb0 already saw that)
<_florent_> rjo: i found a workaround for that (to be able to continue serwb tests, artiq integration): reduce ddr64 to 32 bits...
<_florent_> rjo: i'll look at the ddr issue later
<rjo> _florent_: ack.
<_florent_> rjo: i'm going to look at serwb and then clocking, i'll ask if i need help, thanks
<_florent_> rjo: ethernet still need to be investigated right?
acathla has quit [Quit: Coyote finally caught me]
rjo- has joined #m-labs
<rjo-> _florent_: yes. I don't know how much sb0 has looked into it.
acathla has joined #m-labs
acathla has quit [Changing host]
acathla has joined #m-labs
rjo- has quit [Quit: AtomicIRC: The nuclear option.]
<GitHub44> [smoltcp] whitequark commented on pull request #59 723226c: Same as above. https://git.io/vdDGm
<GitHub178> [smoltcp] whitequark commented on pull request #59 723226c: TTL value of 0 is clearly user error so you should panic rather than silently ignore. https://git.io/vdDGO
<GitHub147> [smoltcp] whitequark commented on pull request #59 723226c: INNA → IANA https://git.io/vdDGq
<GitHub160> [smoltcp] whitequark commented on pull request #59 723226c: Let's leave this out, `set_payload_len` is special here. https://git.io/vdDGY
<GitHub92> [smoltcp] dlrobertson commented on issue #59: Good catches. Updated. https://git.io/vdDZT
<_florent_> rjo/sb0: i got serwb working with artiq targets (rtm_identifier was read correctly by rust runtime), initialization is sometime failing, i'll investigate that (and also see if vivado constraints are correct).
rohitksingh has joined #m-labs
<whitequark> sb0: ping
<whitequark> I'm observing something very strange
<whitequark> is rtio::get_counter not atomic?
<whitequark> I'm computing counter differences and I get a few results on the order of 0xfc880c5fd8
<whitequark> which, actually, make very little sense even if the counter halves aren't read at the right time, hm
mumptai has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<sb0> whitequark, it should be atomic
<whitequark> sb0: ok, this is very weird then.
<whitequark> gateware miscompilation? something else?
<whitequark> wait
<sb0> rjo, you don't understand how this works. it would be "hours traveling to Shenzhen and scouring markets with a translator". a lot of chinese electronic/mechanical stuff isn't crappy at all, but it is undocumented and they expect face-to-face meetings.
<whitequark> how can it possibly be atomic?
<whitequark> it's a 64-bit value
<whitequark> oh I see
<whitequark> nevermind
<sb0> and in this case I was looking at a Rittal case, not a chinese one, and it also suffers from the same lack of docs.
<sb0> whitequark, what do you mean by atomic?
<sb0> _florent_, there was some intermittent vivado breakage with ddr3. I don't know how frequent is it nor what the impact of serwb exactly is.
<sb0> _florent_, yes Ethernet still needs fixing
<mithro> FYI - We found an issue with tftp booting in the bios today
<mithro> Will send patch upstream soon
<sb0> Rittal is 1/3 the price of Schroff, which is still expensive by chinese standards, but yes I want to avoid the hours of annoyance you mention
<whitequark> sb0: ok I figured out why perf counter data was completely worthless
<whitequark> because the implementation is just broken
<whitequark> it counts events ONLY while you're writing to the PCCR regs
<rjo> sb0: there are a bunch of alternatives for these crates: fisher, proma come to mind
<rjo> the proma guides and the schroff guides are incompatible.
<rjo> whitequark: yes. i never got it to work. see my other report.
<whitequark> rjo: oh.
<whitequark> well ok this is easily fixed.
<whitequark> I should also fix the other problem with it while I'm at it
<whitequark> rjo: do you know how to compute population count in verilog?
<whitequark> actually nevermind, most of the events cannot happen simultaneously with each other
<whitequark> or can they
<rjo> i think they can.
<rjo> and popcount is potentially not cheap, certainly not as cheap as just a single or
<rjo> but yes. popcount is the right approach. if it meets timing it should be ok.
<whitequark> ok
mumptai has quit [Remote host closed the connection]
<GitHub117> [mor1kx] whitequark force-pushed master from 1b51259 to b9e1cd6: https://github.com/m-labs/mor1kx/commits/master
<GitHub117> mor1kx/master 68181e2 Robert Jordens: pcu: fix spr writes
<GitHub117> mor1kx/master e7cee0f Robert Jordens: pcu: fix reset
<GitHub117> mor1kx/master 477a7c5 whitequark: Do not assign spr_access_ack[`OR1K_SPR_PC_BASE] twice....
<bb-m-labs> build #262 of misoc is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/262 blamelist: whitequark <whitequark@whitequark.org>
<GitHub192> [misoc] whitequark pushed 1 new commit to master: https://git.io/vdyCQ
<GitHub192> misoc/master b38b933 whitequark: Update mor1kx.
<whitequark> hm
<GitHub102> [misoc] whitequark force-pushed master from b38b933 to 622b807: https://git.io/LjONPA
<GitHub102> misoc/master 622b807 whitequark: Update mor1kx.
<bb-m-labs> build #263 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/263
<whitequark> sb0: can you install 2017.7 on the buildbot?
<rjo> .3? i don't think we have the license.
<whitequark> .7
<whitequark> hm
<whitequark> ok
<whitequark> I'm seeing something really weird happening with the RTIO counter at least
<whitequark> by which I mean it's not monotonically increasing
<whitequark> seems like a clear gateware bug
<whitequark> erm
<whitequark> vivado bug.
<whitequark> sb0: are you completely sure it's not the *other way around*?
<whitequark> I've instrumented dma_playback
<whitequark> on master, I have these two calls:
<whitequark> let zt = rtio::get_counter();
<whitequark> csr::rtio_dma::time_offset_write(timestamp as u64);
<whitequark> (timestamp - zt) is -4112, yet DMA still succeeds
<whitequark> DMA can't possibly send events into the past, right
<whitequark> sb0: wtf
<whitequark> tests pass now
<whitequark> now that I've rebuilt the bitstream with a slightly newer mor1kx
<whitequark> none of this makes any sense
<whitequark> ok correction: all tests except test_dma_trace
<whitequark> and yep, test_dma_trace seems like a legitimate underflow that wasn't catched by the old bitstream
<whitequark> so it seems like there's a bug in master + a bug in vivado that happened to be tickled until I updated mor1kx
<whitequark> and then there's the weird rtio counter thing
<whitequark> anyway I think I've dealt with it?
<GitHub189> [smoltcp] dlrobertson commented on issue #59: Removed `* IPv4 time-to-live value is fixed at 64.` from the README https://git.io/vdyV7
<GitHub62> [smoltcp] podhrmic opened pull request #60: IGMPv2 (master...igmp) https://git.io/vdyoA
<GitHub187> [smoltcp] podhrmic commented on issue #60: Of course the build fails now because it depends on `std`. https://git.io/vdy6m