Good SDRAM Controller

[Peter Sommerfeld]

Hi folks,

Can anyone recommend an SDRAM controller, free or otherwise, with the
following features:
- synthesizable to >100 MHz fmax on Stratix -7 (preferably 133 MHz)
- allows latent read bursts to maximum throughput
- burtsts efficiently (keeps bank rows open where possible)

For starters, I am looking at Rudolf Usselmann's controller from
OpenCores but I'm concerned that the Wishbone interface may not
support latent reads. Can anyone confirm this?

I also looked at Altera's SDRAM controller but it won't synthesize
past 100 MHz.

Regards,

-- Pete

 

[Dave Vanden Bout]

petersommerfeld@hotmail.com (Peter Sommerfeld) wrote in
news:5c4d983.0406070634.385ec9ff@posting.google.com:

Hi folks,

Can anyone recommend an SDRAM controller, free or otherwise, with the
following features:

You might try the one at http://www.xess.com/projects/sdramtst-1_2.zip.
The documentation is at
http://www.xess.com/appnotes/an-030104-sdramcntl.pdf

- synthesizable to >100 MHz fmax on Stratix -7 (preferably 133 MHz)
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.

- allows latent read bursts to maximum throughput
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.

- burtsts efficiently (keeps bank rows open where possible)
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.

For starters, I am looking at Rudolf Usselmann's controller from
OpenCores but I'm concerned that the Wishbone interface may not
support latent reads. Can anyone confirm this?

I also looked at Altera's SDRAM controller but it won't synthesize
past 100 MHz.

Regards,

-- Pete

--
----------------------------------------------------------------
Dr. Dave Van den Bout
XESS Corp.
PO Box 33091
Raleigh NC 27636
Phn: (919) 363-4695
Fax: (801) 749-6501
devb@xess.com
http://www.xess.com

 

[Roger Larsson]

Peter Sommerfeld wrote:

Hi folks,

Can anyone recommend an SDRAM controller, free or otherwise, with the
following features:
- synthesizable to >100 MHz fmax on Stratix -7 (preferably 133 MHz)
- allows latent read bursts to maximum throughput
- burtsts efficiently (keeps bank rows open where possible)

For starters, I am looking at Rudolf Usselmann's controller from
OpenCores but I'm concerned that the Wishbone interface may not
support latent reads. Can anyone confirm this?

Why not ask the authors?

/RogerL

--
Roger Larsson
Skellefteĺ
Sweden

 

[Nicolas Matringe]

Peter Sommerfeld a écrit:

Hi folks,

Can anyone recommend an SDRAM controller, free or otherwise, with the
following features:
- synthesizable to >100 MHz fmax on Stratix -7 (preferably 133 MHz)
- allows latent read bursts to maximum throughput
- burtsts efficiently (keeps bank rows open where possible)

What about this one?
http://www.plda.com/pdt_core_mem.htm

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[Peter Sommerfeld]

Hi Nocolas, Dave,

Thanks for pointers. I will look into both controllers.

What about this one?
http://www.plda.com/pdt_core_mem.htm

 

[Peter Sommerfeld]

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

-- Pete

Why not ask the authors?

/RogerL

 

[rickman]

Nicolas Matringe wrote:

Peter Sommerfeld a écrit:
Hi folks,

Can anyone recommend an SDRAM controller, free or otherwise, with the
following features:
- synthesizable to >100 MHz fmax on Stratix -7 (preferably 133 MHz)
- allows latent read bursts to maximum throughput
- burtsts efficiently (keeps bank rows open where possible)

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.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

Peter Sommerfeld wrote:

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

-- Pete


Why not ask the authors?

/RogerL

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.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Peter Sommerfeld]

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

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.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[john jakson]

petersommerfeld@hotmail.com (Peter Sommerfeld) wrote in message news:<5c4d983.0406090721.24479ad@posting.google.com>...

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