[ibis-macro] Re: What I learned at DesignCon about PDN simulations.

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • To: Gregory R Edlund <gedlund@xxxxxxxxxx>
  • Date: Thu, 6 Feb 2014 16:43:45 -0500

Greg

I have no idea.  Just thinking.

If the predominant noise transfer mechanism is just additive to the signal,
then a PDF of the ac noise can be convolved with the pdf of the signal.  no
need to translate to the jitter domain, since edge displacement will occur
with noise.

If AM is involved, then this can be modeled in bit banging mode as a
variable gain amplifier at the Tx and Rx to account for noise at each
component.

If PM or FM is involved, then we might be pretty much hosed.  Then you're
dealing with the PLL and DLL circuits and the behavior is non-linear (I
think).

I'm just a hack guessing at this stuff.  People much smarter than myself
would need to look at this in detail.


Scott



On Thu, Feb 6, 2014 at 4:27 PM, Gregory R Edlund <gedlund@xxxxxxxxxx> wrote:

> Scott,
> Are you hinting at a parameterized behavioral description of how power
> distribution noise affects the drive stage of an IO circuit?  Maybe
> integrating this with the existing AMI DLL interface?  We could start with
> some simple mathematical relationships as a prototype.  We have to be sure
> not to violate the LTI assumptions, if that is possible.
>
> Walter,
> Were you going in this direction, or were you thinking about keeping the
> signal and power analyses in separate domains?
>
>
>
> Greg Edlund
> Senior Engineer
> Signal Integrity and System Timing
> IBM Systems & Technology Group
> 3605 Hwy. 52 N  Bldg 050-3
> Rochester, MN 55901
>
>
>
> [image: Inactive hide details for Scott McMorrow ---02/06/2014 10:31:54
> AM---Greg Just thinking out loud, it's pretty hard to do any so]Scott
> McMorrow ---02/06/2014 10:31:54 AM---Greg Just thinking out loud, it's
> pretty hard to do any sort of meaningful SSO
>
> From: Scott McMorrow <scott@xxxxxxxxxxxxx>
> To: Gregory R Edlund/Rochester/IBM@IBMUS,
> Cc: Walter Katz <wkatz@xxxxxxxxxx>, Bradley Brim <bradb@xxxxxxxxxxx>,
> IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>, ibis-macro-bounce@xxxxxxxxxxxxx
> Date: 02/06/2014 10:31 AM
> Subject: Re: [ibis-macro] Re: What I learned at DesignCon about PDN
> simulations.
> ------------------------------
>
>
>
> Greg
>
> Just thinking out loud, it's pretty hard to do any sort of meaningful SSO
> simulation without access to accurate die and package models.  Generally
> that's only available to the designers of the silicon.  So right there, you
> have a market limit.  Then we need to separate the linear and non-linear
> effects before noise can be modeled.
>
> 1) Is the noise merely superimposed on the signal?
> 2) Does it amplitude modulate the signal?
> 3) Does it phase or frequency modulate the signal through the PLL/DLL loop?
>
> Seems to me that the model is quite different for these different
> consequences of power noise.
>
> Scott
>
>
>
> On Thu, Feb 6, 2014 at 9:57 AM, Gregory R Edlund 
> <*gedlund@xxxxxxxxxx*<gedlund@xxxxxxxxxx>>
> wrote:
>
>    Walter, Brad, & IBIS Folks,
>
>    We've been talking about this internally off and on for some time.
>     There is definitely a need to account for supply noise in our AMI
>    simulations.  Right now, the jitter parameters are the best way to do this.
>      (Correct me if I haven't been keeping up.)  This involves the model
>    builder translating voltage noise into jitter in some simulation
>    environment outside of IBIS.  I wonder how many companies actually attempt
>    SSO analysis anymore?  I'd be willing to bet we could count them on one
>    hand.  It seems everyone is farming their design work out.  That makes me
>    question the business sense of implementing the necessary features in IBIS.
>     How could simulator companies recover their investment when the customer
>    base is so small?
>
>    Greg Edlund
>    Senior Engineer
>    Signal Integrity and System Timing
>    IBM Systems & Technology Group
>    3605 Hwy. 52 N  Bldg 050-3
>    Rochester, MN 55901
>
>
>
>    [image: Inactive hide details for Walter Katz ---02/04/2014 07:22:43
>    AM---Brad,]Walter Katz ---02/04/2014 07:22:43 AM---Brad,
>
>    From: Walter Katz <*wkatz@xxxxxxxxxx* <wkatz@xxxxxxxxxx>>
>    To: "Bradley Brim" <*bradb@xxxxxxxxxxx* <bradb@xxxxxxxxxxx>>,
>    "IBIS-ATM" <*ibis-macro@xxxxxxxxxxxxx* <ibis-macro@xxxxxxxxxxxxx>>,
>    Date: 02/04/2014 07:22 AM
>    Subject: [ibis-macro] Re: What I learned at DesignCon about PDN
>    simulations.
>    Sent by: *ibis-macro-bounce@xxxxxxxxxxxxx*<ibis-macro-bounce@xxxxxxxxxxxxx>
>    ------------------------------
>
>
>
>
>    Brad,
>
>    Again, your points are well taken. First, parallel interfaces are now
>    exceeding 2GBps. Although S parameters might be overkill at these data
>    rates, there are IC Vendors who are using "swathing" techniques for
>    parallel interfaces with parameterized SPICE circuits. 11-WE7 would have
>    been an ideal forum, but there was only enough time for one or two
>    questions at the end. SSO analysis is important - the current state of the
>    art is to include this noise in added timing margins and noise margins. So
>    the answer is yes, I believe that IBIS should be including SSO macro
>    models, but this traditionally has been beyond the scope of "Buffer"
>    models. So to answer your question, yes IBIS-AIM (or another IBIS AdHoc
>    committee would be an excellent forum for discussing adding PDN macro
>    modeling to the IBIS standard.
>
>    Walter
>
> * From:* Bradley Brim [*mailto:bradb@xxxxxxxxxxx* <bradb@xxxxxxxxxxx>]
> * Sent:* Monday, February 03, 2014 11:40 PM
> * To:* *wkatz@xxxxxxxxxx* <wkatz@xxxxxxxxxx>; IBIS-ATM
> * Subject:* RE: What I learned at DesignCon about PDN simulations.
>
>    Hi Walter,
>
>    Interested to learn in more detail your perception of requirements by
>    "system integrators" for PDN and power-aware SI design. Does you comment
>    apply to both serdes and parallel bus designs? DesignCon 2014 panel session
>    11-WE7 would have been an ideal forum in which to discuss this topic.
>
>    Does your text below imply you believe system integrators only require
>    enough information to select and place PCB decaps that are effective to
>    ~25MHz. You seem to imply there is no need (nor available info or tools)
>    for system integrators to pursue analyses such as SSO and performance for
>    this should be assured apriori by packaged device vendors. If this is the
>    case, seems difficult for system integrators to characterize their designs
>    for noise margin compliance. Maybe you propose some form of PDN macromodel
>    noise specification and a manner in which to include this in power-aware SI
>    verification analyses? If so, an interesting idea. Has such been proposed
>    or presented previously (e.g. at DesignCon) that you can cite for us? Seems
>    a perfect topic for a few DesignCon tracks: system, PI or PCB.
>
>    What is your goal in initiating the discussion with IBIS-ATM? Maybe a
>    PDN macromodel specification as part of IBIS? If it's not already
>    established in the literature is ATM the proper forum to propose and
>    prove-out such PDN macromodel approach?
>
>    Cheers,
>    -Brad
>
> * From:* *ibis-macro-bounce@xxxxxxxxxxxxx*<ibis-macro-bounce@xxxxxxxxxxxxx>
>     
> [*mailto:ibis-macro-bounce@xxxxxxxxxxxxx*<ibis-macro-bounce@xxxxxxxxxxxxx>]
>    *On Behalf Of *Walter Katz
> * Sent:* Monday, February 03, 2014 10:35 AM
> * To:* IBIS-ATM
> * Subject:* [ibis-macro] What I learned at DesignCon about PDN
>    simulations.
>
>    All,
>
>    There were a large number of papers at DesignCon about PDN, and all
>    pretty much said the same thing - it is all now a Science Experiment.
>    Although the composite current now in IBIS is part of the solution, the
>    real problem is how to apply composite current on all the buffers to
>    determine the current requirements on chip. One needs both the spectral
>    content of the total current on each rail and the phase (i.e. what buffers
>    are transitioning when). A SerDes bus will normally have all Tx
>    transitioning at more or less random times. This is assured by the data
>    patterns being 8B10, or scrambled. DDR DQ memory busses can have more
>    regular patterns (e.g. sending lots of 0 data with bursts of all 1's or
>    random data. This gets even more complicated for chips used in Mobile
>    devices where whole sections of a chip can be turned on or off to conserve
>    power. These problems need to be addressed by having sufficient on-die rail
>    capacitance and sufficient package capacitance. In addition, there needs to
>    be sufficient capacitors on the board. This on-die and package capacitance
>    requirements need to be addressed by the IC Vendor, requiring very detailed
>    knowledge of the current requirements for each buffer (e.g. IBIS composite
>    current), detailed knowledge of the spectral density and phase of the
>    buffer switching, and detailed power models on-die and in package. The
>    systems integrator will not have access to this type of information or the
>    simulation tools required to do these types of analysis. The systems
>    integrator does need to insure that he has sufficient  bypass capacitors
>    and power distribution on the board to supply current to the package. This
>    is  a ~25MegHz problem, not a ~GHz problem required by the chip/package
>    tool.
>
>    The bottom line is that we should not confuse the PDN modeling
>    requirements of the Chip/Package tools and the PDN modeling requirements
>    for the System Integrator.
>
>    Walter
>
>    Walter Katz
> *wkatz@xxxxxxxxxx* <wkatz@xxxxxxxxxx>
>    Phone 303.449-2308
>    Mobile 303.335-6156
>
>
>
>
>
> --
>
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 16 Stormy Brook Rd
> Falmouth, ME 04105
>
> (401) 284-1827 Business
>
> *http://www.teraspeed.com* <http://www.teraspeed.com/>
>
> Teraspeed(R) is the registered service mark of
> Teraspeed Consulting Group LLC
>
>
>


-- 

Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Rd
Falmouth, ME 04105

(401) 284-1827 Business

http://www.teraspeed.com

Teraspeed(R) is the registered service mark of
Teraspeed Consulting Group LLC

GIF image

Other related posts: