[ibis-macro] Re: Analog Buffer Model Inside DLL

  • From: Gregory R Edlund <gedlund@xxxxxxxxxx>
  • To: mike@xxxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 13 Dec 2012 11:55:47 -0600

Mike & Others,

I didn't mean to propose any changes to the existing IBIS 5.1 flow.  I was
responding to a question that arose within the company about the validity
of an AMI model that has no analog buffer model in the .ibs file (empty
tables and zero C_comp).  The vendor claims that information is stored in
the DLL.  Maybe it is, but the model is not IBIS 5.1 compliant nor will it
produce a physical simulation with any simulator on the market.

I think we need to focus our efforts on building momentum behind IBIS 5.1,
and that means building confidence among the user community by establishing
a base of high-quality models.

Greg Edlund
Senior Engineer
Signal Integrity and System Timing
IBM Systems & Technology Group
3605 Hwy. 52 N  Bldg 050-3
Rochester, MN 55901





From:   Mike LaBonte <mike@xxxxxxxxxxx>
To:     "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
Cc:     "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
Date:   12/12/2012 04:48 PM
Subject:        [ibis-macro] Re: Analog Buffer Model Inside DLL
Sent by:        ibis-macro-bounce@xxxxxxxxxxxxx



I understood Greg's proposal as simply implementing "forward" simulation of
analog effects within a DLL, such that it only affects the output of each
stage, no chance to create or respond to backward signals. It's easy to see
that this is going to be a problem. Vladimir's proposal amounts to
embedding s-parameter models within DLLs, to be selected and either passed
to the EDA tool or combined with the channel response right within the DLL.
These are completely different proposals.

The latter idea could be seen as a combination of Fangyi's proposal that
the DLL be able to make choices based on inputs then communicate them back
out, and the idea that the analog model should be s-parameters, resulting
in the ability to simply embed the s-parameter data sets in the DLL, which
communicates the correct set back out based on settings. One observation is
that we now seem to have more proposals putting the analog model in the AMI
model than proposals keeping it in the legacy IBIS domain.

Mike


