<sajattack[m]>
it looks like florent is potentially trying to run SMB on my oscilloscope which I'm all for.
<sajattack[m]>
(extrapolating a bit)
Degi_ has joined #litex
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
bl0x has joined #litex
bl0x_ has quit [Ping timeout: 240 seconds]
xralphack has joined #litex
xralphack has quit [Quit: Client closed]
shorne has quit [Read error: Connection reset by peer]
shorne has joined #litex
zjason`` has joined #litex
zjason` has quit [Ping timeout: 265 seconds]
lexano has quit [Ping timeout: 256 seconds]
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
lexano has joined #litex
<_florent_>
sajattack[m]: yes, I'm trying to explore a things a bit to see the possibilities and help Hans on MiSTeX for some features
<sajattack[m]>
Nice
<_florent_>
sajattack[m]: it seems the different project could benefit from it: MiSTeR stuck with the De10-Nano, code that is not really portable on Xilinx or open-source toolchains, etc... and this could require adding some interesting features to LiteX
<sajattack[m]>
Yeah
<_florent_>
sajattack[m]: One thing I'm also interesting to see is if we can emulate the SDRAM interface with LiteDRAM (and DDR3/DDR4) and a specific frontend
<_florent_>
sajattack[m]: if so, we could probably run the cores with only a DDR3, which could be another simplification of the hardware
<sajattack[m]>
Sounds difficult
<_florent_>
sajattack[m]: on paper, this seems possible.
<sajattack[m]>
The cartridges and such need very low latency random access
<sajattack[m]>
(simulated cartridges)
<_florent_>
indeed, but if we can emulate the SDRAM timings, it would be fine
<_florent_>
if you are interested to integrate the change you did in LiteX-Boards, feel free to create a PR for it.
<tnt>
One annoying thing is that every core uses a different controller :/
<tnt>
They are often derived from one another but they've been tweaked sometimes in subtle ways to fit whatever they were trying to emulate.
<_florent_>
arf, this will not simplify things...
<_florent_>
In fact to avoid touching too much MiSTeR internals (and keep these kind of tweaks) I was thinking about emulating the SDRAM directly on SDRAM pins (not on internal SDRAM interface). This way the controller used by the core would still be there. But we'll probably have to have much margin on DDR3 timings.
<gatecat>
this seems pretty tricky, because the basic access latency of DDR3/4 afaik isn't that much faster than SDRAM, so you don't have much margin for PHY etc
<_florent_>
gatecat: looking at the numbers, this is indeed probably too ambitious at the SDRAM interface level: 22.5ns for a SDRAM @ 133MT/S, 15.00 for a DDR3 @ 800MT/S.
<tnt>
What freq do the cores run the SDRAM at ? I'd actually expect a lot of them to be quite a bit slower than 133MHz.
<_florent_>
tnt: I also expect that for most of the cores. I'll probably study the requirements for the different cores
<_florent_>
this could be worth creating a script to extract the SDRAM controller core and configuration for the different core and then see the freq and if the controller has been tweaked.
<_florent_>
this could already provide a good idea of what we could run with a DDR3 doing the emulation
<_florent_>
doing the emulation at the user interface of the SDRAM core will give more margin, but if some very specific timings are required due to a tweaked controller, it can easily become a nightmare