sdram controller

[Altera_Forum]

Greetings Gentlemen! 

 So I've been using SRAM for the longest time but I'm kinda at a point now where I want *MORE*. Unfortunately, this also means PAYING more so I'm kinda forced to use SDRAM. Trolled most of the forums and noticed that there aren't a lot of people writing their own SDRAM controllers. Probably for obvious reasons. Anyway, my needs aren't all that significant so I really want to roll my own. After reading various datasheets and looking at other people's code, I have a few questions:  1. High frequency. If I'm going to use a PLL, at some point I'll be pushing out >100mhz from a pin to SDRAM. Are there any precautions I need to take when laying out my PCB? ( other than keeping the trace as short as possible?) 2. Running at lower frequency. If I don't want to use a PLL and run it off, say 50mhz, will that cause any problems? As long as I adhere to the refresh timing, things should be dandy, no?  Ideally, I'd like to run at 100mhz as it's a nice multiple. Using auto-refresh and frequent enough access, which I'd have since I'll be using it as VRAM, I can probably get by with a static controller..  Any comments / feedback / warnings welcome!  Thoughts?  -Mux

[Altera_Forum]

Beuler? Beuler?

[Altera_Forum]

--- Quote Start ---  Beuler? Beuler?  --- Quote End ---   ??? Beuler ???

[Altera_Forum]

Ferris Beuler's Day Out? Anyone? Anyone? Shows my age I suppose :-)

[Altera_Forum]

--- Quote Start ---  Ferris Beuler's Day Out? Anyone? Anyone? Shows my age I suppose :-)  --- Quote End ---   I didn't see that film (yet) but a quick peek at Wikipedia didn't give me a clue what the connection is. Neither (IMHO) does the urban dictionary's definition (http://www.urbandictionary.com/define.php?term=beuler) apply. Now back to your question: I guess a lot of people have written their own controller. I have done a few, am in the process of doing another one but contemplating to just use Altera's IP and focus on other challenges in our products. PCB layout: you do not have to take any more care for PLL signals as for other output signals; evidently they all have the same range of rise time. Of course a clock signal over a poorly laid out PCB track shows it self ... Running the DRAM refresh from the video access is something I already did back in 1983 - building the controller with PALs and delay lines, saving a few expensive PALs and real estate. It simplifies the controller considerably.

[Altera_Forum]

I actually misspelled it. It's bueller. My bad :-) 

 The z80 had a DRAM refresh counter which I've used before but with SDRAM things seems to be a bit more complicated. Since this will be my first (simple) controller I'll probably base things around video timing with refresh taking place at fixed intervals, done in batches ( i.e. refreshing 4 rows each line or something similar ).  -Mux

[Altera_Forum]

Alright, after having perused various datasheets, I have a (perhaps) obvious question with regards to clocking and latency. Let me see if I can phrase this correctly: 

 Given a certain clock frequency, you can calculate how many clocks you'd need in order to satisfy timing requirements. For example, a tRCD of 15ns at 100mhz would imply 2 clocks, which would give you 20ns and therefore meet the timing requirements, whereas a 200mhz clock would imply at least 3 clocks. These figures are all listed in the datasheets as well as the timing in nanoseconds.  My question is whether or not SDRAM needs to be clocked or if you just need to satisfy those timing requirements. In the example above, you could either wait two clock periods or, if you would lower the clock speed (I know, different discussion) to say, 25mhz, you could submit two commands back-to-back as there would be ample time to satisfy the timing requirements.  So I guess to sum it up, are commands and data (in/out) the only ones that need to be clocked or do you NEED to clock in NOPs as SDRAM is a synchronous, pipelined architecture?  -Mux

[Altera_Forum]

--- Quote Start ---  Alright, after having perused various datasheets, I have a (perhaps) obvious question with regards to clocking and latency. Let me see if I can phrase this correctly:   Given a certain clock frequency, you can calculate how many clocks you'd need in order to satisfy timing requirements. For example, a tRCD of 15ns at 100mhz would imply 2 clocks, which would give you 20ns and therefore meet the timing requirements, whereas a 200mhz clock would imply at least 3 clocks. These figures are all listed in the datasheets as well as the timing in nanoseconds.   --- Quote End ---    --- Quote Start ---   My question is whether or not SDRAM needs to be clocked or if you just need to satisfy those timing requirements. In the example above, you could either wait two clock periods or, if you would lower the clock speed (I know, different discussion) to say, 25mhz, you could submit two commands back-to-back as there would be ample time to satisfy the timing requirements.   --- Quote End ---   Being SDRAM with the 'S for Synchronous' clocking is quite elementary ... The Cas-latency is specified in clocks and is minimum two (2). In theory at very low frequnecies this easily could be lowered to one (1) but I guess that the manufacturers (primarily JEDEC) didn't see the use of this so it can not be specified either.    --- Quote Start ---   So I guess to sum it up, are commands and data (in/out) the only ones that need to be clocked or do you NEED to clock in NOPs as SDRAM is a synchronous, pipelined architecture?  -Mux  --- Quote End ---   Yes you clock in NOPs, but this is automatic as a NOP is the absence of any other command.

[Altera_Forum]

--- Quote Start ---  In theory at very low frequencies this easily could be lowered to one (1) but I guess that the manufacturers (primarily JEDEC) didn't see the use of this so it can not be specified either.  --- Quote End ---    Yeah, I get that. My question though is whether or not wait-states need to be synchronous (ie clocked in) as well or if you just need to satisfy the timing requirement. So while the diagrams show (on average) 8-10 clocks at 100mhz, about 4-5 of those clocks are nops. At a lower frequency, you'd satisfy the timing constraints with fewer clocks, thereby (roughly) getting the same performance.  I'll give it a whirl. It'd save me a PLL which would allow me to go with a cheaper FPGA..  -Mux

[Altera_Forum]

--- Quote Start ---  My question though is whether or not wait-states need to be synchronous (ie clocked in) as well or if you just need to satisfy the timing requirement. So while the diagrams show (on average) 8-10 clocks at 100mhz, about 4-5 of those clocks are nops. At a lower frequency, you'd satisfy the timing constraints with fewer clocks, thereby (roughly) getting the same performance.   --- Quote End ---    As you say most timings are in ns, so at a lower frequency you need less clocks to satisfy that. Unfortunately the Cas-latency is specified in clocks. And yes all 'waitstates' have to be clocked as NOPs, but again NOPs come free.    --- Quote Start ---   I'll give it a whirl. It'd save me a PLL which would allow me to go with a cheaper FPGA..  -Mux  --- Quote End ---    Depends on how many you are going to produce. In a one-off project, I once made the mistake to stay with a smaller device. If I had upgraded to the next size even at twice the cost I would have finished on time ... IMHO, you don't need a PLL to interface to an SDR SDRAM

[Altera_Forum]

Thanks Josyb! 

 Alright, that's kinda what I thought. Commands and CAS-latency need to be clocked but the mandatory waiting time does not. In that case, at 25mhz it looks I can issue an activate followed by a read in the next clock. Then that needs to be followed up with 2 CAS-latency clocks to get the data moved through the pipeline.  Awesome! Thanks again!  -Mux