[ibis-macro] Re: Analog Buffer Model Inside DLL
- From: Gregory R Edlund <gedlund@xxxxxxxxxx>
- To: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
- Date: Mon, 17 Dec 2012 15:43:29 -0600
Michael,
I'm playing catch-up here. I think your idea about a establishing a set of
"standard" tests is right on the mark, and I'm beginning to realize my
DesignCon paper should have been a panel discussion because we could use
the topic of model-to-hardware correlation as a jumping off point for what
makes a good set of tests.
In my mind, it makes sense to divide the tests into four broad categories:
1. TX analog buffer model
2. RX analog buffer model
3. TX algorithmic model
4. RX algorithmic model
To get the ball rolling, let me suggest a few items for the first category:
1. TX analog buffer model
a. turn off de-emphasis
b. ideal RX (pass through, like an oscilloscope)
c. D10.2 pattern
d. drive a light load and decompose the jitter
e. drive a moderately reflective load
f. drive a moderately lossy line with PRBS-7 pattern
Greg Edlund
Senior Engineer
Signal Integrity and System Timing
IBM Systems & Technology Group
3605 Hwy. 52 N Bldg 050-3
Rochester, MN 55901
From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
To: Gregory R Edlund/Rochester/IBM@IBMUS, "mike@xxxxxxxxxxx"
<mike@xxxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx"
<ibis-macro@xxxxxxxxxxxxx>
Date: 12/13/2012 01:51 PM
Subject: RE: [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: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
Other related posts:
- » [ibis-macro] Analog Buffer Model Inside DLL- Gregory R Edlund
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Kumar Keshavan
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Walter Katz
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Gregory R Edlund
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- David Banas
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Dmitriev-Zdorov, Vladimir
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Gregory R Edlund
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Muranyi, Arpad
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Muranyi, Arpad
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Dmitriev-Zdorov, Vladimir
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Mike Steinberger
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Dmitriev-Zdorov, Vladimir
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Dmitriev-Zdorov, Vladimir
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Muranyi, Arpad
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Muranyi, Arpad
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Mike LaBonte
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- fangyi_rao
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Scott McMorrow
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Dmitriev-Zdorov, Vladimir
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Gregory R Edlund
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- fangyi_rao
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- radek_biernacki
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Mirmak, Michael
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- James Zhou
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- James Zhou
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- James Zhou
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Kumar Keshavan
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Walter Katz
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- Todd Westerhoff
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- James Zhou
- » [ibis-macro] Re: Analog Buffer Model Inside DLL- James Zhou