On Wed, Dec 12, 2012 at 5:14 PM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
wrote:
  Todd,





  The original question from Greg was:





  “What nasty things are likely to happen if someone puts the analog buffer
  model inside the DLL?


  At the very least, the impulse response will be incorrect.  Are there any
  circumstances under


  which this can work correctly?





  This spawned a bunch of replies ranging from “why not”


  to “impossible”, mostly on theoretical bases.  You


  may be right that this may not be practical at the


  moment, but that’s not what the question was about.





  Whether it is worth solving or not could be discussed


  in a separate thread.  Who knows, we might find out


  that it is worth considering it…





  Thanks,





  Arpad


  =======================================================








  From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
  Sent: Wednesday, December 12, 2012 4:07 PM



  To: Muranyi, Arpad
  Cc: ibis-macro@xxxxxxxxxxxxx
  Subject: Re: [ibis-macro] Re: Analog Buffer Model Inside DLL





  ... and revisiting one of the fundamental assumptions on which all of
  IBIS-AMI is based.





  Which, based on past experience, is expensive, both in terms of time and
  effort.





  I therefore assert that this is a problem that isn't worth solving.





  Todd.








  --





  Todd Westerhoff


  VP, Software Products


  SiSoft


  6 Clock Tower Place, Suite 250


  Maynard, MA 01754


  (978) 461-0449 x24


  twesterh@xxxxxxxxxx


  www.sisoft.com








  “I want to live like that"


                                               -Sidewalk Prophets






  On Dec 12, 2012, at 5:01 PM, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  wrote:
        Todd,





        I did not suggest that this was possible under the


        umbrella of the current v5.1 IBIS specification.





        In one of my responses I stated:





        “We would also need to revisit the AMI flow a


        little bit, but that’s just detail.”





        which implies a spec change, as far as I can tell…





        Thanks,





        Arpad


        ===================================================





        From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
        Sent: Wednesday, December 12, 2012 3:56 PM
        To: Muranyi, Arpad
        Cc: ibis-macro@xxxxxxxxxxxxx
        Subject: Re: [ibis-macro] Re: Analog Buffer Model Inside DLL





        Arpad,





        We have a published spec that says the analog model is to be
        included in the calculation of that channel impulse response.





        Anything else is not compliant.





        Todd.





        --





        Todd Westerhoff


        VP, Software Products


        SiSoft


        6 Clock Tower Place, Suite 250


        Maynard, MA 01754


        (978) 461-0449 x24


        twesterh@xxxxxxxxxx


        www.sisoft.com








        “I want to live like that"


                                                     -Sidewalk Prophets






        On Dec 12, 2012, at 4:21 PM, "Muranyi, Arpad" <
        Arpad_Muranyi@xxxxxxxxxx> wrote:
              Todd,





              This is not super-theoretical-science in the clouds.





              It can be done just as practically and “easily” as the


              EQ, DFE and CDR AMI algorithms can be done in the DLL-s.


              It involves the same kind of algorithm knowledge, and


              programming skill.





              The question is, do we want to let model makers to do


              this, and possibly get a bunch of bad models from


              inexperienced people, or should we, the EDA vendors


              still have the opportunity to sell our expertise and


              provide higher quality and more reliable solutions to


              our customers and AMI model users.





              Thanks,





              Arpad


              ==========================================================





              From: ibis-macro-bounce@xxxxxxxxxxxxx [
              mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd
              Westerhoff
              Sent: Wednesday, December 12, 2012 2:54 PM
              To: Dmitriev-Zdorov, Vladimir; 'Gregory R Edlund'
              Cc: ibis-macro@xxxxxxxxxxxxx
              Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL





              Vladimir,





              Not clear to me how you propose to handle the reflections
              associated with discontinuities at the point where the TX and
              RX analog circuits interface to the channel.  More
              importantly, even if it’s theoretically possible, that
              doesn’t make it practical.





              I’ll admit I’m guessing here, but I expect Greg wants to
              solve a problem, not just establish that it should be
              possible to solve it.





              Todd.





              Todd Westerhoff


              VP, Software Products


              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





              From: Dmitriev-Zdorov, Vladimir [
              mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx]
              Sent: Wednesday, December 12, 2012 2:39 PM
              To: twesterh@xxxxxxxxxx; 'Gregory R Edlund'
              Cc: ibis-macro@xxxxxxxxxxxxx
              Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL





              In an abstract/theoretical way, it is still possible that AMI
              DLL correctly takes care of the “impulse response” by adding
              its internal model to it. Then however it should not be an
              ‘impulse response’, but 2- or 4-port S-parameters
              representing the core portion of the channel, which does not
              include analog models. Each model then can ‘append’ its
              analog part to the S-parameters, and restore the resulting
              impulse response, if needed for equalization. Instead of
              returning the updated impulse response, the Init function (or
              how we call it) will return the updated touchstone file,
              which then is passed to the Rx model, with the same purpose.





              The objection here is that Tx must have the complete channel
              info, with Rx analog model,  before its Init function can
              start thinking about equalization, but then ‘appending’
              analog models could be either separated from Init, and
              organized as one more function, possibly combined with what
              Fangyi proposed about resolving dependences, or we could
              still do everything in just one function, but perform a few
              cycles of Initialization, for example: (Tx_Init(), Rx_Init
              ()), (Tx_Init(), Rx_Init()) … which resembles “backchannel”
              communication on Init() stage.





              Of course, the writer of the AMI model must be able to do
              some operations with touchstone files, such as appending the
              model to it, and converting it into transfer function,
              finding impulse response by IFFT, etc.





              From: ibis-macro-bounce@xxxxxxxxxxxxx [
              mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd
              Westerhoff
              Sent: Wednesday, December 12, 2012 11:51 AM
              To: 'Gregory R Edlund'
              Cc: ibis-macro@xxxxxxxxxxxxx
              Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL





              Greg,





              Ask yourself how the person writing an algorithmic model
              should accurately model the reflections associated with an
              unspecified channel.  If there’s a way to do that, I’d like
              to hear about it.





              Todd.





              Todd Westerhoff


              VP, Software Products


              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





              From: Gregory R Edlund [mailto:gedlund@xxxxxxxxxx]
              Sent: Wednesday, December 12, 2012 1:41 PM
              To: Todd Westerhoff
              Cc: ibis-macro@xxxxxxxxxxxxx
              Subject: Re: [ibis-macro] Analog Buffer Model Inside DLL





              Todd,

              Thanks for the response.

              So, there are no "mathematical tricks" one can play in the
              DLL to account for the absence of the analog buffer model in
              the impulse response?  You can tell I haven't taken enough
              time to think this through all the way.  I'm having a
              knee-jerk reaction to a discussion that's going on
              internally.  8-)  I'm about to dig into the IBIS 5.1 flow
              material to support my position.  I just wanted to make sure
              I had my ducks in a row and get some outside corroboration.

              Anyone else care to chime in?

              Greg Edlund
              Senior Engineer
              Signal Integrity and System Timing
              IBM Systems & Technology Group
              3605 Hwy. 52 N  Bldg 050-3
              Rochester, MN 55901



              <image001.gif>Todd Westerhoff ---12/12/2012 12:31:11
              PM---Greg, That is not possible. The analog model, by
              definition, interacts with the channel and must be

              From: Todd Westerhoff <twesterh@xxxxxxxxxx>
              To: Gregory R Edlund/Rochester/IBM@IBMUS
              Cc: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
              Date: 12/12/2012 12:31 PM
              Subject: Re: [ibis-macro] Analog Buffer Model Inside DLL








              Greg,

              That is not possible. The analog model, by definition,
              interacts with the channel and must be included in the
              impulse response. The equalization, also by definition, is
              considered to be electrically isolated from the channel and
              is thus represented in the DLL.

              Putting the analog model in the DLL violates a fundamental
              assumption of IBIS-AMI. You may get good-looking results, but
              they will be invalid.

              Todd.


              --

              Todd Westerhoff
              VP, Software Products
              SiSoft
              6 Clock Tower Place, Suite 250
              Maynard, MA 01754
              (978) 461-0449 x24
              twesterh@xxxxxxxxxx
              www.sisoft.com


              “I want to live like that"
                                                           -Sidewalk
              Prophets


              On Dec 12, 2012, at 1:13 PM, Gregory R Edlund <
              gedlund@xxxxxxxxxx> wrote:



                    What nasty things are likely to happen if someone puts
                    the analog buffer model inside the DLL?  At the very
                    least, the impulse response will be incorrect.

                    Are there any circumstances under which this can work
                    correctly?

                    Greg Edlund
                    Senior Engineer
                    Signal Integrity and System Timing
                    IBM Systems & Technology Group
                    3605 Hwy. 52 N  Bldg 050-3
                    Rochester, MN 55901

GIF image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 12-2012