Interfacing cheap DDR-SDRAM with 8-bit controller via software on 2-layer PCB

[soFPG]

I would avoid TXB type in this application

Okay, I used the 74LVX4245 in my design as you recommended.

they have high  output impedance and can oscillate of there is much capacitance on them.

Do you know if the same is true for the 74LVX4245?

I created a basic first schematic, it would be really nice if someone could take a brief look and tell me if there is something terribly wrong.

The only thing I am worried about for the moment is, that at startup the address pins of the EFM8 are not set as GPIO output and could therefore be damaged if the DRAM outputs 5V (for some weird reason).

Is that a legitimate concern?

[soFPG]

I would be very happy to receive any feedback to the schematic I posted above ☺

[hamster_nz]

I think some may be missing the obvious problem with SDRAM, that they need a refresh cycle,  and you have to do them if you want your data to persist.

At fast clock speeds the overhead of (say) 10 cycles every 8us is very low maybe a few %

At 1MHz it is impossible to run SDRAM as you can't issues refresh quick enough, and it eats up all your bus bandwidth.

This is a gross oversimplification, but you should get the idea - it is not practical until you start hitting around 10MHz or so because of the inherent nature of the technology.

There is some "cellular dram" that hides the refresh internally. I've used it on a few old FPGA boards. That might work. See if you can find the part number used on the Digilent Nexys 2 FPGA dev board.

[Siwastaja]

Layout:

Use a ground plane on the bottom; minimize number of tracks on it. Whenever you absolutely need a track there, try to arrange a piece of contiguous ground plane on the top, at the same place, and stitch the ground pieces together with vias on both side of the tracks. Follow the path of return currents of your data/address/clock/control lines; these run from the GND pins of your memory chip / MCU, possibly through vias, to your ground plane. On a 2-layer design, it's never perfect, and it's OK. But do take a careful look, a beginner can easily make a mistake (e.g., gap in the ground plane due to other traces; no stitching) which costs many inches of extra length for the return current, which can cause problems.

Refresh:

Note that while the datasheets tend to specify refresh times such as 64ms, this guarantees functionality in worst-case operating conditions (specifically, highest allowed temperature). If your device is your personal one-off and you know it's not going to ever operate near the maximum temperature, and it's not a life-critical system, by all means extend this time if it makes your life easier. I have personally made some tests at room temperature to see that actual data loss starts to happen between 5 and 10 minutes of no refreshing. A few second interval (instead of 64ms) is almost always safe if you leave some 30-40 degC margin to the highest operating temperature.

[mikeselectricstuff]

Refresh:

Note that while the datasheets tend to specify refresh times such as 64ms, this guarantees functionality in worst-case operating conditions (specifically, highest allowed temperature). If your device is your personal one-off and you know it's not going to ever operate near the maximum temperature, and it's not a life-critical system, by all means extend this time if it makes your life easier. I have personally made some tests at room temperature to see that actual data loss starts to happen between 5 and 10 minutes of no refreshing. A few second interval (instead of 64ms) is almost always safe if you leave some 30-40 degC margin to the highest operating temperature.

On the flip side, don't just do refresh whenever the memory is idle as power consumption in refresh mode is very high & the chips can get really hot!
 

[amyk]

Note that while the datasheets tend to specify refresh times such as 64ms, this guarantees functionality in worst-case operating conditions (specifically, highest allowed temperature). If your device is your personal one-off and you know it's not going to ever operate near the maximum temperature, and it's not a life-critical system, by all means extend this time if it makes your life easier. I have personally made some tests at room temperature to see that actual data loss starts to happen between 5 and 10 minutes of no refreshing. A few second interval (instead of 64ms) is almost always safe if you leave some 30-40 degC margin to the highest operating temperature.

In a different context, some others tried to characterise this, and found that it varies widely: https://cacm.acm.org/magazines/2009/5/24652-lest-we-remember/fulltext (see figure 2)

[soFPG]

Why are the replies from @amyk, @mikeselectricstuff and @Siwastaja so different from @hamster_nz?

If I have interpreted your answers correctly, my schematic does not contain any mistakes?

The only thing I should be carefull about is routing the PCB?

Edit: I don't get why clockrates  <= 1MHz would be a problem, async. DRAM was used like 40 years ago, and CPUs at that time ran at a max. of 2MHz

[hamster_nz]

Why are the replies from @amyk, @mikeselectricstuff and @Siwastaja so different from @hamster_nz?

If I have interpreted your answers correctly, my schematic does not contain any mistakes?

The only thing I should be carefull about is routing the PCB?

Edit: I don't get why clockrates  <= 1MHz would be a problem, async. DRAM was used like 40 years ago, and CPUs at that time ran at a max. of 2MHz

