Spartan3 PCI SSO(Simultaneously Switching Output) problem

I opened a case with this issue just a couple days ago. I'll post here if I get results. The bottom line: we have two solid designs (one shipping, the other ready to go) that have XC3S400-5PQG208C devices using PCI-66 without performance issues. I inherited the PQ208 package when the board designer insisted this was *the* part to use rather than the more SI-friendly FG256 since the price is based on multiple, existing projects. While trying to track down what I thought might be a bug, I found the SSO guidelines you found.

Bottom line: I think those numbers are conservative to the point of laughter. We have the two designs I know of working beautifully and the bug in my own design may not be a hardware issue at all, providing solid performance for the testing I've done there as well. PCI should work but the SSO recommendations say there's not a chance in San Jose.

- John_H

Thanks for John_H 's replay ! I will continue use spartan3 since your boards can run well. Any one know how Xilinx calclate the SSO number ? Use the following formula ? Vgnd = L * 1.52* deltaV *C / (( T(10%-90%))^2) ? I found this in book (Section 2.4.1.4 ). Xilinx may be use it because this formula is linear for L and C that mentioned in xapp689 by xilinx. When I read xapp689, I thought Xilinx maybe make some mistake in calclating SSO number for PCI because PCI has no capacitance load while they use capacitance. There perhaps some other mistake in calculate the SSO number . Because the higher package inductance the slower ouput. So package inductance is not the most significant factor . Though I write these and post it , I am not know if it is right .

Thanks to anyone for any words!

Anyone bothered to do a simulation?

IBIS, or hspice?

Flying or driving blind is not recommended.

Back of envelope calculations are worthless.

Aust> Thanks for John_H 's replay !

The Xilinx application notes that IBIS files and IBIS derived results UNDER NO CIRCUMSTANCES will produce SSO information because there is no modeling of the chip's power and ground distribution.

Do we have spice models available to us that *do* provide power/ground modeling?

We were only flying blind for the first year or so before Xilinx started publishing numbers for the package and for the I/O standard that were absent in several early generations of the datasheet. We worked closely with our Xilinx FAE to develop a reasonable pinout for the PQ208 package. There were no warnings along the way that the PCI SSO limits would be 2 pins per bank for a 50 pin interface. I believe our first PCI/PQ208 design was shipping before the information first appeared in a datasheet. Mine is the 4th internal PCI design in this package that I know of and the Spartan3 is becoming "mature" for the typical design issues associated with a part.

My case # is 597160 if you'd like to track down the active case to see what's going on.

We're working with about 20 SSOs possible per bank rather than the 2 that are given by the guideline. Is this 10:1 difference expected in the SSO guidelines?

John_h Wrote "My case # is 597160 if you'd like to track down the active case to see what's going on". Where to find more information about case # 597160 ?

Login, and find out what the case notes are.

Who is handling it, and what they know so far.

You can get in there, and EDIT it, and add information to your case!

You can be in control and "drive" the support!

Go for it!

Aust> John_h Wrote "My case # is 597160 if you'd like to track down the

My apologies - the case number was primarily for Austin's use if he wanted to see the traffic in the AE group about what has transpired so far. I don't know that the case can be accessed through mysupport by those who didn't submit the case.

Hi Austin , Is Xilinx doing more work on this ? Hi All ! I did a simulation use HyperLynx. Below is the circuit:

PCI-Driver -------- 15 nH Inductor -------7.6cm,88.5ohms,447ps transmission line ----

---PCI Receiver ------- 7.6cm,88.5ohms,447ps transmission line ---PCI Receiver.

PCI receiver use xc2s200-pq208 PCI33M 5V I think voltage across the Inductor is crossed by ground bounce . Result: When PCI-Driver use xc3s200-pq208 PCI33-3, the max voltage is 490mV. When PCI-Driver use xc2s200-pq208 PCI33M5V, the max voltage is 370mV. Question: This result accords with spartan3-SSO guidelines ( SSO number is 1 for PQ208 ), but not accords with spartan2(SSO number is 4 for PQ208). And my xc2s200-pq208 board works well . Why ?

Hi John! Since you have workable 3s pq208 board , I have a method to test the ground bounce rather than simulation.Below is how :

1. Assert pci REQ signal ,request bus.
2. Wait until GNT asserted .
3. Generate an reserved PCI command, assert FRAME.Sine all pci device will ignore reserved pci command,we are safe to driver the bus arbitrarily.
4. While keep FRAME asserted, continuous change pci all signals (all

1. Route the "unchanged" signal to a counter's clk pin or enable pin in fpga, watch the counter . Or
2. Use oscilloscope whatch and measure the unchanged signal.
3. When all done , deassert PCI FRAME.

I think doing this can get more than simulation. If you alse think this a good idea , since this can be done without change hardware ,can you do it and post the result ? BTW, did you get more information from XILINX ?

John, Sorry for I forgot this :

1. Can observ ground bounce by : a) Use one board to watch effect of ground bounce on input . b) Use two or more board to watch effect of ground bounce on output. c) Route the ground bounce effected signal to counter's clk pin to watch any voltage change ,to counter's enable pin to watch effect in a clock system.

When we worked with one of our leading networking clients last year, they identified Xilinx WASSO (weighted avg SSO) calcs as being "necessary but not sufficient" for project success, and asked us to do something about making it easier to calculate. After our client runs WASSO, they still do a *detailed* SI analysis - but will not invest the time doing so until the WASSO numbers are OK. They even "derate" the passing WASSO levels further. While this may be extra-conservative, their revenues and margins indicate they are doing a lot right :-)

We have since integrated WASSO calculations into the latest release of DesignF/X Pin Assignment (DPA), with lots of inputs from users and Xilinx FAEs, on a number of other features as well. (Disclosure: DPA is available only for Xilinx FPGAs at this time, and our company is a Xilinx EDA Alliance Partner.)

Of interest to this group and this thread in particular is that DPA is free to use for under 600 pins, WASSO setup is easy, and calculations are updated as pin assignment progresses, along with IO standard assignment, etc. You can download DPA from our website at

Good luck in all your projects!

Manu Pillai