<somlo>
is it because mmio writes to the registers involved takes a different number of clock cycles, now that they're wider and one doesn't have to string bits together across multiple registers?
<somlo>
or is there something else involved that I'm missing?
rohitksingh has quit [Ping timeout: 245 seconds]
<somlo>
_florent_: interesting, if I set csr_data_width to 32 bits on litex+rocket, memtest passes (if I also comment out the NotImplementedError line in soc_sdram)
<somlo>
it fails if csr_data_width is 64 (at least with the trellisboard)
<somlo>
hmm, still digging for clues, but maybe the limit on csr_data_width is imposed by the data width of the wishbone bus the CSRs are attached to ?
scanakci has quit [Quit: Connection closed for inactivity]
CarlFK has joined #litex
freeemint has joined #litex
ambro718 has joined #litex
<somlo>
meh, with csr_data_width 32 it fails consistently on the nexys4ddr, so there's still likely some sort of timing component, back to digging through sources for clues :)
freemint has quit [Ping timeout: 250 seconds]
<_florent_>
somlo: ah, i forgot about that yesterday. There is indeed a current limitation in the sdram initialization code for the csr_data_width, it's hardcoded for csr_data_width=8
<_florent_>
somlo: that's something i want to remove but haven't spent time on it
<somlo>
_florent_: so it kinda-sorta works on *some* boards, *some* of the time, with data-width 32 (i.e., trellis, with the rocket-chip)
<somlo>
which intuitively feels like a timing problem (i.e., how many clock cycles we must spend waiting before transitioning to a specific next state in the initialization FSM)
<somlo>
which I haven't yet spent serious enough effort to actually understand, so I may be completely wrong :)
<_florent_>
somlo: i don't think it's a timing problem, but just some harcoded write/read that assume a csr_data_width of 8
<_florent_>
somlo: if it's working with csr_data_width != 8, it's probably that last configuration applied for the training is working and that you are lucky :)
<somlo>
the thing that spreads (or collects) wider registers across multiple 8-bit chunks maybe ?
<_florent_>
that's only related to the software
<somlo>
_florent_: is it? The way I understand it, "registers" of more than csr_data_width are split up and placed at (32 or 64 bit) aligned locations, in chunks of csr_data_width (8bit currently)
<somlo>
and it's both the software and the gateware that have to "spread out" and "collect" those registers, from the two sides of the "csr interface"
<somlo>
so, there might be a parameterization bug where the scattering and gathering fails somehow, either on the software side, or on the gateware side
<_florent_>
somlo: yes, but the gateware should be fine regarding that (ie no harcoded things), it's the software in sdram.c that is doing some assumptions
<somlo>
as you can tell, I have a rather "zoomed out", high-level understanding
<somlo>
oh, so basically somewhere in bios/sdram.c, and/or the generated csr.h and sdram_phy.h, then
<_florent_>
somlo: i'm using csr_data_width=32 on very various designs, so i'm pretty sure it's only a software limitation in sdram.c
<somlo>
_florent_: good to know, thanks! I was looking at the generated headers, and the various read/write methods look like they're doing the right thing
<_florent_>
somlo: i think it could be related to the way access sdram_dfii_pix_wrdata_addr/sdram_dfii_pix_rddata_addr
<somlo>
oh, I remember running into the MMPTR() macro when first getting 64bit rocket to work :)
scanakci has joined #litex
Dolu has quit [Ping timeout: 240 seconds]
rohitksingh has joined #litex
Finde has quit [Ping timeout: 240 seconds]
Finde has joined #litex
CarlFK has quit [Ping timeout: 250 seconds]
CarlFK has joined #litex
Dolu has joined #litex
freeemint has quit [Remote host closed the connection]
freeemint has joined #litex
freemint__ has joined #litex
freeemint has quit [Read error: Connection reset by peer]