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

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, 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.

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 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 29, 10:38=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Mar 28, 2:42=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
>
>
> > On 3/28/2010 10:28 PM, John_H wrote:
>
> > > On Mar 28, 3:38 pm, Symon<symon_bre...@hotmail.com> =A0wrote:
> > >> On 3/26/2010 9:13 PM, radarman wrote:
>
> > >>> I've only done one other "high speed" design, with a Gig-E PHY, but=
 I
> > >>> was able to get all of the signals to within +/- 5 mils on that boa=
rd.
>
> > >> When you did this, you took into account the different flight times =
in
> > >> the packages themselves, I hope! For sure the leadframes don't have
> > >> matched lengths on the signals from the die to the PCB pad.
>
> > >> In summary, what the other guys said, 6 inches a ns!
>
> > >> Cheers, Syms.
>
> > > The flight times in the package shouldn't hit the timing budget at
> > > all. =A0The timing for both the SRAM and FPGA will be worst case for =
any
> > > pin. =A0And what's a few 10s of picoseconds?
>
> > Well, I agree, but did you read his post? He's making trace lengths
> > match to within 5 mils! That's what I'm trying to suggest may be a wast=
e
> > of effort.
>
> > Cheers, Syms.
>
> > p.s. FWIW, you can get the flight times of BGA packages from Xilinx, if
> > you ask nicely.- Hide quoted text -
>
> > - Show quoted text -
>
> You don't need to ask Xilinx for this information for the flipchip
> packages because it is available from the ISE partgen tool.
>
> Example: partgen -v xc6slx240tff1156
>
> This command will generate a PKG file that includes the tracelength in
> um (microns). Where 1000 microns =3D 1.0 mm. =A0Multiplying the trace
> length by 6.0-7.1ps/mm will give the flight time within the package.
>
> Ed McGettigan
> --
> Xilinx Inc.

Altera has a page with the relevant data as well:

http://www.altera.com/technology/signal/board-design-guidelines/sgl-bdg-ind=
ex.html

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.

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.

On Mar 28, 2:42=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> On 3/28/2010 10:28 PM, John_H wrote:
>
>
>
>
>
> > On Mar 28, 3:38 pm, Symon<symon_bre...@hotmail.com> =A0wrote:
> >> On 3/26/2010 9:13 PM, radarman wrote:
>
> >>> I've only done one other "high speed" design, with a Gig-E PHY, but I
> >>> was able to get all of the signals to within +/- 5 mils on that board=
.
>
> >> When you did this, you took into account the different flight times in
> >> the packages themselves, I hope! For sure the leadframes don't have
> >> matched lengths on the signals from the die to the PCB pad.
>
> >> In summary, what the other guys said, 6 inches a ns!
>
> >> Cheers, Syms.
>
> > The flight times in the package shouldn't hit the timing budget at
> > all. =A0The timing for both the SRAM and FPGA will be worst case for an=
y
> > pin. =A0And what's a few 10s of picoseconds?
>
> Well, I agree, but did you read his post? He's making trace lengths
> match to within 5 mils! That's what I'm trying to suggest may be a waste
> of effort.
>
> Cheers, Syms.
>
> p.s. FWIW, you can get the flight times of BGA packages from Xilinx, if
> you ask nicely.- Hide quoted text -
>
> - Show quoted text -

You don't need to ask Xilinx for this information for the flipchip
packages because it is available from the ISE partgen tool.

Example: partgen -v xc6slx240tff1156

This command will generate a PKG file that includes the tracelength in
um (microns). Where 1000 microns =3D 1.0 mm.  Multiplying the trace
length by 6.0-7.1ps/mm will give the flight time within the package.

Ed McGettigan
--
Xilinx Inc.

On 3/29/2010 3:56 PM, radarman wrote:
> On Mar 28, 2:38 pm, Symon<symon_bre...@hotmail.com>  wrote:
>> On 3/26/2010 9:13 PM, radarman wrote:
>>
>>
>>
>>> I've only done one other "high speed" design, with a Gig-E PHY, but I
>>> was able to get all of the signals to within +/- 5 mils on that board.
>>
>> When you did this, you took into account the different flight times in
>> the packages themselves, I hope! For sure the leadframes don't have
>> matched lengths on the signals from the die to the PCB pad.
>>
>
> No, because I wasn't aware that the internal wire bond lengths would
> be that dramatically different in a QFP. Those are big packages, and I
> had assumed that all of the wire bond points on the die would be
> around the periphery of the die. I've seen x-ray images of QFP's in
> the past, and the bond wires looked pretty much like you would expect
> - end launched from the die to an internal ring.
>


http://commons.wikimedia.org/wiki/File:TQFP_Leadframe.jpg

On Mar 28, 2:38=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> On 3/26/2010 9:13 PM, radarman wrote:
>
>
>
> > I've only done one other "high speed" design, with a Gig-E PHY, but I
> > was able to get all of the signals to within +/- 5 mils on that board.
>
> When you did this, you took into account the different flight times in
> the packages themselves, I hope! For sure the leadframes don't have
> matched lengths on the signals from the die to the PCB pad.
>
> In summary, what the other guys said, 6 inches a ns!
>
> Cheers, Syms.

No, because I wasn't aware that the internal wire bond lengths would
be that dramatically different in a QFP. Those are big packages, and I
had assumed that all of the wire bond points on the die would be
around the periphery of the die. I've seen x-ray images of QFP's in
the past, and the bond wires looked pretty much like you would expect
- end launched from the die to an internal ring.

Thus, I figured that it would be sufficient to make sure all the
critical signals in a bundle were in the same bank, and on the same
physical side. For that design, I used an EP3C16E144C7, and the GMII
port fit nicely along one side in banks 7 and 8. If the pin pitch had
been the same on both parts, it would have looked like a straight bus
between the two chips.