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

  • From: Mike LaBonte <mike@xxxxxxxxxxx>
  • To: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • Date: Wed, 12 Dec 2012 17:47:31 -0500

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 <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 <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<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 <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 <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****
>
>

Other related posts:

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