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
gric has joined #m-labs
IRCFrEAK has joined #m-labs
IRCFrEAK has left #m-labs [#m-labs]
<sb0> rjo, terminating flterm in 5min
<GitHub> [artiq] whitequark commented on commit bc3fc26: @sbourdeauducq When calling kernels from kernels, there is no access to `self.core`. https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20952766
<GitHub> [artiq] sbourdeauducq commented on commit bc3fc26: Yes, shouldn't this be consistent? https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20952777
<GitHub> [artiq] whitequark commented on commit bc3fc26: @jordens I really don't think we should expose mtspr/mfspr in ARTIQ Python. First, that breaks memory safety (and I think we don't currently have any way to do it otherwise). Second, the firmware and the gateware agree on the interface and go hand-in-hand, whereas the ARTIQ Python code is generally oblivious of all platform details. https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c
<GitHub> [artiq] whitequark commented on commit bc3fc26: I don't see the inconsistency. https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20952782
<GitHub> [artiq] sbourdeauducq commented on commit bc3fc26: @kernel when called from the host refers to ``self.core``. When called from a kernel it refers to the caller's core device. This is not consistent. https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20952806
<sb0> I just moved a 2x divider to bring the xilinx special snowflake CPLL VCO into the recommended range. what could go wrong?
<GitHub> [artiq] whitequark commented on commit bc3fc26: When called from the host, you go through the entire compilation and connection establishment dance. Calls on the core device are direct. This just follows from it... https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20952937
hedgeberg|away is now known as hedgeberg
<GitHub162> [migen] sbourdeauducq pushed 1 new commit to master: https://git.io/vDdtu
<GitHub162> migen/master 9212da1 Sebastien Bourdeauducq: fix/update copyright info
<bb-m-labs> build #133 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/133
<GitHub67> [misoc] sbourdeauducq pushed 1 new commit to master: https://git.io/vDdtw
<GitHub67> misoc/master 9074b5f Sebastien Bourdeauducq: fix/update copyright info
<bb-m-labs> build #205 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/205
madgoat has joined #m-labs
madgoat has left #m-labs [#m-labs]
<sb0> typical xilinx engineering. instead of fixing the problem in the first place (add_files is slow) they add a "critical warning" and an answer record
<sb0> also note the language: "performance intensive" and not "slow".
<GitHub27> [rust] whitequark pushed 1 new commit to artiq-1.17.0: https://github.com/m-labs/rust/commit/56b8f47909b37543d5423503224901c3f30527e6
<GitHub27> rust/artiq-1.17.0 56b8f47 whitequark: Unbreak libstd build after cfg-izing i128 in libcore.
<sb0> whitequark, what does this fix exactly?
<whitequark> rustc doesn't build
<sb0> https://anaconda.org/m-labs/rustc is 1.17 - how did that build?
<whitequark> it wasn't built in one go
mumptai has joined #m-labs
<whitequark> first the rustc. then artiq-1.17.0^ got committed. then libcore
FabM has joined #m-labs
mumptai has quit [Remote host closed the connection]
<GitHub58> [migen] sbourdeauducq pushed 1 new commit to master: https://git.io/vDd8m
<GitHub58> migen/master d4afdeb Sebastien Bourdeauducq: cdc: fix timeout counter clock domain in BusSynchronizer
<GitHub> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/8da28177a42e8da55a05d0a580f78813e74c7741
<GitHub> artiq/master 8da2817 Sebastien Bourdeauducq: conda: bump migen
<bb-m-labs> build #134 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/134
<GitHub> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/c66efc0279bd4cc9b5ccd89d330d4b06e1111e14
<GitHub> artiq/master c66efc0 Sebastien Bourdeauducq: moninj: do not require a rsys clock domain
<bb-m-labs> build #413 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/413
<bb-m-labs> build #421 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/421
<bb-m-labs> build #1330 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1330
kuldeep has quit [Read error: Connection reset by peer]
kuldeep_ has joined #m-labs
<bb-m-labs> build #414 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/414
<bb-m-labs> build #422 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/422
<bb-m-labs> build #1331 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1331
<GitHub> [artiq] jordens commented on commit bc3fc26: Are you saying that all other functions in the kernel API are completely safe?... https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20955191
hedgeberg is now known as hedgeberg|away
<sb0> whitequark, do we have std::io::Cursor on the core device?
<sb0> oh the byteorder functions that use that actually panic when they can't read the correct amount of data. that's not nice
<whitequark> we have Cursor but not integrated with byteorder
<sb0> so what is the recommended method to read/write data structures?
<whitequark> look at any of the *_proto.rs files
<sb0> already done that, they contain "FIXME: replace these with byteorder core io traits once those are in"
<sb0> hence my question
<whitequark> oh yeah, I was thinking of getting core_io integrated with byteorder
<whitequark> but using core_io in artiq requires on having core_error
* rjo is reassured by socat's example showing off its ability to eject CD-ROM media...
<whitequark> and the core_io guy doesn't want to do the core_error crate
<GitHub> [artiq] whitequark commented on commit bc3fc26: > Are you saying that all other functions in the kernel API are completely safe?... https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20955329
<GitHub> [artiq] jordens commented on commit bc3fc26: > If not that's a bug IMO. But yes I think they're safe as none of them take pointers or twiddle with registers that may alter something in memory.... https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20955560
<whitequark> e.g. if a load and a dcache miss happen at the same time the pccr will only get incremented once
<rjo> whitequark: yes. see my issue about that.
<whitequark> oh right.
<whitequark> how'd you even fix that?
<whitequark> without creating some massive adder tree or something?
<rjo> whitequark: pccr += count_bits_set(...) in gateware. might be costly.
<whitequark> I don't like this bitset design for PCMR
<rjo> pccr += count_bits_set(events & mask)
<whitequark> wonder if you could just have a counter per mask bit.
<whitequark> and have it cheaper
<rjo> whitequark: that's the workaround. yes.
<whitequark> well for now there are fewer counters than bits.
<whitequark> so it's not fully general
<whitequark> but I guess you could just document this as well.
<rjo> whitequark: yep.
<rjo> whitequark: also, when i played with it for a few minutes, the numbers didn't make sense to me. i.e. they only increase significantly when i do RPCs (kernel-to-host). but i didn't dig very deep.
<whitequark> we may want to make "syscalls" real syscalls.
<whitequark> so that we can set the CIUM bit.
<rjo> whitequark: absolutely.
<whitequark> ok.
<whitequark> what's your opinion on my proposed interface?
<GitHub> [artiq] jordens commented on commit bc3fc26: The SPR interface is defined in the architecture. It will error correctly if the PCU is not present (and not be silent).... https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20956702
<rjo> whitequark: sounds good.
<rjo> whitequark: do you want to do that? i guess you might be most interested in using the PCU when tweaking the compiler. i am not certain what you'd want the API to look like there exactly.
<whitequark> yes. I would like to do that
<GitHub> [artiq] whitequark commented on commit bc3fc26: > The SPR interface is defined in the architecture. It will error correctly if the PCU is not present (and not be silent).... https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20956726
<whitequark> lolwhat
<whitequark> [ 258he72t us] INFO(runtime::session): new connection from 180.156.1.1r :4 0 r
<whitequark> why would log entries arrive like this?
<whitequark> there's only one flterm running too
<GitHub> [artiq] jordens commented on commit bc3fc26: `mtspr` and `mfspr` behave in a well defined way (as per ISA). `pcu.py` checks for PCU/counter presence.... https://github.com/m-labs/artiq/commit/bc3fc26e3489722d2313aa777c11b2a649549e5b#commitcomment-20956785
<whitequark> oh right, you check for "counter not present"
<whitequark> I missed that
<whitequark> hm, and that mangled log isn't even because of UART, the entries are actually like that
<whitequark> wtf
<whitequark> I bet it's some binutils issue again
<cr1901_modern> *reads o1rk manual section on perfcount* Looks like more than just load/dcache miss at the same time can cause PCCRs to increment more than once? Implementing that seems really ugly/not well thought out :o
<sb0> whitequark, where should I use 'features = ["alloc"]' when depending on std_artiq in Cargo.toml?
<whitequark> sb0: [dependencies.std_artiq]
<whitequark> path = "..."
<whitequark> features = ["alloc"]
<whitequark> or:
<whitequark> std_artiq = { path = "...", features = ["alloc"] }
kuldeep has joined #m-labs
kuldeep_ has quit [Remote host closed the connection]
<sb0> okay, so there should be features = ["alloc"] at all times?
<whitequark> can you elaborate?
<sb0> everytime I add std_artiq to a Cargo.toml, it should have features = ["alloc"]
<whitequark> not really. for example, ksupport lacks the alloc feature
<whitequark> well, now that I look closer at it
<whitequark> this never really worked in the first place
<sb0> whitequark, about to use the kc705s in ~30min
<whitequark> ack
<whitequark> rjo: do you think updating mor1kx might have broken division?
<whitequark> hm, doesn't look like there are any relevant commits...
<rjo> whitequark: i checked the delta. didn't see anything relevant.
<whitequark> so, someone noticed that all the large numbers are off by 12
<whitequark> this system really has no shortage of baffling bugs
<whitequark> sb0: using kc705s?
<sb0> whitequark, just done. you can use them again.
<sb0> we have drtio aux packets! :)
<sb0> whitequark, what bug is that?
<whitequark> sb0: [ 258he72t us] INFO(runtime::session): new connection from 180.156.1.1r :4 0 r
<whitequark> this is how log entries look now
<whitequark> apparently the int-to-string conversion thinks this is how natural numbers go:
<whitequark> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | .. | 0x | 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 |
<sb0> I don't have this problem, what commit caused it?
<whitequark> hm
<whitequark> I haven't reduced it yet
<sb0> I have misoc 0.6.dev py_9+gite52727a
<sb0> artiq c66efc027
<whitequark> okay, so this isn't gateware
<sb0> there's always the possibility of some intermittent vivado miscompilation, but that's unlikely
<larsc> try to cooldown the FPGA ;)
<sb0> rjo, do you have any particular ideas or wishes about the DRTIO protocol for inputs?
cyrozap has quit [Ping timeout: 240 seconds]
kuldeep has quit [Ping timeout: 240 seconds]
cyrozap-ZNC has joined #m-labs
<rjo> sb0: did we discuss that previously? wanna discuss it now?
<rjo> sb0: i guess the buffers (FIFOs) would be on the satellite and then there would be a polling protocol to extract.
<rjo> sb0: maybe accelerated by the aux stuff for remote fifo status monitoring.
<rjo> sb0: apart from that i don't think i have thought about drtio nearly as deeply as you have.
<rjo> sb0: oh. maybe it is interesting to consider input DRTIO and remote DMA (output) together.
mumptai has joined #m-labs
<sb0> the aux packets are currently fully generated and processed by the cpu
kuldeep has joined #m-labs
<rjo> then is the question whether DRTIO input always needs a full round trip to get an event from the remote FIFO to the CPU?
mumptai has quit [Remote host closed the connection]