SDR SDRAM controller for Xilinx Spartan-3E
in [FPGA]
|
Prev: Spartan 3E starter kit DDR SDRAM
Next: OpenSPARC
From: Martin Thompson on 6 Aug 2007 09:14 Eli Billauer <eli(a)billauer.co.il> writes: > Given the situation, I'm considering to create a DDR controller with > MiG for a memory with similar attributes (bus width, array size, etc) > and then hack it down to SDR. Since the command interface is the same, > that should leave me with changing the data flow, and make the burst > timing right. Not much fun, but hey, after debugging the MiG DDR > controller, I should survive this one as well. > > And here's the irony: I picked this SDRAM to make things simpler for > me. > > So before I start this little self torture, does anyone have a better > idea? Write one from scratch? SDR SDRAM is (as you rightly say) fairly straight-forward, especially if you don't need to maximise bandwidth, so you can have a simple state machine controlling it. I did one a very long time ago (my first bit of serious VHDL, so it can't have been that hard :-)... Alternatively, you could use a DDR controller and ignore every other byte :-) Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: Andy Peters on 6 Aug 2007 14:38 On Aug 4, 4:04 am, Eli Billauer <e...(a)billauer.co.il> wrote: > Hello, > > I would like to utilize a controller for a SINGLE data rate SDRAM > (Micron MT48LC16M16A2TG-75, to be specific). In the past I've used > Xilinx' MiG 1.4 to obtain a DDR2 controller, which I ended up pretty > happy with (after forgetting the via dolorosa to set it up...). Its > main benefit is a simple and convenient FIFO-based user interface. > > For some reason, I thought that MiG would create an SDR controller as > well (it's simpler, after all), but it turned out I'm very wrong: The > last piece of attention on Xilinx' behalf to SDR, which I've managed > to find, is xapp134. That paper, along with its HDL code, originates > in 1999, and is more or less the same ever since. The controller > offered is hence adapted to Virtex-I and Spartan-II, and is yucky is > several respects. > > Newer application notes (as well as MiG) relate to faster memory > classes (DDR, DDR2, QDR, you name it), with controllers eating up some > clock resources to solve timing problems. And all I wanted was a cheap > memory with reasonably simple access. > > Given the situation, I'm considering to create a DDR controller with > MiG for a memory with similar attributes (bus width, array size, etc) > and then hack it down to SDR. Since the command interface is the same, > that should leave me with changing the data flow, and make the burst > timing right. Not much fun, but hey, after debugging the MiG DDR > controller, I should survive this one as well. > > And here's the irony: I picked this SDRAM to make things simpler for > me. > > So before I start this little self torture, does anyone have a better > idea? I'm with Martin. Write your own SDRAM controller from scratch. It's really not difficult, and you can optimize it for your particular application. It shouldn't take more than a couple of days to write, simulate and verify it. -a
From: Eli Billauer on 7 Aug 2007 06:05 Thank you for your answers. What I really wanted to verify, is that there isn't an easy way which I've missed. And writing a controller for a very specific purpose from scratch is indeed not difficult, but writing one which makes a fairly good use of the bandwidth for a reasonable, but unknown access pattern, well, well... So I'll stick to my previous plan to downgrade the MiG controller, which has two great advantages: I know it, and I've seen it working. >From what I've managed to understand, the only major difference is startup sequence. I'll report back if I come across something worth mentioning. Thanks again, Eli
From: PFC on 7 Aug 2007 06:51 > Thank you for your answers. What I really wanted to verify, is that > there isn't an easy way which I've missed. > > And writing a controller for a very specific purpose from scratch is > indeed not difficult, but writing one which makes a fairly good use of > the bandwidth for a reasonable, but unknown access pattern, well, > well... > > So I'll stick to my previous plan to downgrade the MiG controller, > which has two great advantages: I know it, and I've seen it working. >> From what I've managed to understand, the only major difference is > startup sequence. I'll report back if I come across something worth > mentioning. Could you use the mch_opb_sdram controller from Xilinx EDK in your application ?
From: PFC on 7 Aug 2007 12:20
> Now I have my own small (~2000 lines including Microblaze interface) > controller, > with open row management for all banks, burst support (>350MB/s from a > 16Bit/133MHz DDR) and 5 independent ports with local burst data caches > and an > easy command like interface... The size is about the same as the > mch_opb_ddr. The > Microblaze R/W memory performance also nearly doubled, and there are > still some > unnecessary latencies left for later optimization. Would there be any remote possibility of imagining that you might some day consider the idea of putting this on OpenCores ? PS : I read your homepage, quite interesting ! I see you do home soldering of BGAs. Since you're in Europe like me, can you point me to a PCB prototyping fab that can handle the PCB tolerances needed for BGA escape routing ? PCB-POOL cannot... |