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

  • From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
  • To: <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 14 Dec 2012 08:23:17 -0500 (EST)

James,



Maybe I’m missing something ... how would the algorithmic model get the 
S-parameters for the channel network to be cascaded, given that only an 
impulse response is passed in?



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: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of James Zhou
Sent: Thursday, December 13, 2012 6:28 PM
To: michael.mirmak@xxxxxxxxx; gedlund@xxxxxxxxxx; mike@xxxxxxxxxxx; 
ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL



Considering Greg's original question (put analog buffer inside dll), even 
though IBIS 5.1 does not support this practice, technically it is a network 
cascade problem that had been solved time ago in network theory using 
S-parameters.



Although "nasty things" could happen if someone "puts the analog buffer 
model inside the DLL", it can be easily avoided by the time-tested 
S-parameter network cascading formula, in which case the impulse response 
CAN also be made correct.



Many of the IBIS AMI models  I have seen so far treat the AMI-to-analog 
interface as perfectly matched  (which is referred to as "isolated" in some 
communications). This makes the network cascading problem easier. However 
this is only a special case of a more general problem of network cascading 
with mismatch, which solutions are readily available and can be derived 
easily using S-parameter theory.



I have recently run into a case where the AMI channel simulation generated 
incorrect amplitude. The EDA tool vendor  contributed the cause to 
misinterpretation of AMI to Tx analog interface impedance in the model. From 
users point of view, this kind of problems can be very difficult and 
time-consuming to debug. It would be very helpful to further clarify these 
issues in the specification by some working examples as Michael has 
suggested.



James Zhou







From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Thursday, December 13, 2012 11:51 AM
To: gedlund@xxxxxxxxxx; mike@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL



(putting on my user hat)



I would have to agree with Greg here.  We are seeing cases where the 
relationship between the data in the traditional IBIS [Model] – including 
C_comp, I-V tables and V-t tables – and the algorithmic model – the .ami 
file and accompanying DLL -- isn’t consistently defined or implemented.



It’s understandable that complex, non-LTI behaviors in the traditional 
[Model] data would be undesirable to include alongside an algorithmic model 
(for example, a non-linear I-V curve set or, if traditional IBIS supported 
it, a complex, voltage-dependent buffer capacitance representation). 
However, the discussion here implies that realistic, simple traditional 
[Model] data should always be present, not zeroed out as Greg is seeing.



If the language in the specification says the data is “used” for analog 
channel characterization, perhaps that language isn’t strong enough to 
ensure that both the right data and the right processing algorithms are used 
to combine them?



Alternately, could we define some simple tests of analog and algorithmic 
model interaction to show that “everything’s working OK?”  For example, in 
traditional IBIS, one of the key tests we have used to show how C_comp 
functions is to ask a user to:

-          Simulate an IBIS driver into a resistive load

-          Simulate the same driver into a lengthy (hopefully mismatched) 
transmission line

-          Alter the C_comp (even setting it to zero) in the driver model, 
re-run both tests above, and observe the behavior



We would expect to see the resistive load cases not differ much at all, due 
to the way C_comp double-counting is avoided in most tools.  However, there 
should be a fairly big difference in the t-line cases due to reflections 
interacting differently with the changed C_comp.



Do we have, or can we produce, a set of similar tests that would demonstrate 
that a traditional + algorithmic model set is working correctly, together, 
in a given simulation environment?



-          MM



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Gregory R Edlund
Sent: Thursday, December 13, 2012 9:56 AM
To: mike@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL



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



Inactive hide details for Mike LaBonte ---12/12/2012 04:48:48 PM---I 
understood Greg's proposal as simply implementing "forwardMike 
LaBonte ---12/12/2012 04:48:48 PM---I understood Greg's proposal as simply 
implementing "forward" simulation of analog effects within a

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: <mailto:twesterh@xxxxxxxxxx> 
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 <tel:%28978%29%20461-0449%20x24>

twesterh@xxxxxxxxxx

www.sisoft.com <http://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> 
mailto:twesterh@xxxxxxxxxx]
Sent: Wednesday, December 12, 2012 3:56 PM
To: Muranyi, Arpad
Cc:  <mailto:ibis-macro@xxxxxxxxxxxxx> 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 <tel:%28978%29%20461-0449%20x24>

twesterh@xxxxxxxxxx

www.sisoft.com <http://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:  <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
ibis-macro-bounce@xxxxxxxxxxxxx [ <mailto: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:  <mailto:ibis-macro@xxxxxxxxxxxxx> 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. •  <http://www.sisoft.com/> www.sisoft.com

6 Clock Tower Place • Suite 250 • Maynard, MA 01754

 <tel:%28978%29%20461-0449%20x24> (978) 461-0449 x24  • 
<mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx



“I want to live like that”

                                             -Sidewalk Prophets



From: Dmitriev-Zdorov, Vladimir [ 
<mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx> 
mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx]
Sent: Wednesday, December 12, 2012 2:39 PM
To:  <mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx; 'Gregory R Edlund'
Cc:  <mailto:ibis-macro@xxxxxxxxxxxxx> 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:  <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
ibis-macro-bounce@xxxxxxxxxxxxx [ <mailto: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:  <mailto:ibis-macro@xxxxxxxxxxxxx> 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. •  <http://www.sisoft.com/> www.sisoft.com

6 Clock Tower Place • Suite 250 • Maynard, MA 01754

 <tel:%28978%29%20461-0449%20x24> (978) 461-0449 x24  • 
<mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx



“I want to live like that”

                                             -Sidewalk Prophets



From: Gregory R Edlund [ <mailto:gedlund@xxxxxxxxxx> 
mailto:gedlund@xxxxxxxxxx]
Sent: Wednesday, December 12, 2012 1:41 PM
To: Todd Westerhoff
Cc:  <mailto:ibis-macro@xxxxxxxxxxxxx> 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 < <mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx>
To: Gregory R Edlund/Rochester/IBM@IBMUS
Cc: " <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx" < 
<mailto: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 <tel:%28978%29%20461-0449%20x24>
twesterh@xxxxxxxxxx
www.sisoft.com <http://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



  _____

This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If 
you are not the intended recipient, you may not read, copy, distribute, or 
use this information. If you have received this transmission in error, 
please notify the sender immediately by reply e-mail and then delete this 
message.

GIF image

Other related posts: