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
rohitksingh has joined #m-labs
mumptai_ has joined #m-labs
mumptai has quit [Ping timeout: 240 seconds]
<sb0>
whitequark, ping
<whitequark>
sb0: pong
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 260 seconds]
_whitelogger has joined #m-labs
dbe has joined #m-labs
dbe has quit [Quit: Page closed]
<whitequark>
sb0: I am still stuck on the arbiter.
<whitequark>
after reviewing the code, I have no idea at all as to why it's not working right now, and therefore how changing it to a simple mux will help
<whitequark>
sb0: so this is interesting
<whitequark>
it's not the arbiter.
<whitequark>
it *hangs* when requesting the arbiter, but the *bug* is not *in* the arbiter, afaict
<whitequark>
I've determined this because it's address-dependent
<sb0>
dependent on the dma address?
<whitequark>
yes
<whitequark>
also, do you know that csr::rtio_dma::base_address_read() is hosed?
<sb0>
reproducibly? that's more interesting
<whitequark>
I write 40162940 there, I read 94000000
<whitequark>
and yes, it's reproducible every time
<sb0>
could it be some address conflict on the kernel cpu bus?
<sb0>
that could explain both problems
<whitequark>
hmmm
<whitequark>
like a CSR address assignment issue?
<whitequark>
it doesn't explain why DMA works at all
<sb0>
no, two wishbone slaves being incorrectly put at the same address
<sb0>
because writes could get broadcasted to both, whereas reads would come from one of them
<whitequark>
not that I can see?
<sb0>
is it only the address that has this bug, or is reading back other dma csrs also broken?
<sb0>
try the time offset reg
<whitequark>
yeah, trying now
<whitequark>
the time offset reg seems fine
<sb0>
then it's sounds like a vivado miscompilation, or a bug in misoc with data_alignment
<sb0>
alignment_bits in CSRStorage. but the analyzer and others also use that without problem...
<whitequark>
let's try reading the base address from analyzer
<sb0>
if you put another CSRStatus that reflects the current value of base_address, what does it get?
<sb0>
from analyzer?why?
<whitequark>
to see if alignment_bits works
<sb0>
I would add a CSRStatus to DMAReader, and do comb += debug_csr.status.eq(base_address.storage)
<sb0>
ah, you're talking about that. yes.
<whitequark>
yes, it definitely works in the analyzer.
<sb0>
ah, but the analyzer CSRs are not mapped on wishbone like the DMA CSRs are
<whitequark>
oh, I know what happens then
<whitequark>
the bus word size is different
<sb0>
yes
<whitequark>
hm
<whitequark>
maybe resetting arb_req is hosed also?
<sb0>
whitequark, you can try disabling alignment_bits. just replace self.base_address.storage with self.base_address.storage[data_alignment:] below
<sb0>
(after removing alignment_bits)
rohitksingh1 has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh has quit [Client Quit]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
<whitequark>
sb0: that makes the readout work
<whitequark>
but does not do anything with the hang
<whitequark>
sb0: actually, not quite
<whitequark>
it's weird
<whitequark>
I write 40162940
<whitequark>
I get back 0000000000162940
<whitequark>
sb0: if perhaps the same memory is aliased at 00000000 and 40000000
<whitequark>
then i guess it could be some cache effect?