03:11 <cr1901> The easy way I know how to do cartridge emulation is to use two separate DRAMs and refresh them out of phase with each other. Which nobody actually does in practice, so I'm clearly being lazy :P

03:13 <cr1901> _florent_: This may be a stupid question, but... how does litedram handle the edge case that "the refresh timer for row 'n' on a specific rank has triggered, but the CPU is currently in the process of doing a r/w to a separate row on that same rank."

03:13 <cr1901> how does litedram ensure that even if the CPU is in the middle of an xfer, the refresh happens while ensuring each row is refreshed every 64ms or whatever

04:34 <sajattack[m]> handy table of sdram timings https://github.com/MiSTer-devel/Wiki_MiSTer/wiki/Cores-that-use-SDRAM

13:08 <_florent_> cr1901: The 64ms is an average, it's common to postpone a few refresh command to avoid interrupting transfers and then do multiple consecusive refreshs.

13:09 <_florent_> cr1901: In LiteDRAM, the Refresher module advertises the core that a refresh should occur and let the core finish the current transfer before doing the refresh.

13:10 <_florent_> cr1901: By default, we don't postpone refreshes (postponing = 1 here: https://github.com/enjoy-digital/litedram/blob/master/litedram/core/refresher.py#L221)

13:11 <_florent_> cr1901: But it's common to postpone up to 8 refreshs.

15:54 <somlo> got the schematics (a pdf file) from the seller of the sitlinv-stlv7325-v2 board I just bought. He asked if I could "upload it to github" so others can see it too

15:55 <somlo> this is all via aliexpress auto-translation, mind you :) He said github is difficult for him due to language barrier, as far as I was able to follow

15:56 <somlo> so I promised I'd ask around: where would be a *good* place for that schematic to live (worst case, I can dump it into my personal github repo and share the link, but figured I'd try for a better place first)

15:56 <somlo> any ideas ?

16:00 <cr1901> _florent_: Thank you for the hint/source code links, they are very helpful

16:01 <cr1901> I knew that 64ms is an average. I designed an old DRAM chip tester on FPGA, and I opted to do refresh of all rows in a single burst. But I thought that each row _also_ had to be refreshed exactly 64ms (or less) after it was previously refreshed

16:03 <cr1901> I didn't know that there was enough slack to postpone refresh for a given row up to 15us * 7 + "time the currently executing command takes"

16:04 <cr1901> (up to 7 because, if postpone = 1, then refresh happens after current command, if postpone == 2, refresh happens after current command + next refresh interval, etc)

16:15 <cr1901> _florent_: Also, thanks for the "it's common to postpone up to 8 refreshs" remark. According to this paper, that's explicitly in the JEDEC spec (I didn't know this) https://memlab.ece.gatech.edu/papers/TACO_2014_1.pdf

19:33 <_florent_> somlo: An easy way to share the .pdf: Copy it to a github issue (in litex-boards) and share the link with us :)

19:36 <_florent_> cr1901: The is really an average and relaxed. You'll also see that at high temperature, it's recommended to shorten it, ex on DDR4, 32ms is recommended for T > 85C.

19:39 <_florent_> cr1901: BTW, a nice way to just visualize it: Use a Video Framebuffer with a static image (or just black) and disable refresh on your controller, you'll see some pixel degradation but that it's also relatively slow.

20:33 <cr1901> _florent_: Yea, against my better judgment, I'm thinking of making a crappy SDRAM and maybe hyperram core, just so I can say I did it. (Obviously use litedram when possible)

20:34 <cr1901> The framebuffer debugger is good advice

22:32 <somlo> _florent_: oh yeah, it could even be the PR I submit to add the platform and target files for the board :)

22:32 <somlo> good idea, thanks!