I'll second that. Check your PERR#, SERR#, and especially, FRAME# = signal. The last one can tell you which transaction phase your bus is in. When FRAME# signal is asserted, the address phase sets in (one clock = cycle). The address phase is followed by the attribute phase (one clock cycle), and then you get the idle clock cycle, which is followed by the data = cycle. In this idle clock cycle the data noise should not matter. I am not sure but there might be another idle clock cycle after the data = phase. I once saw a terrible PCI-X data ringing which I attributed to gnd = bounce partly because the chip was significantly underdecoupled and also because it occurred = only with the large amount of data traffic sent over the bus (hence SSN). No amount of the decoupling helped. And then the chip vendor pointed me to the idle clock cycle:) Still I don't understand why some busses show it and some not. Is it because of the missing bus keepers? Is it some kind of = metastability? From reading the PCI-X spec I've got an impression that the bus keepers = should be designed properly to prevent the bus from "ringing" while tri-stating. -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Grist, Robert Sent: Wednesday, October 15, 2003 7:58 AM To: gedlund@xxxxxxxxxx; swldstn@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: PCI and PCI-X bus noise Also make sure you are not viewing signal conditions during tri-state conditions. Noise during this time is not important. -----Original Message----- From: Gregory R Edlund [mailto:gedlund@xxxxxxxxxx] Sent: Wednesday, October 15, 2003 10:03 AM To: swldstn@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: PCI and PCI-X bus noise Steve, I applaud your efforts in making quiet line measurements on PCI/X. This is an important part of the SI verification process but a difficult one because you need to have control over bus patterns, be able to trigger on the pattern of interest, and verify the switching state of the neighboring lines. In my opinion, it's well worth the effort to isolate crosstalk and SSN from reflections as much as possible. Do this by switching only one bit on the bus (reflection), all bits (SSN), and a small number of aggressors around your quiet line (crosstalk). The other thing that you can do to determine whether or not you're in trouble is to attempt to place the noise events in time relative to the input clock at the receiver chip. You will need to scope both the quiet line and the clock as close to the die pad as possible. Construct a setup and hold window around the clock using what you know about clock skew and the PCI/X timing specs. Do your noise events fall within this window? What if your drive chip speeds up or slows down? I see from my (old) copy of the PCI-X spec that you have 825 mV of noise margin to work with on the low level, assuming Vcc =3D3D 3.3 V. They = =3D break out reflections, crosstalk, and input reference offset but not SSN. I guess I would have broken out crosstalk, SSN, and input reference offset and left reflections as part of propagation delay. At any rate, you'll need to look at your 1.2 V and determine how much of it is crosstalk and SSN that can occur inside the setup and hold window. Greg Edlund Senior Engineer Signal Integrity IBM Engineering and Technology Services 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@xxxxxxxxxx Msg: #11 in digest Date: Tue, 14 Oct 2003 13:49:36 -0400 From: swldstn@xxxxxxxxxxxx Subject: [SI-LIST] PCI and PCI-X bus noise To all, In doing some targeted simultaneous switching noise data patterns on a PCI and PCI-X bus we see total noise of between 0.5 to 1.2 volts depending on bus configurations. This voltage is the sum of ground bounce ringback, reflections, etc when looking at a quiet high or low pin. At this time its hard to separate out the source of the noise. The device under test is part we have designed. Is anyone willing to share their experience or point me to some published information on PCI and PCI/X? Any help is appreciated. Thanks in advance. Steve Waldstein swldstn@xxxxxxxxxxxx ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: =3D20 //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages=3D20 Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu =3D20 ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: =20 //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages=20 Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu =20 ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu