| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** timkpaine <timkpaine!~timkpaine@2603-7000-3202-ae2a-55e8-5ed2-6c5c-c559.res6.spectrum.com> has joined #litex | 00:06 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 01:14 | |
| *** TMM_ <[email protected]> has joined #litex | 01:15 | |
| *** Emantor <[email protected]> has quit IRC (Quit: ZNC - http://znc.in) | 01:20 | |
| *** Emantor <[email protected]> has joined #litex | 01:21 | |
| *** Degi_ <[email protected]> has joined #litex | 01:42 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 01:43 | |
| *** Degi_ is now known as Degi | 01:43 | |
| *** bl0x_ <bl0x_!~bl0x@p200300d7a7472c0058f41d167d732256.dip0.t-ipconnect.de> has joined #litex | 01:57 | |
| *** bl0x <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 01:58 | |
| 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:11 |
|---|---|---|
| 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 | 03:13 |
| *** timkpaine <timkpaine!~timkpaine@2603-7000-3202-ae2a-55e8-5ed2-6c5c-c559.res6.spectrum.com> has quit IRC (Remote host closed the connection) | 03:32 | |
| sajattack[m] | handy table of sdram timings https://github.com/MiSTer-devel/Wiki_MiSTer/wiki/Cores-that-use-SDRAM | 04:34 |
| _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:08 |
| _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:09 |
| _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:10 |
| _florent_ | cr1901: But it's common to postpone up to 8 refreshs. | 13:11 |
| *** indy <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 14:57 | |
| *** so-offishul <[email protected]> has joined #litex | 15:04 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b11::8> has quit IRC (Ping timeout: 246 seconds) | 15:08 | |
| *** so-offishul <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 15:09 | |
| 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:54 |
| 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:55 |
| 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 ? | 15:56 |
| cr1901 | _florent_: Thank you for the hint/source code links, they are very helpful | 16:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| 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 | 16:15 |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #litex | 16:52 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 255 seconds) | 16:53 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 16:59 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 250 seconds) | 17:00 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 17:29 | |
| *** TMM_ <[email protected]> has joined #litex | 17:30 | |
| *** tuff[m] <tuff[m]!~ratzupalt@2001:470:69fc:105::11fc> has joined #litex | 19:12 | |
| _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:33 |
| _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:36 |
| _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. | 19:39 |
| 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:33 |
| cr1901 | The framebuffer debugger is good advice | 20:34 |
| 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! | 22:32 |
| *** pharonix71 <pharonix71!~pharonix7@gateway/tor-sasl/pharonix71> has joined #litex | 22:41 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!