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
<GitHub198> [smoltcp] phil-opp commented on issue #57: Done https://git.io/vFsOG
<sb0> _florent_, ping
<sb0> whitequark, any progress on arp flood and other networking bugs?
<whitequark> sb0: working on the arp flood issue, should be done in an hour or two i think
<whitequark> what do you mean by the other networking bugs?
<whitequark> I believe none of them are blocked on me
<whitequark> I implemented the error statistics already and they haven't sent us the hardware
<whitequark> I don't really see any other obvious option except maybe asking cjbe to hook up a scope to the switch
<whitequark> you?
<sb0> whitequark, what about the low transfer rate from the windows vm?
<whitequark> oh, sorry, will take a look at that too
<GitHub35> [sinara] marmeladapk pushed 1 new commit to master: https://github.com/m-labs/sinara/commit/c6d0bec8ae5a46798f544ac6e2f815e9f9a4a4c6
<GitHub35> sinara/master c6d0bec Paweł: Kasli - small improvements in routing for PI...
balrog has quit [Ping timeout: 240 seconds]
<shuffle2> grumble, even the example project using axi in vivado just hangs :( must be linux doing something dumb
balrog has joined #m-labs
balrog has quit [Quit: Bye]
balrog has joined #m-labs
<shuffle2> also tried exporting all fclk to userspace and enabling them at 50mhz...still hangs :(
<GitHub89> [smoltcp] pothos commented on pull request #65 700ddd0: Ah, yes. Then by just looking at the two numbers there is no way to distinguish between the case of normal operation with local_seq_no just wrapped before the max statement and the retransmission case. There is also a wrapped case for retransmission where the minimum would have to be taken. So first a way to find out if the value of remote_last_seq was coming from a retransmission is need
rohitksingh_work has joined #m-labs
<GitHub49> [artiq] sbourdeauducq commented on issue #687: Zotino done including monitoring. For Novo there now is a generic driver for shift registers that can be used for the PGIA. Talking to the main ADC chip still needs to be done. https://github.com/m-labs/artiq/issues/687#issuecomment-341312399
<GitHub93> [artiq] sbourdeauducq commented on issue #687: Zotino done including monitoring. For Novo there is now is a generic driver for shift registers that can be used for the PGIA. Talking to the main ADC chip still needs to be done. https://github.com/m-labs/artiq/issues/687#issuecomment-341312399
<GitHub64> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/5a972907f3373a79e589e6b7bdf12fc54b8fccca
<GitHub64> artiq/master 5a97290 Sebastien Bourdeauducq: conda: update misoc
<bb-m-labs> build #877 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/877 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #1763 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1763 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
mumptai_ has joined #m-labs
<sb0> _florent_, does your media converter find the ethernet carrier from sayma? this is borked here for some reason
mumptai has quit [Ping timeout: 246 seconds]
<sb0> ordering new cables and media converters...sigh
<shuffle2> hm, so...axi works totally as expected...when not using linux :(
<shuffle2> added some debug stuff and using xilinx' xmd thing. works fine D:<
<shuffle2> is there a better thing to do than just dumping lots of config mmio space and comparing against linux? ugh
<GitHub141> [smoltcp] pothos commented on issue #65: This is roughly how I would solve it now. Instead of the casts it could use PartialOrd::partial_cmp.... https://git.io/vFsEg
Gurty has quit [Ping timeout: 240 seconds]
rohitksingh_wor1 has joined #m-labs
rohitksingh_wor2 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 248 seconds]
rohitksingh_wor1 has quit [Ping timeout: 248 seconds]
<cr1901_modern> Is there any particular reason why there is no "DifferentialIO" (which would instantiate IOBUFDS) in genlib.io?
<cr1901_modern> rjo: Out of curiosity, why is this code here, and why isn't something similar necessary for MultiReg? https://github.com/m-labs/migen/blob/master/migen/build/xilinx/vivado.py#L175-L181
<cr1901_modern> (git blame says you wrote it)
<cr1901_modern> My guess is that AsyncResetSynchronizer is less common than MultiReg, so one can afford a tight constraint like that
<rjo> cr1901_modern: they are both common.
<rjo> cr1901_modern: may very well also benefit from that constraint. do you want to educate yourself on that topic and crosscheck the available info with what we do in migen?
<rjo> cr1901_modern: http://www.colmryan.org/avrums-clock-domain-crossing-widsom.html is a good start. probably has links to everything you'll ever need to know.
<cr1901_modern> rjo: Sure... let me finish my current patch for migen and I'll spend some time reading
<shuffle2> finally! https://www.xilinx.com/support/answers/58615.html axi from linux works :D (i had seen this before, but in the context i saw it, the people said it had already been fixed in xdevcfg driver...)
<_florent_> sb0: haven't really try ethernet with the media converter, i'll try while working on amc/rtm
<shuffle2> lol...now re-writing the bitstream is broken, though. even if i undo those level shifter changes.
<shuffle2> also, vivado axi sample works, while simple csr test w/migen does not :(
<shuffle2> (reads return 0, writes cause bus error)
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
<rjo> _florent_, sb0: that `dw` parameter in the liteeth phy/mac interface does not work for any dw > 8, right? the eop.eq(sink.last_be) won't work correctly AFAICT.
<shuffle2> ok actually read and writes do work on migen CSRs. it's just that each 32bit arm access only maps to 1 axi slave byte. bus error happens on writes if top 24bits are nonzero
<shuffle2> which is kind of expected i guess?
<whitequark> I think so yes
<cr1901_modern> shuffle2: "it's just that each 32bit arm access only maps to 1 axi slave byte" That is expected- well Idk if the bus error part is. But it's how the CSR bus is designed.
<cr1901_modern> A more "dense" decoding scheme is more annoying to impl and you have 256MB of addr space for CSR
<larsc> on altera the axi bridge only has 2M
<shuffle2> oh hah. the bus error was just because __attribute__((packed)) was causing gcc to emit weird non-32bit accesses (even though the struct members were word-aligned and marked volatile...)
<whitequark> this is a common issue with packed and bitfields
<shuffle2> sure, no bitfields tho, just u32s
<larsc> does the compiler assume that packed is not aligned?
<shuffle2> yea seems so (adding aligned(4) on the struct fixes it)
rohitksingh_wor2 has quit [Read error: Connection reset by peer]
npisenti has joined #m-labs
npisenti_ has joined #m-labs
<npisenti_> I had a quick question about the FSM module
<npisenti_> for example: https://pastebin.com/iM2QL4Zi
<npisenti_> In the generated verilog code, the always @(*) block begins with assigning a <= 1'd0
<npisenti_> so unless I explicitly have a `self.a.eq(...)` for each state in the FSM, i'll get that default assignment
<npisenti_> maybe i'm missing something (or that is just good coding practice anyways), but i naively assumed that `reg a` would hold it's value unless getting another explicit assignment
<npisenti_> (feels a bit silly to include `self.a.eq(self.a)` in the other states
<rjo> always @(*) blocks are effectively combinatorial. the only register you can affect with a FSM directly (within act()) is the FSM state. for other things use .ingoing() or {after,before}_{leaving,entering}()
<rjo> *ongoing()
<rjo> (hi npisenti_)
npisenti_ has quit [Ping timeout: 260 seconds]
mumptai_ has quit [Quit: Verlassend]
<npisenti> i see... alternatively to latch a value into reg a, I could use NextValue? or is taht really intended for, eg, running a counter within a particular FSM state?
<rjo> yes. that's correct. although i suspect NextValue() may change or move or disappear in the future.
<sb0> well it could be generalized to all comb blocks. or suppress the notion of sync/comb block and use nextvalue (or equivalent) for registers.
npisenti_ has joined #m-labs
npisenti_ has quit [Ping timeout: 260 seconds]
rohitksingh has joined #m-labs
<GitHub140> [artiq] kesht123 opened issue #845: Dashboard core device connection occasionaly fails https://github.com/m-labs/artiq/issues/845
Ultrasauce has quit [Read error: Connection reset by peer]
<sb0> whitequark, is the "done in an hour or two" arp problem fixed?
<_florent_> rjo: when using wishbone interface, we use dw=32
<_florent_> rjo: i use dw=8 with the hardware udp/ip stack
<rjo> between the phy and the mac? i.e. eth_phy_layout()?
<rjo> that has 8 all over the place.
<GitHub124> [artiq] hartytp commented on issue #687: Thanks! https://github.com/m-labs/artiq/issues/687#issuecomment-341481191
<sb0> whitequark, tests didn't catch the rtio_log breakage because they don't cover rtio_log.
<sb0> or rather, they don't cover its decoding
<sb0> hm
<sb0> they cover some
npisenti has quit [Quit: Page closed]
<sb0> whitequark, why did you add \n's in the rtio_log?
<GitHub167> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/4387b0be1e6f36920d680c4133fefae78de22734
<GitHub167> artiq/master 4387b0b Sebastien Bourdeauducq: clean up rtio_log
<GitHub130> [artiq] jordens commented on issue #788: Waiting for... https://github.com/m-labs/artiq/issues/788#issuecomment-341490593
<bb-m-labs> build #878 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/878 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #1764 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1764 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<sb0> bb-m-labs, force build --branch=release-3 artiq
<bb-m-labs> build forced [ETA 36m58s]
<bb-m-labs> I'll give a shout when the build finishes
<GitHub8> [artiq] sbourdeauducq pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/0c47f8363497adcd343a70e5b63d4988e8c66f6a
<GitHub8> artiq/release-3 0c47f83 Sebastien Bourdeauducq: clean up rtio_log
<bb-m-labs> build #879 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/879
_rht has joined #m-labs
<bb-m-labs> build #1765 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1765
rohitksingh has quit [Quit: Leaving.]
<shuffle2> haha...xilinx kernel tree doesnt even compile
<shuffle2> anyone else built xilinx kernel tree? using latest master or something else?
<shuffle2> meh, just bad defconfig
Ultrasauce has joined #m-labs
<whitequark> sb0: \n is a message delimiter in rtio_log
<whitequark> iirc
<whitequark> let me look over it again
<whitequark> ah no, not quite
<whitequark> the format is PREFIX\x1EARG ARG ARG\n\x1D
<whitequark> the trailing \n is only really added because we do that for print() as well
<whitequark> core_log() that is
<whitequark> shall I remove it?
<whitequark> the ARP commits will be ready in a bit
<GitHub132> [artiq] cjbe commented on issue #837: @whitequark I have tested this again using the current gateware:... https://github.com/m-labs/artiq/issues/837#issuecomment-341551705
<GitHub96> [artiq] whitequark commented on issue #837: @cjbe Could you also send your DGS-108, just for completeness sake, and on the off chance there is a different bug with it? https://github.com/m-labs/artiq/issues/837#issuecomment-341552946
<GitHub116> [artiq] cjbe commented on issue #837: @whitequark will do. https://github.com/m-labs/artiq/issues/837#issuecomment-341553467
<rjo> whitequark: buy that switch. sending it is not worth it afaict.
_rht has quit [Quit: Connection closed for inactivity]
mumptai has joined #m-labs