[SI-LIST] Re: Pin vs. Die
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
- Date: Fri, 9 Jan 2015 18:27:49 +0000
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:
> >>> 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
------------------------------------------------------------------
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:
