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
<GitHub-m-labs> [artiq] klickverbot opened pull request #1191: firmware: Fix dma_record_output_wide (master...dma-wide) https://github.com/m-labs/artiq/pull/1191
mauz555 has quit [Read error: Connection reset by peer]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 252 seconds]
<sb0> is anyone using misoc CSRStorage.atomic_write or can I change the semantics?
<sb0> of course, llvm has to use the opposite write order as the misoc csr functions. 50% chance and murphy's law does the rest...
<davidc__> I think its used in a project I've worked on, but it wouldn't be a big deal to fix it (code is in asm). I'm sure there's a compiler out there that does the opposite to LLVM, so there's probably no good answer :)
<sb0> whitequark: does llvm on or1k require that 64-bit locations be aligned to 64-bit boundaries?
<whitequark> sb0: nope
<whitequark> or1k abi does not require any 64 bit alignment anywhere iirc
<sb0> davidc__: right, so i'll just keep the modification contained in this part of artiq
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 260 seconds]
<GitHub11> [smoltcp] whitequark commented on issue #256: Great to hear, and thanks for your work and patience! https://github.com/m-labs/smoltcp/issues/256#issuecomment-436868005
<davidc__> sb0: I wonder if there's a way to make the atomic-end a property of the bus/master.
<GitHub-m-labs> [migen] whitequark pushed 2 new commits to master: https://github.com/m-labs/migen/compare/966781bc6eb4...7bdc4ed2186b
<GitHub-m-labs> migen/master 7bdc4ed whitequark: build/lattice/diamond: add Linux support....
<GitHub-m-labs> migen/master 3a84a8b whitequark: build/lattice/diamond: only run Jedecgen for MachXO....
<GitHub-m-labs> [migen] whitequark pushed 2 new commits to master: https://github.com/m-labs/migen/compare/7bdc4ed2186b...c51a0641f767
<GitHub-m-labs> migen/master c51a064 whitequark: build/platforms/versaecp55g: allow programming without ispCLOCK in chain.
<GitHub-m-labs> migen/master 34eeb3b whitequark: build/platforms/versaecp55g: import from litex.
<bb-m-labs> build #326 of migen is complete: Exception [exception deploy_doc] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/326 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #325 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/325
<sb0> whitequark: are you sure llvm works the way you think for 64-bit stores?
<sb0> I have this:
<sb0> this code works as expected
<sb0> but if I use the two commented out lines instead, there are strange bugs
<sb0> whitequark: and do you confirm that llvm stores the lower word first and then the higher one? it's not me misreading the asm code?
<whitequark> let me look up the codegen for that
<whitequark> it's in the legalization code
<sb0> btw this now-pinning doesn't seem to have any impact on performance, at least not for test_pulse_rate
<whitequark> sb0: ok, I looked it up in the type legalizer, and no, LLVM does not in fact impose any specific ordering for the two stores. sorry for misinformation earlier.
<whitequark> you will need to split it manually.
<sb0> whitequark: sounds rather complicated to do without performance issues. how hard would it be to enforce ordering in llvm?
<whitequark> sb0: this is a patch in the very core of llvm's target-independent backend
<whitequark> it will never be upstreamed
<whitequark> we can add a hack in the or1k backend, which, if i was the or1k upstream, i would have also never accepted
<whitequark> what are the performance issues here exactly?
<whitequark> if you split a 64-bit store into two 32-bit stores, you do exactly the same thing as the legalizer
<whitequark> just slightly earlier in the pipeline
<whitequark> like, you do store, trunc, another store, this is precisely what the legalizer generates in the DAG
<sb0> right now I'm doing things like telling llvm to do "now = now + 1", with "now" being pinned to the CSRs
<whitequark> you'll get identical DAG *except* it will have correct ordering
<whitequark> what is "pinned to CSRs"?
<sb0> api!(now = csr::rtio::NOW_HI_ADDR as *const _),
<whitequark> that carries an explicit load and store
<whitequark> either in rust or in the compiler
<whitequark> each access
<whitequark> so you aren't actually losing anything if you define a #[inline(always)] helper function
<whitequark> if you make them volatile then yes, it would inhibit some optimizations
<whitequark> you want to make it atomic, gimme a sec
<whitequark> ok, so what you want is to use atomic loads and stores with the "monotonic" ordering
<sb0> I want to do atomicity using the write ordering, to avoid losing performance
<whitequark> llvm optimizes atomic loads and stores.
<whitequark> (it is a common misconception that compilers are not allowed to optimize them; that only applies to volatile)
<sb0> the atomicity solves the problem of the kernel being interrupted in the middle of a "now" store, and leaving a borked value for the next kernel
<whitequark> if you use the monotonic ordering, you should see the exact same machine code generated, but with the correct ordering
<sb0> okay, how do I use that?
<whitequark> doing this in LLVM for regular loads/stores is an awful idea in any case
<whitequark> ok, sec
<whitequark> two of them
<whitequark> ok, sorry, not monotonic, this should be Release
<whitequark> so you do lo.store(lo_val, Ordering::Release); hi.store(hi_val, Ordering::Release);
<sb0> whitequark: the biggest user of "now" is the compiler. rust only *reads* it when raising exceptions.
<whitequark> same thing applies, let me look at i
<whitequark> store atomic release i32 %lo, i32* %loptr, align 4
<whitequark> %lo = trunc i64 %val to i32
<whitequark> %hi1 = ashr i64 %val, 32
<whitequark> %hi = trunc i64 %hi1 to i32
<whitequark> store atomic release i32 %hi, i32* %hiptr, align 4
<whitequark> (swap the ifrst two)
<whitequark> is what the compiler should generate
<whitequark> oh
<whitequark> llvmlite doesn't have atomic stores.
<whitequark> how annoying.
<whitequark> ok give me a moment
<GitHub22> [llvmlite] whitequark created atomics (+140 new commits): https://github.com/m-labs/llvmlite/compare/9748b7224295^...d8c6ced867c4
<GitHub22> llvmlite/atomics a924507 stuartarchibald: Merge pull request #344 from sklam/misc/changelog...
<GitHub22> llvmlite/atomics 42cd083 Nehal J Wani: Get rid of separate prefix for bootstrap...
<GitHub22> llvmlite/atomics 9748b72 Siu Kwan Lam: Update changelog
<GitHub43> [llvmlite] whitequark pushed 1 new commit to artiq-6.0: https://github.com/m-labs/llvmlite/commit/1d167be4eec5d6c32498952be8b3ac17dd30df8d
<GitHub43> llvmlite/artiq-6.0 1d167be whitequark: Add support for atomic loads/stores.
<whitequark> sb0: should work now
<sb0> self.llbuilder.store_atomic(xxxx, self.llbuiltin("now"), "release", 4)?
<sb0> ah, seq_cst
<sb0> well this assert is *before* linking so this makes no sense
<sb0> ah
<sb0> it's happier with align=8, but then won't it break when the csr is actually unaligned?
<sb0> it's generating some sort of function call now, so this definitely won't help with performance
<sb0> bah, i guess i can patch the compiler to use explicit 32-bit accesses.
<sb0> "monotonic" also generates a function call
<sb0> ah but tbaa will also get in the way...
<whitequark> sb0: sec
<whitequark> sb0: that's bizarre, can you give me the elf file and llvm ir
<whitequark> er, no
<whitequark> that won't work
<whitequark> you need to split the store into two manually
<whitequark> it generates a function call because or1k has no 64-bit atomic stores
<whitequark> (and it doesn't know how to do them with ll/sc, which would be a wrong thing anyway)
<whitequark> the function call would be a syscall that tells the kernel to do it atomically
<whitequark> you need to split them AND to use atomics because it's legal for the compiler to reload two stores to two addresses it knows are different
<whitequark> as an optimization
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 252 seconds]
<sb0> how do convert between i64 and 2xi32 efficiently? will it optimize shift/trunc operations?
<whitequark> yes
<whitequark> if not, it's a bug that should be trivially fixable
<whitequark> but it should
<whitequark> or the code would be just horrible
<sb0> btw why would the compiler reload non-atomic stores?
<whitequark> reorder?
<sb0> hm
<sb0> if it can reorder writes arbitrarily, we'd have problems with mmio
<whitequark> no
<whitequark> those writes are volatile
<whitequark> but volatile writes cannot be ever optimized
<whitequark> i'm trying to give you atomics here because atomics *can* be optimized
<whitequark> e.g. it should be able to remove dead stores
<whitequark> i'm not sure that it will do everything we want, but if you make it volatile, it will *definitely* kill performance
<GitHub-m-labs> [artiq] dhslichter commented on issue #1007: I agree with @jordens above. For now, we use the `_mu` methods as a workaround so this particular bug doesn't seem to be a major issue. I am much more concerned about *compilation* slowness than this issue. https://github.com/m-labs/artiq/issues/1007#issuecomment-436901529
m4ssi has joined #m-labs
<sb0> whitequark: not sure that it will do everything we want <<< what kind of issue will there be?
<whitequark> sb0: it might e.g. coalesce loads/stores worse
<whitequark> i will need to look at specific examples
<whitequark> it will not necessarily happen; i have never tried this specific thing before
<whitequark> this is just in realm of possibilities and needs to be checked
<sb0> whitequark: so, lower performance than it could be, but no bugs?
<whitequark> i believe so, yes
<GitHub-m-labs> [migen] whitequark pushed 2 new commits to master: https://github.com/m-labs/migen/compare/c51a0641f767...c79d98882088
<GitHub-m-labs> migen/master c79d988 whitequark: build/platforms/versaecp55g: add X3 external connector.
<GitHub-m-labs> migen/master d60cea0 whitequark: build/platforms/versaecp55g: add external clock input.
ptb_yb3 has joined #m-labs
<bb-m-labs> build #327 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/327
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
<cr1901_modern> sb0: What's your opinion on the icestorm backend if you've ever taken a look? Re: https://github.com/m-labs/migen/pull/149#issuecomment-433579421
<cr1901_modern> I overhauled that with rjo.
<cr1901_modern> It seems to be the direction he wanted to take the backends.
<sb0> cr1901_modern: what icestorm backend?
<cr1901_modern> >IMO the migen build system needs an overhaul.
<sb0> okay; is there something special about the icestorm backend?
<GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to new: https://github.com/m-labs/artiq/compare/aadf5112b7e9...f74dda639f0d
<GitHub-m-labs> artiq/new f74dda6 Sebastien Bourdeauducq: drtio: 8-bit address
<GitHub-m-labs> artiq/new 8caea0e Sebastien Bourdeauducq: gateware,runtime: optimize RTIO kernel interface further...
<cr1901_modern> sb0: Well, you can override any and all parts of the build scripts in a more flexible manner than Vivado.
<cr1901_modern> or ISE
<cr1901_modern> Basically I'm asking: What did you have in mind for a build system overhaul? B/c I implemented changes in icestorm backend w/ the understanding (at least in rjo's eyes) that this is how the backends should all evolve
<whitequark> cr1901_modern: you mean the templates?
<whitequark> i don't think that's how they should be
<whitequark> if i was redesigning them, i'd make each "step" a python function
<whitequark> nextpnr and arachne would subclass the basic icestorm backend
<whitequark> then there would be an overarching function that collects all the "steps"
<whitequark> this actually allows you to override things in a sane way and also lets the language help you, e.g. via @abstractmethod
<whitequark> this is just more stringly typed nonsense...
<whitequark> i mean, it *is* better
<whitequark> it's just not nearly better enough for an overhaul
<whitequark> anynway, you can see some traces of that in my changes
<whitequark> e.g. look at what i did to _build_script and _run_script
<whitequark> there's no magic in _run_script anymore, you can just make a build tree and later run it with `bash` elsewhere, even on a different machine (subject ot some constraints)
<whitequark> actually, what i would like to see in a migen build system overhaul is remoting.
<cr1901_modern> I would prefer to see makefiles or ninja scripts generated instead of bash/cmd scripts
<whitequark> right now it has some silly dependencies on the `build` machine, like all the `if sys.platform` statements
<whitequark> so you can't e.g. run migen on windows but remote to a linux machine with vivado
<whitequark> (makefiles) what's the point?
<whitequark> first, this adds a dependency (make or ninja respectively)
<whitequark> second, toolchains do not maintain dependency information
<whitequark> and in case of verilog, you will have to extract all the preprocessor statements to construct the complete tree
<whitequark> this can be done with verilator (iirc), which is *yet another* dependency
<cr1901_modern> whitequark: Tbh, I don't remember the reason I think this. I just remember thinking it at some point. So just forget that I said it.
<whitequark> and in the end you always resynth and replace the entire thing on any change anyway
<cr1901_modern> anyways remote would be nice
<whitequark> i had a branch with remoting, actually
<whitequark> but it did not work well at all and i gave up
<whitequark> it was long ago anyhow
<cr1901_modern> Anyways I'd like parity of all backends interfaces to the extent that's reasonable.
<whitequark> yes, _run_script and _build_script should be factored out
<whitequark> think you can do that?
<whitequark> that would be great
<cr1901_modern> right now creating the build script for Vivado is different from icestorm is different from ISE is different from trellis
<whitequark> even if it's just for two backedns
<cr1901_modern> sure, lemme finish eating and I'll do that
<GitHub-m-labs> [artiq] klickverbot closed pull request #1191: firmware: Fix dma_record_output_wide (master...dma-wide) https://github.com/m-labs/artiq/pull/1191
<GitHub-m-labs> [migen] whitequark pushed 1 new commit to master: https://github.com/m-labs/migen/commit/37deff134fac50344cf2c091799fab6891c23126
<GitHub-m-labs> migen/master 37deff1 whitequark: build/platforms/versaecp55g: fix IOStandard for ext_clk.
<bb-m-labs> build #328 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/328
<cr1901_modern> whitequark: I can't focus on this right now, but re: adding Linux support to diamond, please make sure the Windows part doesn't contradict this: http://ix.io/1rj5
<cr1901_modern> I had intended to add Linux support at some point, and this was supposed to be a large comment indicating how screwed up the docs are
<whitequark> >Set $bindir env variable, run diamond_env, and then
<whitequark> # invoke pnmainc.
<whitequark> that's what I am going
<whitequark> doing
<whitequark> and on windows i don't source it
<cr1901_modern> 2. On Windows, add Diamond binary directory to the path, and run pnmainc.
<cr1901_modern> Doesn't look like you do, I'll work on that if you don't get to it in a bit
<cr1901_modern> I can test on Windoze anyway
<cr1901_modern> I may even add that comment block b/c I don't want to have gone through that frustration for nothing
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
<cr1901_modern> whitequark: I want to push trellis now; I think refactoring _build_script/_run_script should be its own PR
<whitequark> sure
<bb-m-labs> build #1995 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1995
<cr1901_modern> https://github.com/m-labs/migen/pull/156 Fixed (Barring any last minute issues)
<bb-m-labs> build #1996 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1996
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
<GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/0c5d42c8f65b7dc9e2ab472f287a7c3791c0b19d
<GitHub-m-labs> migen/master 0c5d42c William D. Jones: Add Project Trellis Backend (#156)
mauz555 has quit [Ping timeout: 252 seconds]
<bb-m-labs> build #329 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/329
mauz555 has joined #m-labs
mauz555 has quit [Read error: Connection reset by peer]
<cr1901_modern> whitequark: Also I want to massage the diamond backend while I'm at it. It should be possible to refactor it in such a way that I can also hoist its _build_script out into build/tools.py >>
<cr1901_modern> If you want to try your proposed build overhaul, perhaps now would be a decent time (on the FOSS plus Diamond backend)?
<bb-m-labs> build #2674 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2674
<whitequark> you can proceed refactoring it, this doesn't lock each other
<cr1901_modern> Ahhh.
<sb0> bb-m-labs: force build --branch=new artiq
<bb-m-labs> build forced [ETA 1h07m07s]
<bb-m-labs> I'll give a shout when the build finishes
<GitHub-m-labs> [artiq] sbourdeauducq pushed 6 new commits to new: https://github.com/m-labs/artiq/compare/f74dda639f0d...a0cc7311ad7d
<GitHub-m-labs> artiq/new d185465 Sebastien Bourdeauducq: grabber: use new rtio_output() API
<GitHub-m-labs> artiq/new 2549e62 Sebastien Bourdeauducq: ad9914: use new rtio_output() API
<GitHub-m-labs> artiq/new e8d58b3 Sebastien Bourdeauducq: spi2: use new rtio_output() API
<sb0> bb-m-labs: stop build artiq ad9910
<bb-m-labs> build 2675 interrupted
<bb-m-labs> build #2675 of artiq is complete: Exception [exception interrupted] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2675
<sb0> bb-m-labs: force build --branch=new artiq
<bb-m-labs> build forced [ETA 1h07m07s]
<bb-m-labs> I'll give a shout when the build finishes
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to new: https://github.com/m-labs/artiq/commit/c990b5e4f18ee6bc433e09ddecec41059f60215d
<GitHub-m-labs> artiq/new c990b5e Sebastien Bourdeauducq: Merge remote-tracking branch 'origin/master' into new
<cr1901_modern> whitequark: btw, did you happen to install Diamond into /opt/Diamond? Current convention is "if toolchain_path is None, set to installer defaults" for proprietary toolchains. On Diamond, this is /usr/local/Diamond
<bb-m-labs> build #2676 of artiq is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2676
<whitequark> nope, /usr/local/diamond
<cr1901_modern> good, I can change that w/o regrets then
vup has quit [Quit: The Lounge - https://thelounge.github.io]
vup has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 252 seconds]
cr1901_modern has quit [*.net *.split]
d_n|a has quit [*.net *.split]
iwxzr has quit [*.net *.split]
d_n|a has joined #m-labs
cr1901_modern has joined #m-labs
iwxzr has joined #m-labs
<cr1901_modern> whitequark: Wow, this one change makes diamond so much better to use on Windoze (any complaints before I continue? Perhaps I should open the issue as WIP...): https://github.com/cr1901/migen/commit/71a1d6674ee7bb0d789908263b040ed509d1db3d
<cr1901_modern> Idk if I'm gonna be able to hoist out _build_script though... :(
mauz555 has joined #m-labs
<whitequark> this shouldn't be necessary...
<whitequark> os.path.join uses \\ on windows
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
<cr1901_modern> whitequark: I am uncertain why, but it's producing forward slash here
<cr1901_modern> Very much makes perfect sense and definitely not surprising
<cr1901_modern> whitequark: It depends on which shell (bash or cmd.exe) I'm running when mingw python is invoked whether forward or backslash is used. But in the context of cmd.exe I exclusively need backslash.
<cr1901_modern> since we use the native command interpreter when running the script
<whitequark> mh, ok
<cr1901_modern> specifically the rules seem to be (for mingw python): If interactive REPL and cmd.exe running, os.path.sep == "\\", else "/". Yea, makes sense. /s But whatever it's Windoze fault for not pushing "/" in the DOS 2.x days lol
<cr1901_modern> (fwiw, I think Windoze is actually pretty good w/ paths nowadays; all APIs don't care which slash you use. Just cmd.exe internals insist on backwards compat)
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 252 seconds]
mauz555 has joined #m-labs
<rjo> bb-m-labs: force build --props=package=artiq-board,artiq_target=kasli,artiq_variant=opticlock artiq-board
<bb-m-labs> build forced [ETA 17m03s]
<bb-m-labs> I'll give a shout when the build finishes
<bb-m-labs> build #1997 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1997
mauz555_ has joined #m-labs
mauz555_ has quit [Read error: Connection reset by peer]
mauz555 has quit [Ping timeout: 252 seconds]
m4ssi has quit [Remote host closed the connection]
<GitHub-m-labs> [artiq] hartytp commented on issue #790: - [x] timing is deterministic between SERDES and simple TTLs both on the master... https://github.com/m-labs/artiq/issues/790#issuecomment-436677050
<GitHub-m-labs> [artiq] hartytp commented on issue #790: Timing of SERDES/simple TTLs is fully deterministic across multiple power cycles. Latency is in line with expectations:... https://github.com/m-labs/artiq/issues/790#issuecomment-437096622
<GitHub-m-labs> [artiq] hartytp commented on issue #790: Timing of SERDES/simple TTLs is fully deterministic across multiple power cycles. Latency is in line with expectations:... https://github.com/m-labs/artiq/issues/790#issuecomment-437096622
<GitHub-m-labs> [artiq] hartytp commented on issue #790: NB those numbers include some non-negligible fibre delays. https://github.com/m-labs/artiq/issues/790#issuecomment-437107498
mumptai has joined #m-labs
kristianpaul has quit [Quit: Reconnecting]
kristianpaul has joined #m-labs
Gurty has quit [Ping timeout: 252 seconds]
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
mumptai has quit [Quit: Verlassend]
futarisIRCcloud has joined #m-labs