Page 1 of 1

SDRAM Update Discussion

Posted: Mon Dec 14, 2020 3:31 pm
by aberu
Hey everyone.

Talking to a few people over time (jdeberhart recently brought it back up to my attention just today) and having read up on this before slightly in the old forums and these forums, including Sorgelig's previous comments on the matter... maybe there is a good discussion to be had over SDRAM design update options down the road as some of the newer cores are stressing the limits of the previous design. I'm reaching out here because I'm not very knowledgeable but I think a good consolidated discussion could be had here which the people with the know-how could contribute.

The current design's BOM (https://github.com/MiSTer-devel/Main_Mi ... mbly-(DIY)) calls for a particular SDRAM module that the MiSTer devs rely upon heavily. However, the bandwidth on this module might be limited in what can be accomplished using it. Additionally the space could potentially be upgraded. For reference:

Current RAM used: https://www.digikey.com/en/products/det ... IN/6589202 - or - https://www.digikey.com/en/products/det ... IN/6716555 - (the latter being "better" for having a higher clock frequency)

Additionally, Mouser's listing (which the wiki with the BOM links to) inaccurately lists the AS4C32M16SB-6TIN as "133MHz" when it is actually 166MHz according to Alliance Memory's datasheet. If builders of memory who sell them as a product have been using the 7TIN variant instead because of the Mouser listing, that error could be part of the unnecessary bandwidth limitation.

And finally, the price is the same between the two current modules. So if the SDRAM will stay the same, I guess it looks like the 6TIN model is superior and the 7TIN should be dropped from the BOM. Any thoughts on this?

Anyways, for replacement modules... Some potential and/or necessary considerations:

* Size, since many cases have been designed around the current size

* Compatibility with I/O header that is currently used

* Compatibility with Analog I/O shield/add-on board (which uses one of the arduino-style headers).

* Ready availability from distributors

So far the only "direct" equivalent that is faster that I have seen is this:

https://store.nacsemi.com/Products/Deta ... &instock=y

It's datasheet is basically a complete carbon copy of the AS4C32M16SB-6TIN/7TIN just there is one higher end module with 200MHz (and of course slightly lower write and read access times. It's basically the equivalent of Alliance making a "5TIN" model of their same chip.

Now I've been just made aware in discussing this option that the main problem could be that the SDRAM module has to multiplex the connections since there are so limited I/O for that single module. This could be acting as an artificial limiter and effect the capability of faster SDRAM modules from achieving their rated speeds. We've seen both 7TIN and 6TIN modules from Alliance Memory on the SDRAM board get 140MHz consistently using the test software on the MiSTer. Sometimes 130MHz. I'm sure there are rare instances of the 6TIN achieving 150 or even 160MHz for an extended period of time.

There is (using just my ignorant imagination) another option. Given that Direct video to VGA adapters are well supported now and seem to be working just as good as Analog I/O, it might make sense to make an "ultimate digital I/O board" instead that uses both headers and has the necessary memory upgrade soldered onto it.

Another option someone told me in discussion today is this - https://www.digikey.com/en/products/det ... TR/5019873 - But I'm unsure of the advantages and disadvantages of using this. Obviously it would require a redesign of the board to use.

Any thoughts/ideas, criticisms, are all welcome. Thanks for reading!

Re: SDRAM update discussion

Posted: Mon Dec 14, 2020 4:19 pm
by KnC
my understanding was not the speed of the chips as they ok when used on single chip pcb
but the way 2 chips are accessed on the one pcb due to the design because of the amount of io available

i could be totally wrong as it does not cause me any problems at the moment so i have not taken a 100% interest in it

Or it could even be something else as NEOGEO i thought was bandwidth hungry and that seems to play fine as is

Re: SDRAM update discussion

Posted: Tue Dec 15, 2020 2:50 am
by legacypixels
The chips aren't the issue, they are more than fast enough. It is extremely difficult to design a high speed board for the DE10 header, there was quite the discussion about it 'back in the day' on the old Atari-forum.

Re: SDRAM Update Discussion

Posted: Sat Dec 26, 2020 5:18 am
by Coffea
The discussion around "bad ram" is a little misleading. The ram chips are (for the most part) absolutely fine, it's everything between them and the FPGA chip that's a problem and only a small part of that right at the end of the line is in our hands.

MiSTer's ram is round the bend in an echoey twisty corridor, and rather than fix the corridor and remove the bend, all we can do is adjust the ram's shoelaces and try shuffling it about in a way that doesn't break all the things it already does.

Personally .. I can probably improve my (purchased) hand soldered module by reworking it little and tweaking some of the passives. But that doesn't address the base problem in anyway and doesn't mean it wont end up right back here with the next fancy-pants-core.

I'm not in any way upset with the designer or maker of the ram I have right now, nor do I wish to ascribe blame. Perfectly fine buying or building "better ram" as and when that's worked out. This one is going to be pretty nightmarish and I don't envy anyone the job.

We are going to need a more comprehensive memory test routine that does more than just access speed.

Re: SDRAM Update Discussion

Posted: Tue Dec 29, 2020 5:56 pm
by Duffygag
You are wasting your time :)

Re: SDRAM Update Discussion

Posted: Tue Dec 29, 2020 6:49 pm
by goofyseeker3
for the hsmc equipped boards, there should be ready made SDR SDRAM boards, even stuff like DDR4 boards, off-the-shelf.

Re: SDRAM Update Discussion

Posted: Tue Dec 29, 2020 7:46 pm
by jca
Would it be possible to use the arduino header with the 128MB module or are these pins stepping over the GPIO pins and unavailable for the 128MB module?