Scott - we may not be able to come to complete agreement as I believe we have two different world views. You see things from a system perspective, rightly so, and I can appreciate that. I see things from a silicon component perspective, after all I work for a component supplier. Let me tell a story that may clarify my position on SSN noise and load capacitors.. About 6 years ago when I joined my company, the FPGA industry was having terrible trouble with SSN. Some companies were a little ahead of the others in fixing the problems.. One of the things we needed to do was develop the measurement techniques to clearly tell us how much SSN we had. Characterization engineers were putting 5pF load caps at the end of the victim (quiet-low or quiet-high) transmission line for the measurement. I asked them why they did that and they said that the SSN "looked a lot better" with the load cap and that customers always have some amount of load capacitance. I asked them to remove the load cap for measurement and met with 'great resistance' because the SSN would look incredibly bad and they "did not want to measure bad data." I finally won that battle and we now measure SSN with as close to 50 Ohm termination as we can get. The load capacitor consumes the SSN glitch that begins at the FPGA BGA mount and travels to the far end of the line. The voltage across the capacitor is (1/C)*integral_i*dt. Imagine a the glitch in terms of a current waveform that is 200pSec wide (a little more than an inch) dumping into a load capacitor to charge it up. The noise voltage across the load capacitor goes as 1/C (inversely proportional to load capacitance). Modern receivers may have on the order of 0.5pF so a 5pF load diminishes the (apparently measured) SSN by a factor of 10. We were in denial about our SSN and were covering it up by assuming enormous load capacitance. The justification was that customers have load capacitance and we want to measure what the customer will see. I disagreed. With an FPGA that supports LVTTL, CMOS, SSTL, HSTL, class 1 & 2, and LVDS using the same silicon circuits and same package structures, there is absolutely no way we are going to measure what the customer is going to see for all types of busses. The best we can hope to do is to determine the SSN noise glitch that is launched into the victim transmission line and let the customers figure out for themselves what will be the system response to the SSN generated by the mounted FPGA. And that is what we do today. During product design, we choose ball definitions and return paths that will generate and acceptable amount of SSN as compared to the bus noise margin. We characterize the several different drive strengths and drive types and deliver this information to customers. We try our hardest to balance both cost and SSN performance in each of our product lines because customers will not like it if we stray too far either direction on that scale. There is no doubt that load capacitance reduces the SSN noise measured (seen by the receiver) at the far end of the line. It does not affect the properties of the initial glitch launched in the victim t-line. Nor does it affect near end SSN which was mentioned in your note. And yes, we do transmit and receive in the same IO bank at the same time so this is very much of an issue. The way that the system responds to the SSN glitch can only be evaluated with knowledge of the system. The best we can hope to do is keep the SSN glitch consistent with the expected cost and performance of the product. Well, this is just the perspective from one SI PI engineer in a component house.. Best regards, Larry Smith -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow Sent: Wednesday, August 03, 2011 11:25 AM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: SSO and load capacitance Larry I agree with most of what you say, however, I cannot agree with these two points: "To Scotts point, there is certainly a system level analysis to be done that includes the characteristics of the offending silicon as well as the rest of the system (package, PCB, traces, load, etc). But this is the system response to the SSN generated near the driver." "Going back to the original question on this thread, load capacitance at the far end of transmission line has no effect on the amount of SSN energy launched into a victim net from aggressor nets. The height of the SSN glitch seen at the victim receiver is actually reduced with more load capacitance. There are however system reflection issues that are generated by this load capacitance (non-perfect termination)." There are multiple concepts at work here. * SSO - the act of firing multiple drivers simultaneously * SSN - the noise generated by the simultaneous switching drivers as measured at a receiver somewhere. o That receiver may be at the far end of a line, seen by different receiver silicon. o That receiver may be at the near end of a line, seen by a receiver in the same silicon. + This can happen when there is the possibility the the silicon can both transmit and receive at the same time. Dynamic load characteristics that the driver sees will very much impact measured SSN energy. The driver does not exist outside of the system, it is part of the system, and as such, worst case driver performance and SSN will depend on the driving point impedance. That driving point impedance can be altered by external loading conditions, termination conditions, and interconnect length. This occurs because of standing waves on the interconnect. This phenomena was much more important during the days of reflected wave signaling, such as the original PCI bus, DDR 1 and 2, original Rambus, and many processor front-side busses. However, it nonetheless still exists today whenever a driven interconnect has a resonance point (even low-Q) that causes the load impedance to reflect back to the driver at any multiple of one bus cycle, thus aligning the reflection with a future edge transition. The primary interconnect reflection problem will cause a change in the driver current profile with time. This will in turn change the amplitude of measured SSN on other lines. With just the right data patterns, standing waves can increase the actual SSN. regards, Scott Scott McMorrow Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 (401) 284-1827 Business (401) 284-1840 Fax http://www.teraspeed.com Teraspeed(r) is the registered service mark of Teraspeed Consulting Group LLC On 8/3/2011 12:20 PM, Larry Smith wrote: > But this is the system response to the SSN generated near the driver. ------------------------------------------------------------------ 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 technical documents are available at: http://www.si-list.net List archives are viewable at: //www.freelists.org/archives/si-list Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. ------------------------------------------------------------------ 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 technical documents are available at: http://www.si-list.net List archives are viewable at: //www.freelists.org/archives/si-list Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu