<GitHub62>
[artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/vXjHD
<GitHub62>
artiq/drtio cd334c0 Sebastien Bourdeauducq: Merge branch 'master' into drtio
<GitHub142>
[artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/vXjHA
<GitHub142>
artiq/drtio 5a2edef Sebastien Bourdeauducq: drtio: adapt example to new mu/second API
<GitHub148>
[artiq] sbourdeauducq opened issue #625: improve error message when a connection is attempted and startup kernel is still running https://git.io/vXjHh
<sb0>
cr1901_modern, any progress on the SPI fix?
<GitHub148>
[artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/vXj5q
<cr1901_modern>
sb0: Wrote a small testbench/created a stub SPI slave that echos the input back to the master. Not able to duplicate problem yet (which of course means something wrong with my testbench). Need to sleep, try again when I wake up in 5 hours or so.
<cr1901_modern>
I wrote a stub slave because the SPI core passes all tests when connected in loopback configuration. I think I'll be able to find the problem easier if I add non-loopback tests
FabM has joined #m-labs
Ultrasauce has quit [Ping timeout: 244 seconds]
Ultrasauce has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
bentley` has quit [Ping timeout: 244 seconds]
<sb0>
hmm how should the analyzer handle DMA?
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 245 seconds]
rohitksingh_wor1 has quit [Ping timeout: 250 seconds]
Gurty has quit [Ping timeout: 256 seconds]
Gurty has joined #m-labs
<rjo>
sb0: we can either (a) just record the DMA().play() event or (b) distribute the analyzer as well and do distributed recording.
<whitequark>
rjo: confirmed all your weird behavior here, currently addressing it
<whitequark>
rjo: oh. I remember now. I disabled the output of trace messages to the UART because it made RPC very slow.
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 45.5.0/20161115214506]]
FabM has joined #m-labs
rohitksingh has joined #m-labs
<whitequark>
rjo: all fie
<whitequark>
fixed*
<GitHub75>
[artiq] whitequark pushed 2 new commits to master: https://git.io/v1e2k
<GitHub75>
artiq/master 4df7941 whitequark: runtime: don't attempt to perform writeback if disabled in kernel....
<GitHub75>
artiq/master cd7527b whitequark: runtime: print trace level log messages to UART during startup....
<rjo>
whitequark: thanks.
<rjo>
whitequark: works
rohitksingh has quit [Read error: Connection reset by peer]
<whitequark>
it was attribute writeback after all. I haven't noticed that I dereference before checking, not after
<whitequark>
and so it didn't catch the NULL properly as I expected
<whitequark>
should've wrapped it into Option<usize>
<rjo>
that sounds like rust should have disallowed that by design.
<whitequark>
yes. it does. but I wrote a badly designed API around a C API in misoc.
<rjo>
whitequark: well. the copious `unsafe` blocks are to be taken seriously i guess ;)
rohitksingh has joined #m-labs
<whitequark>
indeed
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<GitHub192>
[artiq] jordens pushed 3 new commits to master: https://git.io/v1eaC
<GitHub192>
artiq/master a964cf2 Robert Jordens: runtime.rs/rtio.rs: style
<GitHub192>
artiq/master 347609d Robert Jordens: rtio: auto clear output event data and address...
<GitHub192>
artiq/master 8cce5d2 Robert Jordens: runtime.rs: wide rtio data
<rjo>
whitequark: ^ are those ok? the o_data and i_data registers will become wider than 64 bit soon.
<whitequark>
rjo: then the CSR headers/modules will not get generated (for either rust or c)
<whitequark>
for these registers that is
<rjo>
whitequark: exactly. that's what those commits are for.
<whitequark>
oh, I see,
<whitequark>
but that doesn't help you at all. rust doesn't have integer types wider than i64
<rjo>
whitequark: see rtio_output_list()
<rjo>
rtio::output_list() that is
rohitksingh has quit [Read error: Connection reset by peer]
<rjo>
could be renamed to output_wide() if that sounds better.
<whitequark>
rjo: ok, I understand it now
<whitequark>
one problem though, tuples aren't #[repr(C)]
<whitequark>
so you should make a #[repr(C)] struct ArtiqList and pass that (probably just by value)
rohitksingh has joined #m-labs
<whitequark>
the rest seems rather fine
<rjo>
whitequark: i mirrored cache_put() which seemed to do the same.
<whitequark>
ah wonderful, so that has a bug too.
<whitequark>
let me fix both
<rjo>
whitequark: thanks. and feel free to rename to output_wide() if that suits better.
<rjo>
sb0: then those 8 bits are the DRTIO "port"?
<sb0>
I'm fine with merging address into data
<sb0>
they're the port if we have one DRTIO core per link
<rjo>
... in the absence of a globally contiguous channel address space/"switch"?
<sb0>
but we can also make one DRTIO core manage multiple links, with the advantage of resource sharing and more efficient packing of the channel state BRAM
<sb0>
this is also more consistent with switches if/when they are implemented
<rjo>
which "this"?
<sb0>
one DRTIO core multiple links
<sb0>
but lower performance, if we have one DRTIO core per link we can have multiple DMA engines and a CRI crossbar
<rjo>
ack.
<rjo>
all good.
rohitksingh has quit [Quit: Leaving.]
<whitequark>
rjo: also found an ABI violation in Rust OR1K support, so let me fix that up. it'll take a while to rebuild.
<rjo>
whitequark: why should output_list or cache_put get their tuples in #[repr(C)] anyway? this is artiq-python calling rust, right? artiq-python could just do repr(Rust).
<sb0>
whitequark, did you end up doing the now register pinning btw?
<rjo>
re register pinning. can't we just pin the memory location of `now` to the o_timestamp csr location?
<GitHub93>
artiq/drtio 9941f35 Sebastien Bourdeauducq: rtio: use only CRI commands for rio/rio_phy resets
<sb0>
ffs
<sb0>
okay i properly fucked up that merge
<sb0>
aaargh
<sb0>
git merge strategies with -s: "This should not be confused with the 'ours' merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring 'our' history contains all that happened in it."
<whitequark>
bb-m-labs: force build --props=package=rustc conda-lin64
<bb-m-labs>
build forced [ETA 49 seconds]
<bb-m-labs>
I'll give a shout when the build finishes
<GitHub141>
[artiq] sbourdeauducq pushed 2 new commits to drtio: https://git.io/v1ejA
<GitHub141>
artiq/drtio 8b736dd Sebastien Bourdeauducq: drtio: update test
<GitHub141>
artiq/drtio 7cd27ab Sebastien Bourdeauducq: drtio: do not reset remote TSC on reset command
<sb0>
rjo, 200 is not ok?
<sb0>
anyway, 150 shouldn't be hard to support, we can have the link at 3 or 6 Gbps
rohitksingh has joined #m-labs
<rjo>
sb0: doesn't work for the required output frequency band.
rohitksingh has quit [Client Quit]
<rjo>
150 M does 300 M sample rate at 6 G jesd line rate, and can then covers 150-300 M with mix mode.
<rjo>
_florent_: by the way. i know you tend to use vivado's programmers. but if you start working on the kcu105 and want to use openocd: i had started the openocd/bscan_spi proxy bitstream support a while ago. if you need it i can clean it up.
<rjo>
whitequark: any chance that fix has other positive sideeffects, e.g. the freezing kernel upload thing?
<_florent_>
rjo: thanks, I'll tell you if I need it.
mumptai has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
<GitHub24>
[artiq] dhslichter commented on issue #570: OK, so for now we are foreclosing on the options of picoTCP, Gnuradio, etc? https://git.io/v1vRM
<GitHub192>
[artiq] jordens commented on issue #570: Picotcp yes, but we seem to have a reasonable alternative.... https://git.io/v1v0H
<GitHub125>
[artiq] jordens pushed 2 new commits to master: https://git.io/v1vgT
<GitHub125>
artiq/master dab19d2 Robert Jordens: runtime: support rtio data wider than 64 bit
<GitHub125>
artiq/master fbf6010 Robert Jordens: moninj.rs: force u32 dds_ftws
<GitHub17>
[artiq] r-srinivas opened issue #626: Check if ttl channel overridden from experiment code https://git.io/v1va7
<GitHub116>
[artiq] jordens commented on issue #626: I strongly advise against implementing that functionality in the way you describe it. It would violate the clear separation of functionality. Since stuff can become overridden at any time you would never be able to reliably detect that situation.... https://git.io/v1vMN
<rjo>
bb-m-labs: force build --props=package=rust-core-or1k conda-lin64
<bb-m-labs>
build forced [ETA 29m58s]
<bb-m-labs>
I'll give a shout when the build finishes