I did some more research, and bothered to look at a data sheet for MT48LC4M16. I once wrote a SDRAM controller for this part, but that was a long time ago.

To work in spec you have to refresh all 4096 rows every 64ms, so you need to issue an auto refresh once every 15.625us. Each refresh command takes two cycles.

Looking at Figure 40 & 46, a single word read, with auto pre-charge takes 6 clock cycles, and a single write with auto pre-charge takes 7.

If running on a fixed schedule of a read or write memory access followed by a refresh you will get one memory operation+autorefresh every 9 cycles.  To be in spec, those 9 cycles need to happen every 16us, giving a minimum feasible clock rate of about 0.562MHz, and a memory bandwidth of 64k single-words transactions per second.

Of course you can use bigger burst transfers to increase your bandwidth, but that will also require an increase the minimum clock speed.

You could also clock slower if you issued multiple refresh cycles back to back, with the minimum being 8092 clocks every 64ms. (about 8us/0.125MHz) but that leaves no cycles to actually access the memory!

[asmi]

Edit: I don't get why clockrates  <= 1MHz would be a problem, async. DRAM was used like 40 years ago, and CPUs at that time ran at a max. of 2MHz

Async DRAM is long dead as far as I know.
Also - here is what Micron has to say on DLL disabled mode for their DDR3 chips (you have to disable DLL to be able to drive these chips at low frequencies):

The DRAM is not tested to check—nor does Micron warrant compliance with—normal mode timings or functionality when the DLL is disabled. An attempt has been made to have the DRAM operate in the normal mode where reasonably possible when the DLL has been disabled; however, by industry standard, a few known exceptions are defined:
• ODT is not allowed to be used
• The output data is no longer edge-aligned to the clock
• CL and CWL can only be six clocks
When the DLL is disabled, timing and functionality can vary from the normal operation specifications when the DLL is enabled (see DLL Disable Mode (page 123)). Disabling the DLL also implies the need to change the clock frequency (see Input Clock Frequency Change (page 127)).

Translation for inexperienced datasheet readers: "DO NOT USE THIS MODE, we don't know - nor do we really care - how will it behave in this mode, hence we can't guarantee anything.".

As for this solution - I personally think it's insane. Why would you even need a lot of RAM with 8 bitters? I struggle to come up with any more-or-less realistic scenario when it could be useful. The two advantages 8 bitters have over 32bit ARMs - simplicity and low power - both disappear in this case. So why not pick some ARM Cortex MCU with built-in SDRAM controller instead?

[soFPG]

I did some more research, and bothered to look at a data sheet for MT48LC4M16.

I don't use that one. As you can see in my schematic. Sorry that I've changed my way in the middle of the post, which has apparently led to confusion.

Async DRAM is long dead as far as I know.

I may say you didn't read the complete thread. I am using async DRAM (KM44C256B).

Why would you even need a lot of RAM with 8 bitters?

I won't use it on the same µC. This EFM8 is just controlling the DRAM, refreshing it, reading & writing the data from / to the RAM it is getting via SPI from another 8-bit controller. It should basically behave like SPI SRAM to another controller.

disabled mode for their DDR3 chips

I do not know why you bring DDR3 into play now. 

[colorado.rob]

I may say you didn't read the complete thread. I am using async DRAM (KM44C256B).

Wow.  Are those chips still available?  I am surprised those were not made obsolete decades ago.

[soFPG]

Are those chips still available?  I am surprised those were not made obsolete decades ago.

I don't think they are still in production, but you can get those from old hardware. I just found an old graphics card (OTI067 from Oak Tech) in my cellar. It has 4 of these DRAM chips soldered onto the PCB. Two are in DIP and the other two are in SOJ-Package.

[blacksheeplogic]

Refresh:
Note that while the datasheets tend to specify refresh times such as 64ms, this guarantees functionality in worst-case operating conditions (specifically, highest allowed temperature). If your device is your personal one-off and you know it's not going to ever operate near the maximum temperature, and it's not a life-critical system, by all means extend this time if it makes your life easier. I have personally made some tests at room temperature to see that actual data loss starts to happen between 5 and 10 minutes of no refreshing. A few second interval (instead of 64ms) is almost always safe if you leave some 30-40 degC margin to the highest operating temperature.

I worked on a HPC case where the application could spend many seconds not going back out to main memory (they had optimized for the cache size). Error Correction did flag the occasional corruption of a bit due to an interesting bug in refreshing. I don't think the contents of memory is an area you want to be introducing risk, it took a lot of effort with a significant cost associated to figure this problem out not to mention the problems addressing the client confidence these type of issues cause.

[asmi]

I may say you didn't read the complete thread. I am using async DRAM (KM44C256B).

