[SI-LIST] Re: Pin vs. Die
- From: Hermann Ruckerbauer <Hermann.Ruckerbauer@xxxxxxxxxxxxx>
- To: lyndell.asbenson@xxxxxxxxxxx, Arpad_Muranyi@xxxxxxxxxx, "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
- Date: Sat, 10 Jan 2015 10:33:19 +0100
Hello,
there have been already a lot of discussions on this one, but still here
my two cents (especially realted on DRAMs):
Working in the DRAM interface development I was focusing on the die
signal integrity. The correlation of simulation and measurement to the
SI at the ball was the second part after we solved the issue to get the
signal good enough to the die.
What I did starting with higher DDR3 speed grades was to account for
package effects in the timing budget. In the die to die simulation the
package is included, but in the datasheet values the degradation of e.
g. Setup/Hold is included as well. So I did a simulation on the package
effects and subtracted these e. g. in the setup/hold requirements.
Problem is, that most of the IBIS models you will get today are not good
enough to keep this approach, as e. g. Crosstalk ist not included.
Regarding the measurment especially for multi die packages: I think the
only chance to verify SI in such cases is to use the embedding of the
package in the measurment e. g. by Infiniisim (Keysight). Measuring at
the pin of a multidie package is quite useless in my opinion.
For single die packages I'm measuring the DQ signals after the serial
resistors and use the the embedding feature of the scope and include
here DIMM routing and package. In case of a multidie package I would use
my interposers to simplify the embedding by beeing closer to the real point.
Problem of the embeddings are:
- The Package models might not be good enough
- the exact configuration is sometimes difficult to implement (e. g.
Termination settings during writes to Rank1 or RAnk2)
- The scope compliance app needs to separate read/write and really only
evaluate the write bursts. e. g. for overshoots the application might
not to this, but when using the embedding on the wrong configuration (e.
g. for reads) the results are completely wrong.
- ....
==> Conclusion: this is a real difficult task with a lot of
uncertainties...
Read vs. Write:
I know that some compliacne apps to sell "Data output Tests" as "Read
Tests". This is just Wrong.
Data output timings of the DRAM need to be tested not in the system but
on a special testboard in a testload. this is done by the DRAM vendor.
if you design a system your are interested in the input timings for the
controller. Controller are not commodity so each vendor can have
different input specs (and I have seen very strange ones in the past).
A first order test is to touch the probes as close as possible to the
controller package (maybe also embedd controller package in the scope
application), use the "Write Tests" of the compliance application and
delay the DQS by a quater period. By this you might be able to fool the
compliance app and sell Reads as writes.
DRAM vendors and JEDEC: I think the DRAM vendors are still working as I
mentioned in the beginning.
I have serveral times mentioned to my old contacts (who are still
working with JEDEC) that for people implemening DRAM memory subsystems
the current spec at the pin is not good enough and that it has a lot of
things that can be improved. But I never got real feedback on these (not
even when using the official Feedback from to JEDEC).
On DDR3 I tried to establish some kind of Mask testing, but JEDEC
thought for DDR3 the standard methodology is still good enough. I was
happy to see now the approach in DDR4 (but I have not enough expericene
with this one to judge if the implementation is good or not....)
The problem is, that the memory spec in JEDEC is driven by the DRAM
vendors, Controller vendors, and some large system vendors. For these
who are working so close to the develompent I think it is possible to
handle the issues as it was done in the past and they don't really care
about "normal" design engineers that need to implement and verify the
memory subsystem based on the spec.
As long as "we" have no voice in JEDEC I guess this will not change
(this is also the reason why DDR4 is optimized for servers).
I was considering to take a JEDEC membership, but I'm a one man show,
and I need to do my work for living .. and as long the efforts I would
spend there would not create any revenue I just can not spend the
ressources .. so if anybody is willing to pay for it I would be happy to
do this job ;-)
Best Regards
Hermann
EKH - EyeKnowHow
Hermann Ruckerbauer
www.EyeKnowHow.de
Hermann.Ruckerbauer@xxxxxxxxxxxxx
Itzlinger Strasse 21a
94469 Deggendorf
Tel.: +49 (0)991 / 29 69 29 05
Mobile: +49 (0)176 / 787 787 77
Fax: +49 (0)3212 / 121 9008
Am 09.01.2015 um 21:40 schrieb Lyndell Asbenson:
> That is tricky, I worked on that years ago Lyndell Asbenson
> -----Original Message-----
> From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
> Sent: â1/â9/â2015 1:27 PM
> To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
> Subject: [SI-LIST] Re: Pin vs. Die
>
> That brings an interesting question to my mind.
>
> How does one probe stacked die devices at the die?
> Is it possible to access the die pad on a die in
> the middle of the stack?
>
> Thanks,
>
> Arpad
> ===================================================
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
> Behalf Of Scott McMorrow
> Sent: Friday, January 09, 2015 12:23 PM
> To: Ralph Wilson
> Cc: Walter Katz; brian.p.moran@xxxxxxxxx; si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: Pin vs. Die
>
> If you saw what is done in some dual-die and quad-die packages, you would
> be very very scared of using measurements at the pins. Memory testers use
> very nicely controlled rise times. In that environment it may be possible
> to correlate performance, but a fast rise time controller might not play as
> nicely with these packages.
>
>
>
>
>
> Scott McMorrow
> Consultant - R&D
> 16 Stormy Brook Rd
> Falmouth, ME 04105
> (401) 284-1827 Business
> http://www.teraspeed.com
>
> On Fri, Jan 9, 2015 at 1:15 PM, Ralph Wilson <
> ralph.wilson@xxxxxxxxxxxxxxxxxx> wrote:
>
>> 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:
>
> [The entire original message is not included.]
> ------------------------------------------------------------------
> 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:
