PCB routing issues for sync SRAM

On 3/29/2010 5:09 PM, radarman wrote:
>
> Apparently I was wrong, there is a small, but significant, difference
> between pins even on the same physical side of the chip. I also failed
> to notice that Vref pins used as I/O affect timing.
>
Well, kinda. I would say that there is a small and (almost always) 
negligible difference between the pins' flight time. The fact that only 
Xilinx Ed pointed out where to find the flight times indicates that very 
few posters on CAF have ever worried about them. Similarly, small 
differences on the PCB are also insignificant, and trying to eliminate 
them is an unnecessary task. FWIW, with QFPs you will never have to 
worry about these data, as the packages are rubbish for high-speed signals.

> However, the whole point of this exercise was to learn, and I'm doing
> plenty of that. Perhaps it's time to throw together a spreadsheet with
> all the timing figure in it, and do a proper budget.

Right, you'll get no disagreement from me on that one. From that, you 
will be able to judge how much length matching effort you need to do on 
your PCB.

Cheers, Syms.

On Mar 28, 5:27=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Mar 28, 1:22=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:

> > If you're going to feed the clock back, then you'll want to parallel
> > terminate to ground rather than series terminate at the source.
>
> I figured the external lines are small enough that the transmission
> line characteristics are no longer as important as the lumped model.

Depends on the edge rates...but likely true that no termination might
be needed.  The point is to add one resistor as insurance against a
nasty surprise on an unexpectedly high edge rate.

> Having a series resistor could help the transmitter avoid too much of
> a surge.

If you're talking abou the 'surge' from when the I/O switches, then
series termination causes the large surge, parallel termination has
much smaller AC current changes.

> =A0The termination at the final destination is the classical
> version, however. =A0Having room for both can help, perhaps more than
> hinder.

Ummm...nothing 'classical' about it.  If you have a multi-drop net and
you need clean edges at each load, you don't use series termination,
you use parallel.

If you have a driver that can't provide a clean incident wave
switching edge into the PCB then you need to rethink having a multi-
drop net, go back to having one load and then series terminate...in
the radarman's case, that would mean not feeding back the SRAM clock
back to the FPGA.

Kevin Jennings

On Mar 29, 8:31=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Mar 28, 5:27=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>
> > On Mar 28, 1:22=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> > > If you're going to feed the clock back, then you'll want to parallel
> > > terminate to ground rather than series terminate at the source.
>
> > I figured the external lines are small enough that the transmission
> > line characteristics are no longer as important as the lumped model.
>
> Depends on the edge rates...but likely true that no termination might
> be needed. =A0The point is to add one resistor as insurance against a
> nasty surprise on an unexpectedly high edge rate.
>
> > Having a series resistor could help the transmitter avoid too much of
> > a surge.
>
> If you're talking abou the 'surge' from when the I/O switches, then
> series termination causes the large surge, parallel termination has
> much smaller AC current changes.
>
> > =A0The termination at the final destination is the classical
> > version, however. =A0Having room for both can help, perhaps more than
> > hinder.
>
> Ummm...nothing 'classical' about it. =A0If you have a multi-drop net and
> you need clean edges at each load, you don't use series termination,
> you use parallel.
>
> If you have a driver that can't provide a clean incident wave
> switching edge into the PCB then you need to rethink having a multi-
> drop net, go back to having one load and then series terminate...in
> the radarman's case, that would mean not feeding back the SRAM clock
> back to the FPGA.
>
> Kevin Jennings

Kevin, you're turning my stomach in knots here.  You're regurgitating
transmission line theory quoting "edge rates" without apparent
consideration for the extremely minute distances involved.  At 250-750
mil, you will NOT see a classic step, reflect, step kind of response.

And when's the last time you really fixed a signal by capacitively
loading it?  Your suggestion that lightening the driver's load with a
series resistor (hence, reducing initial overshoot that I've seen on
the scope in many families) exacerbates the problem is downright
ludicrous.

Please stop parroting what you heard in transmission line theory; it's
good stuff but it doesn't apply for these flight times with the SSTL
drivers involved.  Take some time and check out the signal fidelity on
boards with various terminations with a high end scope or run some
IBIS simulations to see what really happens when traces become lumped
elements rather than transmission lines.

As others have said you at least need to have series termination on your
clock, unless you're bringing it back to the FPGA then parallel terminate it
at the end.

CycloneIII s have on chip termination which you could try using for this, but
this only has two settings, 25R and 50R so if you need to tweak values you're
stuffed (although you can add an external resistor to set the termination
value).

I'd play safe and add an external resistor.



Nial. 

On Mar 29, 11:47=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Mar 29, 8:31=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:

>
> Kevin, you're turning my stomach in knots here. =A0You're regurgitating
> transmission line theory quoting "edge rates" without apparent
> consideration for the extremely minute distances involved. =A0At 250-750
> mil, you will NOT see a classic step, reflect, step kind of response.
>

I have considered the distances...and every post said that the
termination is probably not needed, but is cheap insurance if it turns
out to be needed for some unforeseen reason down the road.

> And when's the last time you really fixed a signal by capacitively
> loading it? =A0

Never...nor did I suggest it here.

> Your suggestion that lightening the driver's load with a
> series resistor (hence, reducing initial overshoot that I've seen on
> the scope in many families) exacerbates the problem is downright
> ludicrous.
>

Not my suggestion at all.  What I said was that you series terminate
when the load is at the end of a line; parallel terminate if you have
multiple loads along the line.  Radarman said he was going to
implement someone's suggestion to route the clock to the SRAM and then
feed it back to the FPGA...sounds like two loads to me, SRAM in the
middle, FPGA at the end.

> Please stop parroting <snip>

I don't parrot...I gave sound advice that you seem to have trouble
understanding.  I run the sims, make the measurements, add insurance
where necessary, been doing this successfully for a long time too.

Time to end this thread

Kevin Jennings