EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

How to add some SDRAM to a FPGA board ?

Started by whygee January 21, 2009
Hello,

I thought that I could ask for advices on this group
since most high-end embedded CPU have the same constraints.

I would like to add a good RAM capacity to existing
evaluation/development boards equiped with 2.54mm pins.
Ideally that would mean 32 or 64MB with a 16-bit datapath
(32-bit would be too wide, too many wires...).
SRAM are not possible, the largest I have are 36Mbits in BGA,
this is not suitable for a first prototype.
And using/hacking a SODIMM is not suitable either because
they are 64-bit wide.

I also have SDRAM chips that fit the description,
like PC133 compatible 256Mbits SSOP with 8-bit or 16-bit wide bus.
However, I don't feel like making a PCB for just 1 or 2 chips.
There is still the old hack of wiring the pins with fine wires
but the chips are very fine pitch (.65mm) and it's going to be difficult...

Is there another method ?

Oh, and once the chips are wired (a pair of 256Mb will give 64M bytes),
how does one initialises and uses these complex beasts ?

yg

-- 
http://ygdes.com / http://yasep.org
whygee wrote:

> I would like to add a good RAM capacity to existing > evaluation/development boards equiped with 2.54mm pins. Ideally that > would mean 32 or 64MB with a 16-bit datapath (32-bit would be too wide, > too many wires...). SRAM are not possible, the largest I have are > 36Mbits in BGA, this is not suitable for a first prototype. And > using/hacking a SODIMM is not suitable either because they are 64-bit > wide. > > I also have SDRAM chips that fit the description, like PC133 compatible > 256Mbits SSOP with 8-bit or 16-bit wide bus. However, I don't feel like > making a PCB for just 1 or 2 chips. There is still the old hack of > wiring the pins with fine wires but the chips are very fine pitch > (.65mm) and it's going to be difficult... > > Is there another method ?
I'm afraid you're not going to be able to (easily) achieve what you want. First off, you'd need to clock the SDRAM with the output of a PLL, so that you can control the skew wrt the control/data lines. Also, with a 133MHz clock you need to match trace length/impedence on all the pins from FPGA to SDRAM. That just ain't going to happen with a 'old hack [job]'. You also need an SDRAM controller inside the FPGA, parameterised to your particular SDRAM chips. You need to find yourself an eval board with SDRAM already. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266
Mark McDougall wrote:

