Please remember that there are two ends of a DDR interface, the memory and the controller. I believe that the DDR specs are at the memory only. So one may choose to require that simulations at the memory verify the rules at the Pin, since that is where the memory suppliers are doing their compliance tests, but one should not necessarily apply the same methodology at the controller inputs. Walter Katz Signal Integrity Software, Inc. -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Moran, Brian P Sent: Friday, January 09, 2015 12:55 PM To: ralph.wilson@xxxxxxxxxxxxxxxxxx; si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: Pin vs. Die I believe this issue has been a source of ongoing discussion within the DDR community for a while. Since the device vendors typically spec to the pin, and indeed test and characterize their parts in the package, there are no true specs for how the signal should behave at the die. Yet, we all know that the waveform at the pin is pretty meaningless as far as SI analysis. Where it gets even more acute is with DDP and QDP devices, where the package interconnect gets longer and more complex. I just don't see any viable alternative to making all measurements at the die, however, OS/US is an interesting counter argument. I have to assume that when they spec OS/US they are basing it on the waveform at the die, but I always hope not to have a case where it passes at one and not the other. Brian Moran Intel Corporation -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Ralph Wilson Sent: Friday, January 9, 2015 6:07 AM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: Pin vs. Die Let me throw in a devil's advocate alternative rationale, as I'm involved in the discussion with Conrad. First of all, I agree that generally the signal at the die is what we really want to "make good". However, in this particular case, using ibis and package models that we trust, we are seeing DDR3 signals that are ringing back below the Vin(ac) levels. At the die the signals are actually ringing back below Vref (well below Vin(dc)). However, at the pin the signals remain above Vin(dc). Hence, at the die the signals fail, but at the pin the signal is ok. The devil's advocate argument goes that the vendor has spec'd the device at the pins. Hence, if we meet the SI at the pin, we can make an argument that we've met the device specs and the system ought to work. If there's a problem it is the device vendor's (package) issue, not a PWB design issue (ignoring the fact that we're trying to make the system work, not point fingers). In other words, do we do something "strange" or "abnormal" to the PWB to compensate for the package parasitics in order to clean up the signal at the die (and likely screw up the signal at the pin)? Or, keep the PWB routing clean and have good signals at the pin but not at the die? I argue for the latter. Ralph Wilson Alcatel-Lucent On 1/9/2015 7:33 AM, Conrad Herse wrote: > Thank-you everyone for your replies, the consensus opinion is > consistent with mine - "it's the die that matters". The reason I > brought this up is that we're working on this situation right now: a > design with better SI quality at the pin than the die. I continue to > advocate that it's the die that matters, but questions are being asked > if that's too conservative.We will continue to scrutinize the > implementation and models to try and improve our results. > > If anyone has a dissenting opinion I would be very interested in > hearing about it and any supporting data behindthe position. > > Thanks! > > Conrad Herse > Alcatel-Lucent > Conrad.Herse@xxxxxxxxxxxxxxxxxx > > On 1/9/2015 3:10 AM, Craciun, Liviu-Dumitru wrote: >> Hi Todd. >> I agree "signal quality at the die is what matters". >> Yet I make simulation ONLY at the die and at some test points. >> >> To compare the simulations results with the measurements we place >> test points somewhere on the transmission lines. >> The position is NOT important !! >> Why ? >> The simulation tool is able to show the waveform at the test point, >> with and without the influence of the scope probe. >> >> If the measurements at the TP are in concordance with the simulation >> results WITH the influence (with the load) of the scope probe ... then >> the simulation reflects the reality. >> So, the waveforms at the die will be "identical" with the simulation >> results. >> Clear, plus minus tolerances. >> >> Best regards, >> Liviu Craciun >> Harman Becker Automotive Systems GmbH >> D-76307 Karlsbad, Germany >> >> -----Ursprüngliche Nachricht----- >> Von: si-list-bounce@xxxxxxxxxxxxx >> [mailto:si-list-bounce@xxxxxxxxxxxxx] Im Auftrag von Todd Westerhoff >> Gesendet: Donnerstag, 8. Januar 2015 21:26 >> An: si-list@xxxxxxxxxxxxx >> Betreff: [SI-LIST] Re: Pin vs. Die >> >> Conrad, >> >> Interesting question. Ultimately, it's the signal at the die that >> matters, because that's the signal that gets received and processed. >> Anything else is well, just, something else. >> >> My experience matches yours - having poor signal quality at the pin >> but acceptable quality at the receiving die is common, but the other >> way around is rare. Uncommon enough that I can't remember the last time I >> saw it. >> >> In years past, I've seen metrics that assessed signal quality at the >> pin, in an effort to assure that signal quality at the die was >> acceptable. This was a measurement-based methodology and I don't think >> it's in use anymore. >> >> My vote - signal quality at the die is what matters. >> >> Todd. >> >> Todd Westerhoff >> VP, Semiconductor Relations >> Signal Integrity Software Inc. • www.sisoft.com >> 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 >> (978) 461-0449 x24 • twesterh@xxxxxxxxxx >> >> “I want to live like that” >> -Sidewalk Prophets >> >> -----Original Message----- >> From: si-list-bounce@xxxxxxxxxxxxx >> [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Conrad Herse >> Sent: Thursday, January 8, 2015 3:04 PM >> To: si-list@xxxxxxxxxxxxx >> Subject: [SI-LIST] Pin vs. Die >> >> Historically, when performing PCB SI (ibis) simulations I've always >> focused on the SI quality of a signal when measured at the die of a >> receiving device, if a signal needs to be monotonic I've ensured it's >> monotonic at the die rather than at the pin. On (rare) occasions I've >> encountered instances where simulations show a signal to have >> acceptable SI at the pin but not the die, for these cases I've always >> worked to find improvements to achieve acceptable SI in the die waveform. >> >> Questions have been raised recently as to whether achieving good SI >> at the pin of a device is adequate, without careful regard to the SI >> of a waveform at the die. The rationale behind this being that >> datasheet specifications were traditionally considered at the pin of >> a device. The reasoning goes that if good SI is achieved at a device >> pin this meets the datasheet specifications and no further improvements >> should be needed. >> >> I personally do not subscribe to this line of reasoning but would be >> interested in hearing feedback from others on this. >> >> Thanks, >> >> -- >> Conrad Herse >> Alcatel-Lucent >> Conrad.Herse@xxxxxxxxxxxxxxxxxx >> >> ------------------------------------------------------------------ >> 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 forum is accessible at: >> http://tech.groups.yahoo.com/group/si-list >> >> 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 >> >> >> ------------------------------------------------------------------ >> 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 forum is accessible at: >> http://tech.groups.yahoo.com/group/si-list >> >> 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 >> >> >> ------------------------------------------------------------------ >> 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 forum is accessible at: >> http://tech.groups.yahoo.com/group/si-list >> >> 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 >> >> > ------------------------------------------------------------------ > 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 forum is accessible at: > http://tech.groups.yahoo.com/group/si-list > > 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 > > ------------------------------------------------------------------ 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 forum is accessible at: http://tech.groups.yahoo.com/group/si-list 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 ------------------------------------------------------------------ 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 forum is accessible at: http://tech.groups.yahoo.com/group/si-list 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 ------------------------------------------------------------------ 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 forum is accessible at: http://tech.groups.yahoo.com/group/si-list 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