| *** tpb has joined #litex | 00:00 | |
| *** ambro718 has quit IRC | 00:05 | |
| *** freemint has joined #litex | 00:34 | |
| *** freemint has quit IRC | 00:39 | |
| *** freemint has joined #litex | 02:28 | |
| *** freemint has quit IRC | 02:33 | |
| *** freemint has joined #litex | 03:00 | |
| *** freemint has quit IRC | 03:05 | |
| *** freemint has joined #litex | 04:17 | |
| *** freemint has quit IRC | 04:21 | |
| *** freemint has joined #litex | 04:23 | |
| *** freemint has quit IRC | 04:28 | |
| *** CarlFK has quit IRC | 05:48 | |
| *** _whitelogger has quit IRC | 11:09 | |
| *** _whitelogger has joined #litex | 11:12 | |
| *** freemint has joined #litex | 11:50 | |
| *** rohitksingh has quit IRC | 12:20 | |
| *** freemint has quit IRC | 12:26 | |
| *** freemint has joined #litex | 12:27 | |
| *** rohitksingh has joined #litex | 12:36 | |
| *** synaption[m] has quit IRC | 12:39 | |
| *** xobs has quit IRC | 12:39 | |
| *** john_k[m] has quit IRC | 12:39 | |
| *** nrossi has quit IRC | 12:39 | |
| *** xobs has joined #litex | 13:25 | |
| *** synaption[m] has joined #litex | 13:26 | |
| *** nrossi has joined #litex | 13:26 | |
| *** john_k[m] has joined #litex | 13:26 | |
| somlo | _florent_: why does having a csr_data_width != 8 break SDRAM initialization? (https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_sdram.py#L33) | 13:26 |
|---|---|---|
| tpb | Title: litex/soc_sdram.py at master · enjoy-digital/litex · GitHub (at github.com) | 13:26 |
| 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? | 13:27 |
| somlo | or is there something else involved that I'm missing? | 13:27 |
| *** rohitksingh has quit IRC | 13:32 | |
| 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) | 15:22 |
| somlo | it fails if csr_data_width is 64 (at least with the trellisboard) | 15:25 |
| 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 ? | 15:48 |
| *** scanakci has quit IRC | 16:03 | |
| *** CarlFK has joined #litex | 17:09 | |
| *** freeemint has joined #litex | 17:09 | |
| *** ambro718 has joined #litex | 17:09 | |
| 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 :) | 17:10 |
| *** freemint has quit IRC | 17:11 | |
| _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 | 17:26 |
| _florent_ | somlo: that's something i want to remove but haven't spent time on it | 17:27 |
| 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) | 17:30 |
| 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) | 17:32 |
| somlo | which I haven't yet spent serious enough effort to actually understand, so I may be completely wrong :) | 17:32 |
| _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 | 17:40 |
| _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 :) | 17:42 |
| somlo | the thing that spreads (or collects) wider registers across multiple 8-bit chunks maybe ? | 17:42 |
| _florent_ | that's only related to the software | 17:51 |
| 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) | 18:15 |
| 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" | 18:15 |
| 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 | 18:16 |
| _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 | 18:16 |
| somlo | as you can tell, I have a rather "zoomed out", high-level understanding | 18:16 |
| somlo | oh, so basically somewhere in bios/sdram.c, and/or the generated csr.h and sdram_phy.h, then | 18:17 |
| _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 | 18:19 |
| 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 | 18:23 |
| _florent_ | somlo: i think it could be related to the way access sdram_dfii_pix_wrdata_addr/sdram_dfii_pix_rddata_addr | 18:32 |
| somlo | oh, I remember running into the MMPTR() macro when first getting 64bit rocket to work :) | 18:41 |
| *** scanakci has joined #litex | 18:51 | |
| *** Dolu has quit IRC | 20:09 | |
| *** rohitksingh has joined #litex | 20:14 | |
| *** Finde has quit IRC | 20:19 | |
| *** Finde has joined #litex | 20:20 | |
| *** CarlFK has quit IRC | 21:15 | |
| *** CarlFK has joined #litex | 21:19 | |
| *** Dolu has joined #litex | 22:17 | |
| *** freeemint has quit IRC | 22:33 | |
| *** freeemint has joined #litex | 22:33 | |
| *** freemint__ has joined #litex | 23:31 | |
| *** freeemint has quit IRC | 23:31 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!