> You need to find yourself an eval board with SDRAM already.
Alternatively, you could find some other high-density (non synchronous?) memory technology... not up on these sorry. Anyone else? Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266
Mark McDougall wrote:
> Alternatively, you could find some other high-density (non synchronous?) > memory technology... not up on these sorry. Anyone else?
The best I have is 4MB of static RAM, which is already large (and some room too, with two DIP40 packages, and time, since it's 70ns access time) but won't buffer enough data...
> Regards,
thanks, yg -- http://ygdes.com / http://yasep.org
Mark McDougall wrote:
> whygee wrote: >> Is there another method ? > > I'm afraid you're not going to be able to (easily) achieve what you want.
That's what I thought...
> First off, you'd need to clock the SDRAM with the output of a PLL, so that > you can control the skew wrt the control/data lines.
I think that it is possible with the FPGA that I use (Actel ProASIC3), I have spotted functionalities of the IO pads that ease these designs. They have things like programmable delays and skews to avoid driver contention on bidirectional buses for example.
> Also, with a 133MHz > clock you need to match trace length/impedence on all the pins from FPGA > to SDRAM. That just ain't going to happen with a 'old hack [job]'.
hmmmm If I cut a bunch of same-length wires, a la Cray-1, that could maybe help... (kidding) Fortunately, the eval boards have rather short traces to the headers so impedence will not be a big problem (I hope). Also my designs don't clock faster than 100MHz, and I thought that it's possible to downclock SDRAM chips, provided the cycles are adjusted.
> You also need an SDRAM controller inside the FPGA, parameterised to your > particular SDRAM chips.
Sure, I'm looking at datasheets and VHDL "cores" too. Should this discussion continue on comp.arch.fpga ?
> You need to find yourself an eval board with SDRAM already.
I have one that has what looks like a SODIMM socket, but it's an Altera thing for which I have no programming cable or software suite :-/ Furthermore, I believe that since I'll have to use SDRAM anyway one day, then I should hit the bullet and go forward.
> Regards,
thanks, yg -- http://ygdes.com / http://yasep.org
On Jan 21, 4:38=A0pm, whygee <why...@yg.yg> wrote:
> Mark McDougall wrote: > ....... > > Also, with a 133MHz > > clock you need to match trace length/impedence on all the pins from FPG=
A
> > to SDRAM. That just ain't going to happen with a 'old hack [job]'. > > hmmmm If I cut a bunch of same-length wires, a la Cray-1, > that could maybe help... (kidding) > > Fortunately, the eval boards have rather short traces to the headers > so impedence will not be a big problem (I hope).
You will not need to match lengths at 133 MHz that much, 10-20 mm won't make any difference (just do the math). However, not having a ground plane to reference the signals to may well become an issue. Since this is a one-off thing (I suppose you do not intend to hand- wire them DDRAMs in mass-production :-) ), you may be better off if you explore and cut a piece (literally) from a DDRAM DIMM, some do use DDRAMs with 16 bits of data (this means you can have 32 or 64M maximum depending on which parts you use). Now how you connect this piece of board to the other still remains unclear, of course; using many evenly spread GND wires between the two might help, but you won't know if it will work until it works... Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Original message: http://groups.google.com/group/comp.arch.embedded/msg/1fb= 098552def8cbd?dmode=3Dsource
On Jan 21, 9:38=A0am, whygee <why...@yg.yg> wrote:
> Mark McDougall wrote: > > whygee wrote: > >> Is there another method ? > > > I'm afraid you're not going to be able to (easily) achieve what you wan=
t.
> > That's what I thought... > > > First off, you'd need to clock the SDRAM with the output of a PLL, so t=
hat
> > you can control the skew wrt the control/data lines. > > I think that it is possible with the FPGA that I use (Actel ProASIC3), > I have spotted functionalities of the IO pads that ease these designs. > They have things like programmable delays and skews to avoid driver conte=
ntion
> on bidirectional buses for example.
Have you considered a different family? There is a $40 Xilinx eval board available from Avnet. But it still does not have ram. That will likely be a $200 or higher board.
> > Also, with a 133MHz > > clock you need to match trace length/impedence on all the pins from FPG=
A
> > to SDRAM. That just ain't going to happen with a 'old hack [job]'. > > hmmmm If I cut a bunch of same-length wires, a la Cray-1, > that could maybe help... (kidding)
The only hard part is the wiring. A decoupling cap will need to be wired directly between the power and ground pins. Actually, this may be a show stopper. The low impedance of the ground plane and its capacitance helps a lot to reduce the high freq spikes on the power bus. By wiring power it is possible to add too much inductance and the cap may not be able to provide a low enough impedance. As long as your wires are very short (both on board and off board), less than 2" for example, the SI and clock timing will not be significant issues. To mitigate the output delays on the FPGA you should register all signals in the IOBs.
> Fortunately, the eval boards have rather short traces to the headers > so impedence will not be a big problem (I hope). > > Also my designs don't clock faster than 100MHz, and I thought > that it's possible to downclock SDRAM chips, provided the cycles > are adjusted.
That will work. You can clock an SDRAM as slow as you want to some point. You do have to provide a periodic refresh cycle unless you are doing that in software. But the clock speed won't have much to do with the SI and power decoupling issues.
> > You also need an SDRAM controller inside the FPGA, parameterised to you=
r
> > particular SDRAM chips. > > Sure, I'm looking at datasheets and VHDL "cores" too. > > Should this discussion continue on comp.arch.fpga ?
That would be a good venue. I have not found a good venue for discussing FPGA CPU cores. If you are interested in MISC processors, comp.lang.forth is a good place.
> > You need to find yourself an eval board with SDRAM already. > > I have one that has what looks like a SODIMM socket, > but it's an Altera thing for which I have no programming cable > or software suite :-/ > > Furthermore, I believe that since I'll have to use SDRAM anyway > one day, then I should hit the bullet and go forward.
You can get the Altera softare for free just like the Xilinx software. The programming cable is not a lot of money. I would bite the bullet and use that for a first pass. Wiring an SDRAM chip is likely to delay you some considerable time. Rick
whygee wrote:
> Mark McDougall wrote: >
... snip ...
> >> Also, with a 133MHz clock you need to match trace length/impedence >> on all the pins from FPGA to SDRAM. That just ain't going to >> happen with a 'old hack [job]'. > > hmmmm If I cut a bunch of same-length wires, a la Cray-1, that > could maybe help... (kidding) > > Fortunately, the eval boards have rather short traces to the > headers so impedence will not be a big problem (I hope). > > Also my designs don't clock faster than 100MHz, and I thought that > it's possible to downclock SDRAM chips, provided the cycles are > adjusted.
To evaluate the effects of wire length, consider that 1 foot (1/3 meter) of wire represents about 1 nS in a vacuum. Probably closer to 2 nS in your environment. 100 MHz chips are cycling in no more than 10 nS. Also bear in mind that you have to provide the appropriate signals and addresses to refresh the memory at some interval. See the data sheets for this. The circuitry is a complication, not present in static memory chips. The variation in delays through this circuitry also need to get absorbed in that 10 nS window. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.
On Jan 21, 6:20 am, whygee <why...@yg.yg> wrote:
> Mark McDougall wrote: > > Alternatively, you could find some other high-density (non synchronous?) > > memory technology... not up on these sorry. Anyone else? > > The best I have is 4MB of static RAM, which is already large > (and some room too, with two DIP40 packages, and time, > since it's 70ns access time) but won't buffer enough data...
There are 10 to 20ns sram in TSOP, and faster if you pay more. 16 chips in a small PCB is not impractical. Not using PCB at all is impractical.
> > > Regards, > > thanks, > > yg > > --http://ygdes.com/http://yasep.org
Didi wrote:

> You will not need to match lengths at 133 MHz that much, 10-20 mm won't > make any difference (just do the math).
As long as the trace lengths from the FPGA to the expansion header are also taken into account... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

The 2024 Embedded Online Conference