FPGARelated.com
Forums

spartan 3 on 4 layers

Started by colin October 13, 2004

Symon wrote:

(snip regarding decreasing inductance by thicker ground planes)

> I just realised, making it thicker will only reduce its
> resistance. Its inductance won't change. The inductance > is determined by the loop area of the current path. > Think about it, when you calculate the inductance of a
> coil, you don't need to know the wire diameter, just the
> diameter and number of turns. The coil formula doesn't work so well for a ground plane, but I do think you are right. The volume occupied by flux is staying (about) the same. As a coil is stretched into a straight wire its inducance decreases. Then, as the wire gets larger it also decreases but that is because the field spread out more. I think, though, that more vias still decreases the inductance until they get so close that there is a large field overlap bewteen them. -- glen
> SSO guidelines are on page 23 of: > http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf
No data for PQ-208. No data for PCI33_2 or PCI66_3. (Page 25.) There is a note at the end of the table that says: The numbers in this table are recommendations that assume sound board layout practice. But that's hard to test or measure. I'm not trying to pick on Xilinx. Most data sheets I look at don't even have that sort of footnote. But this is a hard problem area. How good does "sound board layout" have to be? How/what would you specify if you were writing the data sheet? If you were on a jury for a big legal battle, how would you decide if a design was "sound" enough? Anybody got PCI running on a PQ-208 with only 4 layers? :) Is that a silly idea? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:cl44k8$1qu$1@gnus01.u.washington.edu...
> I think, though, that more vias still decreases the > inductance until they get so close that there is a > large field overlap bewteen them.
Agreed, as you said earlier "Inductors in parallel". The current is shared between the vias. I think you're right about the total inductance increasing as the two (say) vias get close as well, food for thought. Is that because of the mutual inductance between the two current loops? Time to crack out a text book! An interesting discussion, thanks Glen! Best, Syms.
Symon wrote:

