From: Symon on
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!
From: radarman on
On Mar 28, 2:38 pm, Symon <symon_bre...(a)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.
From: Symon on
On 3/29/2010 3:56 PM, radarman wrote:
> On Mar 28, 2:38 pm, Symon<symon_bre...(a)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
From: Ed McGettigan on
On Mar 28, 2:42 pm, Symon <symon_bre...(a)hotmail.com> wrote:
> On 3/28/2010 10:28 PM, John_H wrote:
>
>
>
>
>
> > On Mar 28, 3:38 pm, Symon<symon_bre...(a)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.- 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 = 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.
From: radarman on
On Mar 29, 10:38 am, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote:
> On Mar 28, 2:42 pm, Symon <symon_bre...(a)hotmail.com> wrote:
>
>
>
> > On 3/28/2010 10:28 PM, John_H wrote:
>
> > > On Mar 28, 3:38 pm, Symon<symon_bre...(a)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.- 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 = 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.

Altera has a page with the relevant data as well:

http://www.altera.com/technology/signal/board-design-guidelines/sgl-bdg-index.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.