The title says DDR SDRAM, not sure what does async DRAM hava to do with this.

I won't use it on the same µC. This EFM8 is just controlling the DRAM, refreshing it, reading & writing the data from / to the RAM it is getting via SPI from another 8-bit controller. It should basically behave like SPI SRAM to another controller.

Are there any EFM8's with enough IO pins for that? Normally I'd say this is a job for FPGA.
Still I'm at loss as to why would you need a lot of super-slow RAM. Can you give some details on the intended application?

I do not know why you bring DDR3 into play now. 

Believe or not, DDR3 is a type of DDR SDRAM.

[mikeselectricstuff]

Don't forget there are some quite large SPI SRAMs available cheaply :

https://lcsc.com/product-detail/RAM_Lyontek-Inc-LY68L6400SLIT_C261881.html
https://lcsc.com/product-detail/RAM_VTI7064MSME_C139966.html

[colorado.rob]

After reading this thread, this has nothing to do with finding the most efficient solution.  No one looking at a solution involving reclaiming obsolete chips from old video cards cares about that.  I suspect that OP is building a Rube Goldberg electronic device for his own amusement & edification.  Or maybe he's just trolling this forum.

[Scrts]

There are also PSRAMs, which are easy to interface to small micros as well.

[PCB.Wiz]

I then took a look at Aliexpress, and they sell 5 Pieces of DDR-SDRAM (32Mbyte x 16Bit) for a little bit over 2$ (https://www.aliexpress.com/item/5pcs-lot-HY5DU121622CTP-D43-HY5DU121622CTP-DDR64M-SDRAM-TSSOP-66/32954967053.html).

Of course, interfacing SDRAM is a lot (a lot) more complex than using already built in SPI / I²C.

But I was wondering, especially because these SDRAM-Chips are comming in a solderable TSSOP package, if interfacing this chips could be done not only on a 2-layer PCB but also without any hardware support from a microcontroller, only via pin toggling?

This may sound crazy - but it seems like an interesting project to me.

See above links for SO8 packaged QuadSPI SDRAM (PSRAM) LY68L6400SLIT  VTI7064 & also
https://www.electrodragon.com/product/2pcs-ipus-ips6404-iot-ram/

That PSRAM still has refresh rules, but has a much lower pin count, and has hidden refresh that can make the MCU task simpler.
You can connect 2, or 4 of these, depending on if you need 8 or 16b interfaces.

[soFPG]

The title says DDR SDRAM, not sure what does async DRAM hava to do with this.

It's quite common that the topic shifts into different directions as different opinions come up on the way.

Are there any EFM8's with enough IO pins for that?

Well, I successfully made a schematic with one. It has 28 GPIOs, which apparently is enough.

Believe or not, DDR3 is a type of DDR SDRAM.

Believe me or not, to interface DDR3 is, as you may already know, in a completely different ballpark compared to SDR-SDRAM.

Don't forget there are some quite large SPI SRAMs available cheaply

I always looked at mousers parametric search and it never came up with such cheap SRAM 

I suspect that OP is building an [..] electronic device for his own amusement & edification

I sure do, I don't see what is wrong with doing things which are fun?

You can connect 2, or 4 of these, depending on if you need 8 or 16b interfaces.

Thanks, as I already mentioned, I only used mouser parametric search and it never came up with such RAM (or I didn't look closely enough).

Honestly, I am just really excited to use almost 30 year old hardware and try to get it back to life. 

[Axk]

Are these SPI SRAM chips cheaper than parallel ones because they are slow?

[PCB.Wiz]

Are these SPI SRAM chips cheaper than parallel ones because they are slow?

Not entirely, the other saving, is they are not static SRAM memories, but are DRAMS, with refresh (in some cases 'hidden') and that imposes rules on their use.

[PCB.Wiz]

You can connect 2, or 4 of these, depending on if you need 8 or 16b interfaces.

Thanks, as I already mentioned, I only used mouser parametric search and it never came up with such RAM (or I didn't look closely enough).

Mouser do not stock all  parts

They do have Static 4MBit SRAMS now, in SO8, which is a boost in the previously std speeds of just 20MHz.
SRAM 4Mb 512Kx8 45MHz Serial SRAM IT

A single PCB layout could accept either these SRAMs, or the PSRAMs listed above.

[legacy]

There are also PSRAMs, which are easy to interface to small micros as well.

what is PSRAM? and can you give me an example?
thanks 

[asmi]

what is PSRAM? and can you give me an example?
thanks 

Pseudo-Static RAM. It's DRAM with integrated controller, so to outside world it appears as SRAM. Example

[legacy]

wow, that's really comfortable
is there any chip not in BGA package?