< re. the missing leaded package SSO data >
> >That's because the lead frame has buggered your SI before >you've even started your PCB. >
Yes, and the poorer on-die power distribution of those same leadframes makes adhering to those (missing) SSO guidelines even more important than in the BGA parts.
> >The idea is that if the voltage mode drivers switch >simultaneously in opposite directions, the current through >the Vcco pins stays constant, so the lead/trace inductance >doesn't screw things up. >
Xilinx has two flavors of differential driver: 1) the older style, voltage-mode, pseudo-differential, switch-two-CMOS-outputs-with-an-external-resistive-attenuator which they say doesn't balance that well : http://www.fpga-faq.com/archives/42700.html#42709 2) the 'real' balanced current-mode drivers of the V2/V2P/S3, which the Answer Records say is not a factor in SSO limits So, I'd expected to see much better SSO numbers for the 'real' LVDS drivers than for the older 'pretend' ones, but DS099, table 23, says both types have a four-pair SSO limit per VCCO-GND pair. Brian
Austin wrote:
> >LVDS is a low current driver, but the LVPECL is two single >ended drivers with external resistors, so it has significant current. > >Even LVDS has a restriction, but not nearly that of a >larger driver (more current). Unless I am missing something? >
I'd also expected to see much better numbers for the current-mode drivers, but the Spartan3 SSO table that you referenced says otherwise: Excerpts from DS099-3, v1.4, Table 23 SSO outputs per VCCO/GND pair Single ended: LVCMOS33 Fast 16mA 7 pins LVCMOS33 Fast 24mA 3 pins Current-mode: LVDS_25 4 pairs (8 pins) RSDS_25 4 pairs Psuedo-differential: BLVDS_25 4 pairs LVPECL_25 4 pairs Which lists the current mode LVDS drivers as having the same low SSO pin limit (4 pairs) as the LVPECL drivers, and pretty much the same pin limit as does LVCMOS33/FAST/16mA.
> >> >> 3) Why do the input-only differential parallel DCI standards >> show up in the SSO table? > >Because they draw current for the parallel termiantion, and the >restriction is for current drain on the Vcco/Gnd pins in the bank. >
I'd hoped that was the reason; but since those same "4"'s were next to every type of differential I/O in the table, I thought it might be a block pasting error when compiling the datasheet. Following up on this: In "normal" operation, these on-chip DCI terminator pairs have already been biased to 1.25 V, and experience a small balanced input swing (~0.8V), providing some measure of terminator VCCO current cancellation. In this "normal" mode of operation, in the BGA packages, they have a four pair SSO limit, possibly less for leaded parts. But at post-configuration DCI startup, these terminators all switch simultaneously, unbalanced, from full stop to 1.25 V Given that this unbalanced, larger swing should have poorer SSO limits than the "normal" operation, that's why I was concerned over on that other thread about using LVDS_25_DCI in the leaded packages. Brian
"Brian Davis" <brimdavis@aol.com> wrote in message 
news:a528ffe0.0410191907.7dea9fd4@posting.google.com...
> Symon wrote: > > < re. the missing leaded package SSO data > >> >>That's because the lead frame has buggered your SI before >>you've even started your PCB. >> > > Yes, and the poorer on-die power distribution of those > same leadframes makes adhering to those (missing) SSO > guidelines even more important than in the BGA parts. >
V. good point. I wonder, do the IBIS models include the lead frame?
>> >>The idea is that if the voltage mode drivers switch >>simultaneously in opposite directions, the current through >>the Vcco pins stays constant, so the lead/trace inductance >>doesn't screw things up. >> > > Xilinx has two flavors of differential driver: > > 1) the older style, voltage-mode, pseudo-differential, > switch-two-CMOS-outputs-with-an-external-resistive-attenuator > > which they say doesn't balance that well : > http://www.fpga-faq.com/archives/42700.html#42709 > > 2) the 'real' balanced current-mode drivers of the V2/V2P/S3, > which the Answer Records say is not a factor in SSO limits > > So, I'd expected to see much better SSO numbers for the 'real' > LVDS drivers than for the older 'pretend' ones, but DS099, table 23, > says both types have a four-pair SSO limit per VCCO-GND pair. > > > Brian
I got the difference between the two types, but failed to realise that they didn't balance so well. Thanks for the link you posted to Bob and Austin's exchange, I'm thinking again. I guess I'm very cynical, I think the "25 ps to 125 ps" time from the pad to the pin is a red herring. The synchronicity of the IOBs outputs switching on the die is what's important. Maybe the 'gate' or drive capacitance of the output transistors added to the bounce? Maybe a tiny bit! I guess that leaves the crossover current, but how long does that last? I thought the output structure stopped that happening. CMOS, right? And how did they measure it? Hmmm! Cheers, Syms.
>That's because the lead frame has buggered your SI before you've even >started your PCB.
Then why does Xilinx sell the chips? They must be good for something. Maybe there is a comment in some ap-note that says not to bother trying to implement PCI in a PQ-208 type package. (and explaining why) Or maybe it takes 8 layers, or ... I haven't seen anything like that, but I haven't looked carefully and nobody has mentioned anything like that yet in this discussion. "Don't do that" might be the right answer. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
Symon wrote:
> >I wonder, do the IBIS models include the lead frame? >
AFAIK, IBIS modeling ignores ground bounce & such. Earlier versions of the S3 IBIS files used the SAME package model for ALL packages, from BGA through PQFP; the IBIS file had tiny entries for package parasitics, and Xilinx suggested a user-added Tline model to model the pin: uncoupled 65 ohm transmission line, 25-100 ps delay from : http://direct.xilinx.com/bvdocs/appnotes/xapp475.pdf Now, if what you're modeling is a transmission line, or behaves like one at the edge rates of interest, a Tline model is more appropriate than a single element lumped approximation; but to model a conventional leadframe package with an UNCOUPLED** Tline model seems rather optimistic. Looking again today, the latest version (2.6) of the S3 IBIS files now has lumped parasitics for some of the leaded packages ( PQ208 and TQFP144, but not the VQ100 ). Note: XAPP475 has not yet been updated to address this modeling change. The other concern I have with the Xilinx IBIS models is that they're still using an ancient version of IBIS (2.1), which doesn't support some of the newer IBIS features such as differential input parasitics. ( Which explains the lack of IBIS models for the _DT terminators in the V2Pro ) ** I don't believe IBIS 2.1 supports modeling of pin-pin coupling Brian
"Brian Davis" <brimdavis@aol.com> wrote in message
news:a528ffe0.0410200342.638dedb0@posting.google.com...
<snipped very informative stuff>
> > The other concern I have with the Xilinx IBIS models is > that they're still using an ancient version of IBIS (2.1), > which doesn't support some of the newer IBIS features such > as differential input parasitics. ( Which explains the lack > of IBIS models for the _DT terminators in the V2Pro )
I see in XAPP475 they say that "Unfortunately, IBIS 3.2 still is not widely supported by simulators.". It wouldn't hurt to publish new IBIS3.2 or even 4.0 files alongside the old ones though! Thanks for a very informative post, much appreciated. Best, Syms.
All,

IBIS 4.0 is now out for bid for the "golden parser."

Without a "golden parser", no one can say they adhere to the standard.

The last golden parser was back in the IBIS 1.2 days, so that is all 
anyone can lay claim to.

If you claim something more than that, you are not being entirely 
honest.  Small errors in the IBIS file get rejected by various tools, 
and support mushrooms.

As well, not everyone implemented the changes in IBIS 2, 3.... the same 
way, or the simulators implementations were also not identical....

We have 200,000+ seats of software out there, and trying to blaze a new 
trail for IBIS is like pushing tons of wet spaghetti (hard work, and not 
very satisfying).

We are actively looking at when to fold in the new IBIS, but only after 
it is supported by the tools that allow us to succeed.  Until then, we 
use what we have got, which includes the encrypted hspice versions for 
folks that have to have the "answer."

For the MGTs, no one can say if IBIS is adequate or not for differential 
signals at 10 Gbs, so we are sticking to methods that we know work.  We 
do know that behavioral models are really fast, but also really 
inaccurate.  If someone has a complete backplane simulation with 
extracted pcb parasitics (s parameters, complex lossy t-lines, 
connectors, pre-emphasis transmitter and adaptive receiver, etc.) that 
is within 5% of the behavioral model, I'd like to know how the miracle 
occurred.

Austin