Spartan-3E SDRAM interface

I'm starting a design with an XC3S500E-4PQG208C and a 4M*32 SDR SDRAM
(Micron MT48LC4M32B2 or equivalent, TSOP package), using MicroBlaze
with the MPMC memory controller.

I'm concerned about signal integrity and SSOs.  Being on a shoestring
budget, I unfortunately don't have an IBIS simulator.

If I put the TSOP very close to the FPGA (QFP), and keep the trace lengths
short, is it plausible to get this to work?  Will fast outputs at 3.3V CMOS
with 2mA drive be satisfactory, or will higher drive be necessary (resulting
in more possible SSO problems)?

I picked SDR SDRAM on the assumption that I'd be opening an even bigger
can of worms with DDR or DDR2.  I'm using the QFP and TSOP rather than BGAs
to avoid having to pay big bucks to an assembly house to assemble the
prototypes.

Thanks for any advice!
Eric Smith

Eric

Sounds like you are applying a reasonable approach. SDR dram still has
it's place and you can see almost the same in our Darnaw (PGA FPGA)
product http://www.enterpoint.co.uk/moelbryn/darnaw1.html and soon to
be released Mulldonoch2. The only difference is we have the advantage
of using BGAs for the FPGA.

One thing to mention is that the PQ208 packages don't perform as well
as BGA in terms of SSO and hence ground/power bounce of signals. Try
and make decoupling and power structures as good as you can to
minimise the risk. You can also spread the I/Os but that will make
your routing much less optimal.

John Adair
Enterpoint Ltd.



On 17 Nov, 07:18, Eric Smith <e...@brouhaha.com> wrote:
> I'm starting a design with an XC3S500E-4PQG208C and a 4M*32 SDR SDRAM
> (Micron MT48LC4M32B2 or equivalent, TSOP package), using MicroBlaze
> with the MPMC memory controller.
>
> I'm concerned about signal integrity and SSOs. =A0Being on a shoestring
> budget, I unfortunately don't have an IBIS simulator.
>
> If I put the TSOP very close to the FPGA (QFP), and keep the trace length=
s
> short, is it plausible to get this to work? =A0Will fast outputs at 3.3V =
CMOS
> with 2mA drive be satisfactory, or will higher drive be necessary (result=
ing
> in more possible SSO problems)?
>
> I picked SDR SDRAM on the assumption that I'd be opening an even bigger
> can of worms with DDR or DDR2. =A0I'm using the QFP and TSOP rather than =
BGAs
> to avoid having to pay big bucks to an assembly house to assemble the
> prototypes.
>
> Thanks for any advice!
> Eric Smith

On Nov 17, 5:17=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> Eric
>
> Sounds like you are applying a reasonable approach. SDR dram still has
> it's place and you can see almost the same in our Darnaw (PGA FPGA)
> producthttp://www.enterpoint.co.uk/moelbryn/darnaw1.htmland soon to
> be released Mulldonoch2. The only difference is we have the advantage
> of using BGAs for the FPGA.
>
> One thing to mention is that the PQ208 packages don't perform as well
> as BGA in terms of SSO and hence ground/power bounce of signals. Try
> and make decoupling and power structures as good as you can to
> minimise the risk. You can also spread the I/Os but that will make
> your routing much less optimal.
>
> John Adair
> Enterpoint Ltd.
>
> On 17 Nov, 07:18, Eric Smith <e...@brouhaha.com> wrote:
>
> > I'm starting a design with an XC3S500E-4PQG208C and a 4M*32 SDR SDRAM
> > (Micron MT48LC4M32B2 or equivalent, TSOP package), using MicroBlaze
> > with the MPMC memory controller.
>
> > I'm concerned about signal integrity and SSOs. =A0Being on a shoestring
> > budget, I unfortunately don't have an IBIS simulator.
>
> > If I put the TSOP very close to the FPGA (QFP), and keep the trace leng=
ths
> > short, is it plausible to get this to work? =A0Will fast outputs at 3.3=
V CMOS
> > with 2mA drive be satisfactory, or will higher drive be necessary (resu=
lting
> > in more possible SSO problems)?
>
> > I picked SDR SDRAM on the assumption that I'd be opening an even bigger
> > can of worms with DDR or DDR2. =A0I'm using the QFP and TSOP rather tha=
n BGAs
> > to avoid having to pay big bucks to an assembly house to assemble the
> > prototypes.
>
> > Thanks for any advice!
> > Eric Smith

As mentioned, the PQ package is pretty bad for SSO, having the most
lead
inductance of all the package choices.  However it helps to sprinkle
virtual
ground pins among your package outputs.  Also, I'm not sure how fast
you're
trying to run the SDRAM, but you may get more help with SSO using slow
slew rate vs. lower output drive.  Unfortunately slow slew rate gives
a rather
large output delay compared to the fast slew rate.  Your SSO also
improves
with smaller load capacitance, so if you can use one 32-bit wide SDRAM
part instead of two 16-bit wide parts, you'd have half the address and
control line loading.  The by-32 parts come in TSOP as well, having
the
same overall dimensions but more finely spaced pins than the by-16's.
They tend to be a bit pricier, though and don't come in the largest
bit
density.