PCB routing issues for sync SRAM

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.

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.
Having a series resistor could help the transmitter avoid too much of
a surge.  The termination at the final destination is the classical
version, however.  Having room for both can help, perhaps more than
hinder.

On Mar 28, 3: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.

The flight times in the package shouldn't hit the timing budget at
all.  The timing for both the SRAM and FPGA will be worst case for any
pin.  And what's a few 10s of picoseconds?

On 3/28/2010 10:28 PM, John_H wrote:
> On Mar 28, 3: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.
>>
>> 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.  The timing for both the SRAM and FPGA will be worst case for any
> pin.  And 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.

On Mar 28, 5:42=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
> 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.

I missed that.  My recollection was the lengths were varied between
250 and 750 mils and he hadn't changed that decision yet.  I need to
pay more attention, I guess.

TIMING BUDGET !!!!

I had an engineer at my previous place of employ who quite literally
"broke" a layout person with the outrageous constraints for the DDR2,
mostly waaaay too tight and sometimes conflicting.

Do the budget, know the needs, plan the clock, open your windows.

On 3/29/2010 5:03 AM, John_H wrote:
>
> TIMING BUDGET !!!!
>
> I had an engineer at my previous place of employ who quite literally
> "broke" a layout person with the outrageous constraints for the DDR2,
> mostly waaaay too tight and sometimes conflicting.
>
> Do the budget, know the needs, plan the clock, open your windows.

Amen!

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.

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