[SI-LIST] Re: SSO and load capacitance

  • From: Larry Smith <LSMITH@xxxxxxxxxx>
  • To: 'Scott McMorrow' <scott@xxxxxxxxxxxxx>, "'si-list@xxxxxxxxxxxxx'" <si-list@xxxxxxxxxxxxx>
  • Date: Thu, 4 Aug 2011 13:32:47 -0700

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
  

Other related posts: