[SI-LIST] Re: Pin vs. Die
- From: Ralph Wilson <ralph.wilson@xxxxxxxxxxxxxxxxxx>
- To: Walter Katz <wkatz@xxxxxxxxxx>, brian.p.moran@xxxxxxxxx, si-list@xxxxxxxxxxxxx
- Date: Fri, 09 Jan 2015 12:15:19 -0600
Any memory vendors care to weigh in on this pin/die topic?
Ralph Wilson
Alcatel-Lucent
On 1/9/2015 12:08 PM, Walter Katz wrote:
> 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
Other related posts:
