Newbie DRAM interfacing questions - Page 1
Forum section: electronics / general

author: Kaisha
author_rank: Contributor
timestamp: March 06, 2024, 09:05:44 pm
content: I'm not sure if this should go here or elsewhere, since it's only indirectly related to FPGAs, and rather about DRAM. I'm learning verilog and making a toy/hobby CPU. I'm looking to interface with some very old 414256 DRAM modules (datasheet is attached as pdf below) and I have 3 questions.The first is, I'm confused as to the point of the #G pin. It's not shown in any of the timing diagrams (except for G-controlled late write cycle, and a few others) and yet it's mentioned in the descriptions of the timing diagrams. It seems strange that they would explicitly talk about #G and yet not show it.The second question is about setup times. Both #RAS and #CAS have a setup time for the address (and other pins) of 0ns. So I'm assuming I can set the address (and #W) pins on the same clock as I transition #RAS or #CAS? I just sort of assumed that if the address was 'clocked in' to a register that the address would have to be setup some time before the #RAS or #CAS transition. Also, despite all signals being sent on the same clock cycle, due to tiny variations in delay, could there be issues? Am I overthinking or misunderstanding this?The time between the #CAS transition and the time that the data is valid is measured as tCAC. Now I assume that doesn't include things like signal transmission over the pcb, and 'clocking in' the data to a register on the FPGA. If tCAC is say 25ns, do I have to wait 26ns? 27ns? before I can reliably read the data? Is there a way to estimate this delay?Thanks in advance for your time and patience

author: TomS_
author_rank: Frequent Contributor
timestamp: March 07, 2024, 08:53:37 am
content: To me, based on the description in the datasheet, #G seems to be something somewhat of an #OE signal that you find on SRAMs and ROMs - it enables the output buffers during read cycles. At a guess you could probably hook this up to the read signal of your CPU, or similar. Thats a bit strange, because so far all of the DRAMs Ive looked at derive read cycles from the write signal being negated once the column address is strobed.As for timing, this may be a bit of a "try it and see" kind of thing. Some DRAMs I used in a recent project also have a 0ns setup time on the row and column addresses, but I couldnt get away with strobing and changing addresses at the same time - I had to sequence my operation as 4 separate actions:set up row addressstrobe row addressset up column addressstrobe column addressI cant imagine any of the timing figures include any PCB traces, since these are complete unknowns for the memory device manufacturer. They will be nominal values for the memory device itself. For read it should give you the maximum amount of time it will take for the memory to present contents, you then need to add any delays required by your own circuitry such as intermediate buffers etc. It is often the case that a memory device will present data faster than quoted, but to rely on this behaviour you would need to characterise your memory devices and tread carefully.

author: Kaisha
author_rank: Contributor
timestamp: March 07, 2024, 02:51:16 pm
content: I appreciate the response, and my thoughts were similar.QuoteIs there anyway to estimate the delay needed for PCB traces and clocking in the data? If the datasheet shows the read data is stable after 25ns, should I wait 26ns? 27ns? Is there a 'rule of thumb' or some way to estimate when it's safe?

author: TomS_
author_rank: Frequent Contributor
timestamp: March 08, 2024, 01:37:11 am
content: There should be calculators available that can tell you how much delay there is in any given length of PCB trace, and also depending on the materials, inner vs outer layer etc. Try searching for "PCB trace delay calculator" and see what you get, although Ive never used one personally so I cant make any recommendations.I cant say Ive ever paid much attention to PCB trace lengths in my projects though. 1ns is roughly 1 foot in distance at the speed of light, and thats quite a lot of distance for a PCB trace. But for low speed systems operating in the single or very low double digit MHz ranges there is a relative eternity for signals to propagate quite long distances and through a couple of levels of logic before timing is going to become a significant issue IMO.

author: Kaisha
author_rank: Contributor
timestamp: March 08, 2024, 02:50:10 am
content: Sounds good, thanks for the info.