Good SDRAM Controller

snipped-for-privacy@hotmail.com (Peter Sommerfeld) wrote in news: snipped-for-privacy@posting.google.com:

You might try the one at

Unknown. It runs at 100 MHz on an the slowest speed grade of SpartanII. It does use Xilinx DLLs at the very top-level but these can be stripped out without any effect. The rest is standard VHDL so it should be synthesizable for Altera.

It does have some delay when you first read from a row if the row was not already open, but after that you can pipeline the reads so you get a new word every cycle. Writes work the same way.

Yes, it does that but it doesn't keep rows open in separate banks. So you incur the delay of opening a row each time you read or write to a different bank.

Why not ask the authors?

/RogerL

Peter Sommerfeld a écrit:

What about this one?

Hi Nocolas, Dave,

Thanks for pointers. I will look into both controllers.

Yes I emailed yesterday morning ... waiting on reply.

-- Pete

I know that it takes time to design your own module and debug it. But an SDRAM controller is actually very easy. I have built them before and did not have *any* trouble with it other than a bug in my state machine that would create a hang if the local bus (not the memory bus) was operated in a way I did not expect. Of course, we were only running at a slow rate. But most of the problems you will have with 133 MHz will be external to the chip, not internal. It is not hard to design logic that has a pipeline delay of 7.5 ns if you are at all careful about your design. And memory controllers almost have to be pipelined if you want speed.

If you can't find a core you like, I can guaranty a simulated design in a week once the specs are fully nailed down.

I don't know if you will get a speedy reply. Rudolf Usselmann has contributed a lot of cores and I expect he is getting a lot more questions than he can answer and still work full time. I believe these are cores that his company has paid to develop and they expect to get some consulting income from supporting them, but I doubt that they ask money to answer a simple question, I just don't expect them to be quick about answering.

Hi Rick,

Yes I've taken the route of developing my own. The opencores one didn't cut it - 2000 LEs and 64 MHz fmax, which is much too big and slow for me (mind you, it lets you change SDRAM timing parameters on the fly via registers, but that's a feature I don't need).

Like you say, after poring over some Micron datasheets and drawing up a state machine it didn't seem too difficult. My first compile has fmax 135 Mhz without setting a target fmax in Quartus, and 780 LEs (could be less with register packing option turned on). I also added something I think might be useful, which is piling up refresh events so that they are done only at the end of a long bursts, instead of interrupting them. Hopefully this will help reach theoretical max bandwidth in the case of long bursts within open rows followed by a bit of idle time (exactly the model of my video app).

Now comes the task of testbenching and debugging. I was hoping I didn't have to reinvent the wheel, but I think I'll have exactly what I want when I'm done.

-- Pete

Both X & A have loads of appnotes on these controllers and esp they get into board and signal, timing issue. By the time I read the Micron and Xilinx and PLD notes, I felt the same way (reading the same thing over & over), doing your own will get you a direct interface that will maybe be smaller than the general designs.

regards

johnjakson_usa-com