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
<shuffle2> sweet, latest kernel+xdevcfg fixed rewriting bitstream after enabling level shifters. finally in a happy place :)
<sb0> rjo, and then it's a different hardware revision and the bug isn't there ...
<GitHub18> [artiq] sbourdeauducq commented on issue #837: > I assume I should post this to the HK address on the M-Labs website?... https://github.com/m-labs/artiq/issues/837#issuecomment-341599506
<whitequark> rjo: what sb0 said.
<GitHub192> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/0d8bad512847def1147c105f9905c074d721ecba
<GitHub192> artiq/master 0d8bad5 Sebastien Bourdeauducq: runtime: fix rtio::log
<GitHub156> [artiq] sbourdeauducq pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/8ebca38323a5c09b098deb938eb1827266be55ae
<GitHub156> artiq/release-3 8ebca38 Sebastien Bourdeauducq: runtime: fix rtio::log
<whitequark> sb0: regarding the ARP issue, I underestimated it.
<bb-m-labs> build #880 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/880
<bb-m-labs> build #1766 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1766 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
_whitelogger has joined #m-labs
_rht has joined #m-labs
rohitksingh_work has joined #m-labs
mumptai_ has joined #m-labs
mumptai has quit [Ping timeout: 248 seconds]
mumptai has joined #m-labs
mumptai_ has quit [Quit: Verlassend]
<sb0> rjo, which dds chip do we have on the urukul for opticlock? I suppose we don't write a driver for the other one?
<sb0> whitequark, how would you make the buildbot use the board lock files?
<rjo> sb0: i'd like to accelerate the progress on that arp issue. it's just being pushed around. and having to wait for shipping now again before any other action is taken does not help. just spend the dozen quid and try to reproduce it.
<sb0> that's not the arp issue
<rjo> yes. the switch issue.
<rjo> or more general: smoltcp issues.
<rjo> keep in mind that this keeps ARTIQ borderline unusable for many.
<rjo> sb0: see the wiki for what opticlock uses.
<sb0> the wiki doesn't give a clear decision for the opticlock dds chip
<rjo> it's the AD9912. could you update the wiki then?
<sb0> done. who will write the driver for the other chips and the various other non-opticlock features of the board?
<rjo> there is only one other chip. and which features do you mean?
<sb0> there are many and it has become very complex. is everything on that board for opticlock or nu-servo?
<rjo> yes
<GitHub27> [artiq] sbourdeauducq opened issue #846: spiflash core on Sayma not working https://github.com/m-labs/artiq/issues/846
<shuffle2> is there a way to have CSRBankArray accumulate all CSRs in submodules below some module? it seems that it only scans the immediate children
<GitHub6> [artiq] sbourdeauducq opened issue #847: Sayma won't boot from flash https://github.com/m-labs/artiq/issues/847
<cr1901_modern> 1. it should recursively scan all children
<cr1901_modern> 2. Why are you using a CSRBankArray directly?
<shuffle2> 2. hrm, because that's the example i saw? :) https://github.com/jordens/redpid/blob/master/gateware/redpid.py#L171
<cr1901_modern> I see... misoc normally protects you from having to use CSRBankArray. I am pretty sure that submodules are recursively scanned for "get_csrs()" though
<cr1901_modern> not just immediate children
<sb0> _florent_, how is sayma coming along? do you get an ethernet carrier?
<sb0> Greg wants me to reset the PHY chip after applying the TX clock, but the reset is only accessible from the MMC as far as I can tell ...
<shuffle2> removing the middle module would fix it. adding a different immediate child with csrs would allow codegen to succeed and silently drop the grandchild csrs
<cr1901_modern> CSRWrapper doesn't have a get_csrs() method. Add one by subclassing w/ AutoCSR
<cr1901_modern> and try that
<cr1901_modern> i.e. class CSRWrapper(Module, AutoCSR):
<shuffle2> cr1901_modern: yea i had tried that actually, doesn't change anything
* cr1901_modern sighs heavily
<cr1901_modern> why can't something be easy
<cr1901_modern> I don't have time right now to look deep into it, sorry
<shuffle2> np
<cr1901_modern> "lambda name, mem: 0" <-- I don't like this. You don't provide a memory range to which your csr devices should respond to
<shuffle2> well, they respond to offset 0 starting from axi space on the zynq. i've made some test design with 3 csrs and it seems to work fine
<cr1901_modern> I would've expected something like csr_map = { "csr_test" : 0 }
<cr1901_modern> But I guess "0" would work
<cr1901_modern> in any case, not sure why it's not finding your children, I am 90% positive get_csrs() recurses into children (if get_csrs() exists as a method, which it doesn't in CSRWrapper)
<shuffle2> the problem is that the submodule must be named at the intermediate level
<shuffle2> using self.submodules += ThingWithCSRs() results in scan finding that it has get_csrs, but it doesn't actually add them for some reason...
<shuffle2> it seems explicitly not supported: _make_gatherer will not descend _submodules, which is the only way it could get to the needed depth
<shuffle2> well not the only way, but the most intuitive :)
<_florent_> sb0: i'm on it, sorry no new for now, i try to get serwb working in all situations, then clocking, then i can give a try to ethernet
<_florent_> news
<_florent_> sb0: for ethernet, IIRC Greg tested it successfully, do you know where we can find the code he tested?
<sb0> _florent_, just emailed it to you
<_florent_> sb0: ok thanks, have you tested it yourself?
<sb0> I just have this messy VHDL file. for anything else please email Greg directly
<sb0> no
<_florent_> ok
<sb0> ah and a few other vhdl sources. second email coming.
<_florent_> sb0: i just asked greg for the full project
<_florent_> sb0: but you can stil send me the others files
<sb0> sent you all I have (3 vhdl files)
<_florent_> sb0: I'd like to speed P&R for the sayma work i'm doing (sayma_amc takes up to 15min), i'd like to remov the second cpu since unused, analyzer, rtio, do you know where i can do that easily?
<_florent_> sb0: haven't yet tried, just asking
<sb0> _florent_, you can build the bare misoc targe
<sb0> t
<sb0> but I think the runtime won't compile without rtio
<sb0> or the second cpu
<sb0> you could spin another firmware though, that uses libboard and runs the clocking code
<_florent_> ok thanks, i'll try to see what i can easily do
<whitequark> _florent_: it should be fairly easy to cfg() off rtio and second CPU
<whitequark> if you want I'll guide you on doing it
<_florent_> whitequark: thanks, then i'm going to remove them from gateware and report you the compile errors i have
<_florent_> whitequark: i get that: https://hastebin.com/izijeyuvih.rb
<GitHub22> [artiq] jordens commented on issue #847: M[2:0] settings? https://github.com/m-labs/artiq/issues/847#issuecomment-341670949
<whitequark> _florent_: ok let me just do that
<_florent_> whitequark: thanks!
<whitequark> _florent_: FileNotFoundError: [Errno 2] No such file or directory: 'artiq_sayma_rtm/sayma_rtm_csr.csv'
<_florent_> ah, you have to compile sayma_rtm before
<whitequark> I just fed /dev/null t here
<whitequark> ... oh
<whitequark> okay I see
<_florent_> that's because we are controlling csr of rtm from amc
<whitequark> can you give me that csv file? I don't have Vivado locally
<whitequark> and it's a pain in the ass to install anyway
<_florent_> yes
<whitequark> thanks
<_florent_> sb0: rtm identifier read from amc: https://hastebin.com/rexehakicu.go
<sb0> _florent_, well that doesn't work here. did you patch the code?
<sb0> _florent_, by the way if you want to try on the boards we have here (3 of them, and sayma 1 and 3 have rtms) your ssh account still works
<sb0> sayma 1 and 2 usually die after ~hours from the 1V8 bug and to fix this all boards can be power cycled with echo > /dev/ttyACM0
<_florent_> sb0: ah, yes i probably changed something in the firmware (i'm working in my branch), let me apply that. (but i think there are still initialization issue from time to time that i have to look at)
<sb0> whitequark, you don't need vivado for the csv
<sb0> use --no-compile-gateware when building artiq and it skips the vivado part
<sb0> you can also use vivado on the lab computer if needed
<GitHub17> [artiq] enjoy-digital pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/0d8bad512847...b3e920b3c8cd
<GitHub17> artiq/master 5bd1e43 Florent Kermarrec: gateware/serwb: cleanup imports, use buffered SyncFIFO in EtherboneRecordSender
<GitHub17> artiq/master b3e920b Florent Kermarrec: firmware/libboard/serwb: fix init
<_florent_> sb0: you should be able do test by just recompiling the runtime
<_florent_> sb0: gateware changes have no fonctionnal impacts
<sb0> okay running that now. thanks
<whitequark> sb0: sayma_rtm doesn't compile with --no-compile-gateware if there's no vivado
<whitequark> not sure why
<sb0> _florent_, maybe the register should not be called "ready" if it reads 0 when the core is ready?
<_florent_> it reads 1 when core is ready
<_florent_> in case it does not work, here are the traces i'm using https://github.com/enjoy-digital/artiq/blob/master/artiq/firmware/libboard/serwb.rs#L10
<_florent_> by the way, here i'm testing by loading rtm then amc, but it should work in both cases
<_florent_> sb0: here https://github.com/m-labs/artiq/commit/b3e920b3c8cd4c9eb4ff134b3019e1bc205193bc for me we are waiting until ready = 1 :)
<whitequark> _florent_: do you still need firmware-with-no-rtio?
<_florent_> whitequark: yes
<whitequark> ok
<whitequark> no kernel CPU either, right? so no ksupport
<_florent_> whitequark: because i need to touch gateware, so that could reduce a lot P&R time
<_florent_> whitequark: yes no kernel CPU would also reduce P&R time and don't need it
<whitequark> ok will do
<_florent_> thanks
<sb0> _florent_, ah you're right, sorry.
<_florent_> can you post you results if you do the test? bbl
<sb0> I remembered it also didn't work when I tried manually from the BIOS, but maybe you fixed things since then
<sb0> firmware loading ...
<_florent_> yes that's a bit long, i increased baudrate to 2000000 on my side...
<whitequark> _florent_: it's faulty on anything over 115200
<whitequark> I tried already
<whitequark> do you know about the "hotswap" feature?
<whitequark> artiq_coreboot hotswap FIRMWARE
<whitequark> this loads a new fw over TCP/IP
<_florent_> whitequark: ethernet is not working yet on sayma_amc...
<whitequark> oh
<whitequark> annoying
<_florent_> and baudrate set to 20000000 works fine here
<sb0> _florent_, which one should I load first to reduce likelihood of init failure?
<sb0> amc or rtm? does it matter?
<_florent_> rtm then amc
<_florent_> at least that's what i'm doing there
<_florent_> whitequark: on witch target was it failing at more than 115200?
<_florent_> going out for lunch, bbl
<whitequark> _florent_: kc705
<whitequark> seems to have flakey UART on whichever side
<whitequark> not sure but I wasted a lot of time trying to get it to load firmware faster
<whitequark> 3M fails almost immediately
<whitequark> 1M doesn't which is even worse
<whitequark> because I still had to revert it
<sb0> there were also all sorts of bugs in that baudrate change code ...
<sb0> _florent_, can't get the bridge to init
<sb0> [ 0.016399s] INFO(board::serwb): waiting for AMC/RTM serwb bridge to be ready...
<sb0> and freezes
<sb0> this is a new problem though, before the result was random
<sb0> _florent_, so I tried on sayma3, and ddr3 fails.
<sb0> Write leveling: 3 24 379* 374* completed
<sb0> Read bitslip: 1 0
<sb0> Read delays: 3:98-269 2:102-273 1:512-520 0:512-520 completed
<sb0> Memtest failed: 532512/532736 words incorrect
<bb-m-labs> build #881 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/881
<bb-m-labs> build #607 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/607 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<bb-m-labs> build #1767 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1767
<sb0> _florent_, nope. refuses to work.
<sb0> I somehow managed to crash the ftdi chip, too
<sb0> sigh
<sb0> bugs, bugs, bugs, bugs and more bugs
rohitksingh_work has quit [Read error: Connection reset by peer]
<whitequark> a vivarium
<whitequark> sb0: HAS_DRTIO is conditional on HAS_RTIO, right?
<_florent_> sb0: ok,for ddr3 failing, it's something similar to what i have (0:512-520 is already wrong since max is 512, need to see if it's an issue in the software or the gateware)
<_florent_> sb0: ok for the serwb test, i continue work on my side and do more testing
<_florent_> whitequark: have you been able to look at disabling rtio/cpu in runtime?
<whitequark> _florent_: finishing it
<whitequark> will be ready in a moment
<_florent_> whitequark: ok great
<_florent_> whitequark; i'm maybe asking too much... :) but is is easy to also disable ethernet in the runtime??... (this would allow me to build from BaseSoC and not MiniSoC)
<_florent_> is it
<_florent_> whitequark: if that's not trivial, don't bother with that, not sure it takes a lot more time to build MiniSoC vs BaseSoC. But it would maybe reduce runtime size a bit since no ethernet/smoltcp support.
<whitequark> _florent_: it's quite trivial
<whitequark> but let me do it piece by piece
<_florent_> whitequark: yes of course
mumptai has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<_florent_> sb0: strange you were not able to get serwb working, here i've not been able to get it failed for today while doing my tests (20/30 inits), we'll figure that out when clocking will be working
<rjo> _florent_: what's your vivado version?
<_florent_> rjo: 2017.2
<_florent_> rjo: and yours?
<rjo> _florent_: same
<_florent_> rjo: ok, possible we don't have the exact same sources, I'll see that later
<rjo> _florent_: could you have a quick look at my response from yesterday re the eth phy layout dw?
<_florent_> rjo: sure, i thought i had answered
<_florent_> rjo: hmm not able to find it, was it a mail or github issue?
<rjo> "between the phy and the mac? i.e. eth_phy_layout()?"
<rjo> "that has 8 all over the place."
<_florent_> yes but i'm trying to find your mail/issue, you have a link if it's an issue or email subject?
<_florent_> rjo: on sayma_rtm, we have spis with different cs polarities (hmc830 active high, hmc7043 active low), would you be ok that i add support for different cs_polarity in SPIMaster
<_florent_> rjo: or maybe better doing that outside for now...
rohitksingh has joined #m-labs
<rjo> _florent_: no mail or issue. i am writing the 1000Base-X PHY (PMA/PCS).
<_florent_> rjo: ah ok it was on irc...
<_florent_> rjo: so I'm using dw=32 when using the wishbone interface
<rjo> _florent_: sure. but keep in mind that the SPIEngine (below the CSR SPI Master) is also used in ARTIQ as an RTIO SPI Master and accesses that stuff differently. but afaict it should be fine and compatible to have cs_polarity undriven in that case.
<_florent_> but dw=8 with the hardware udp/ip stakc
<_florent_> stack
<_florent_> do you need to know more about dw?
<rjo> _florent_: but the MAC (which we use in MiSoC and ARTIQ) does dw=8 (e.g. gmii etc) everywhere, no?
<_florent_> ah ok, and you want to simplify code?
<rjo> _florent_: i want to know whether this will work and has been tested with dw=16
<rjo> i.e. if the MAC can handle a PHY with dw=16
<_florent_> ok i see, let me look at the code
<rjo> ... or whether i have to gearbox it. e.g. mac.last_be looks problematic.
<_florent_> rjo: code seems to be generic, except for delimiters
<_florent_> (delimiters = last_be)
<_florent_> but i don't think i tested with dw > 8
<_florent_> for the phy
<_florent_> with the 1000 Base-X PHY you have 16bits @ 62.5 MHz?
<_florent_> it's not possible to run the mac at 8bits @ 125Mhz and keep 16bits in the phy?
<_florent_> if you want to have a phy with dw=16, i think the only thing you'll have to modify is last_be and use 2 bits instead of one
<rjo> ok. so it's either gearbox or change/upgrade last_be handling.
<_florent_> yes
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.3.0/20170811091919]]
<GitHub190> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/2404a0d8c8a72f78747921aa74180e807aca9704
<GitHub190> artiq/master 2404a0d whitequark: runtime: allow #[cfg(not(has_rtio))] builds.
<bb-m-labs> build #882 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/882 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #1768 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1768 blamelist: whitequark <whitequark@whitequark.org>
<GitHub108> [artiq] whitequark pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/2404a0d8c8a7...4835431ac3db
<GitHub108> artiq/master ad8fcb8 whitequark: runtime: has_rtio -> has_rtio_core....
<GitHub108> artiq/master 4835431 whitequark: runtime: allow #[cfg(not(has_kernel_cpu))] builds.
<_florent_> whitequark: thanks!
<whitequark> _florent_: you must leave mailbox memory mapping in place.
<GitHub118> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/dfb2fe0b80390b045dfc8eb14e133df61015764d
<GitHub118> artiq/master dfb2fe0 whitequark: runtime: allow #[cfg(not(has_ethmac))] builds.
<whitequark> and watch out for AMPSoC.__init__ and such statements
<_florent_> ok
<bb-m-labs> build #883 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/883 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #1769 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1769 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #884 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/884 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #1770 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1770 blamelist: whitequark <whitequark@whitequark.org>
_rht has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Ping timeout: 255 seconds]
<_florent_> sb0: just for info, serwb seems reliable here, haven't been able to get a failure while testing others things today
<_florent_> sb0: i got hmc830 spi working (with a small modification misoc's spi), i'm now testing hmc7043
<_florent_> misoc's spi / to misoc's spi
mumptai has joined #m-labs
<GitHub93> [smoltcp] edef1c commented on issue #3: Yeah, I need to find some spare time and probably go over some more details with you, but I've got a packet parser and stuff going, I don't think there's all *that* much work involved in integrating this — I'm mostly worried about testing it sufficiently exhaustively https://git.io/vFczA
<GitHub196> [smoltcp] dlrobertson commented on issue #3: @edef1c Do you have a fork and branch you're working on?... https://git.io/vFcol
<GitHub137> [smoltcp] dlrobertson commented on issue #3: @edef1c Do you have a fork and branch you're working on?... https://git.io/vFcol
<whitequark> _florent_: were you able to build everything without rtio kernelcpu and ethmac?
<_florent_> whitequark: haven't tested yet...
<_florent_> whitequark: i was expecting to need to rebuild amc for serwb but since it's working... but that will be useful for later
<whitequark> ah ok
<shuffle2> is there a (builtin) way to treat a group of platform pins as a Record? (i'd like to have the pins be the "master" side instead of the slave)
<cr1901_modern> shuffle2: Subsignals
<GitHub181> [artiq] cjbe opened issue #848: Label masters with a name to distinguish dashboards https://github.com/m-labs/artiq/issues/848
<_florent_> whitequark: that's working fine and a lot faster! : runtime ~10x smaller (so 10x faster to load...) and gateware 4x smaller (less than 5 minutes build) by removing ethernet, kernel cpu and rtio
<_florent_> whitequark: great for the things i'm working on
<shuffle2> cr1901_modern: yea, but i'd like to put the direction info into the Subsignal
<shuffle2> inverting the directions in my Record does what i want, it's just counter intuitive
<whitequark> _florent_: superb
<whitequark> _florent_: oh you can also make ksupport.bin empty
<whitequark> just hack the build system locally to do that
<whitequark> there's no good way to do it in the build system anyway
<whitequark> that should shave runtnime size maybe 2x more
<_florent_> whitequark: that's already fine, runtime is now 40KB and load in a few seconds (was > 400KB before)
<whitequark> oh right that's because I replaced most of it with while(true)
<whitequark> and it's built with LTO
<_florent_> whitequark: thanks for you time on that
<whitequark> yw
<GitHub30> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/vFcHJ
<GitHub30> smoltcp/master 198fe23 Philipp Oppermann: Redesign the phy::Device trait to avoid Drop impls.
<GitHub15> [smoltcp] whitequark closed pull request #57: New device trait design (master...new-device-trait) https://git.io/vdPH4
<GitHub30> [smoltcp] whitequark commented on issue #57: Thanks a lot for your work on this! https://git.io/vFcHU
<travis-ci> m-labs/smoltcp#366 (master - 198fe23 : Philipp Oppermann): The build passed.
<GitHub160> [smoltcp] whitequark commented on issue #66: @jackpot51 Can you rebase? https://git.io/vFcQu
<GitHub63> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/vFcQo
<GitHub63> smoltcp/master 32ee91d whitequark: Add CODE_STYLE.md.
<travis-ci> m-labs/smoltcp#367 (master - 32ee91d : whitequark): The build passed.