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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 20 Dec 2012 18:39:34 +0000

Todd,

I agree on both points.  And the minutes from the last ATM
meeting contains this on the discussion of analog models:


Analog models:
- Walter: In IBIS 5.1 no analog model is defined
- Michael M: You can have zeroed-out IV models
- Walter: An IBIS Input requires no IV curves at all
  - In IBIS 5.1 the DLL can not affect impulse response creation
- Ambrish: Correct
- Walter: James proposed a way to have the DLL modify the channel response
- James: Two issues:
  - What should models do in IBIS 5.1?
    - The emails have clarified that
    - The analog channel should have high Z input
  - What if models do not follow the convention?
    - Have seen models that do not, created by members of this group
    - From one vendor one TX assumes 0 ohm, other assume 50 ohm
    - Signals can only flow forward
  - We could let model makers use any declared impedance
    - If an s-param is used that impedance is always there
- Walter: Agree, we need a specified on-die s-param analog model
  - It has to declare the termination parameters
- Ambrish: Analog models have been put in the DLL?
- Walter: No
- James: My point is that we do not have to force people to use 0 ohms
- Michael M: We are running into TX interoperability problems right now
  - In some cases ramp and IV have been embedded in the DLL
  - We must distinguish between analog info in DLL vs. AMI
  - I don't think anyone wants it in the DLL
- Ambrish: Then the AMI model is not a legal IBIS model
- Michael M: Some problems are cause by assumptions about where the VT data is
  - Embedding in the DLL may be bad for bandwidth reasons
- Arpad: Ramp is required in IBIS
- Fangyi: BIRD 116 might address the impedance issue
- Arpad: It replaces C_comp and IV with ISS
- Radek: We have had that discussion, we decided TX is a 0 ohm source
  - Defining source impedance should be doable right away
- Walter: IBIS 5.1 says that
- Fangyi: It just says "high impedance interface"
- Arpad: It says "high impedance connection"
  - That is even more vague
- Radek: There is no requirement that the input impedance is infinite
- James: We agree on interpretation of IBIS 5.1
- Arpad: IBIS 5.1 does not allow s-parameters
- James: If output is 0 ohms then the s-parameter is -1
- Michael M: There is no way to test this for current implementations

Arpad: We might continue this tomorrow



Thanks,

Arpad
=============================================================

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Todd Westerhoff
Sent: Thursday, December 20, 2012 11:46 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL

Thanks Walter,

Arpad (and others), do you agree?  This is something SiSoft has been saying for 
a while, so I’m looking for confirmation (outside of SiSoft) that these 
statements have been agreed up by the committee.

For example, is this in the meeting minutes? It should be, right?

Todd.


Todd Westerhoff
VP, Software Products
Signal Integrity Software Inc. • www.sisoft.com<http://www.sisoft.com>
6 Clock Tower Place • Suite 250 • Maynard, MA 01754
(978) 461-0449 x24  •  twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx>

“I want to live like that”
                                             -Sidewalk Prophets

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, December 20, 2012 9:40 AM
To: twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx>; 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL

Todd,

Yes. This was discussed in this week’s IBIS-ATM meeting. There was agreement 
with no objection that the two points below were affirmed.

Walter

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Thursday, December 20, 2012 8:31 AM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL

All,

Have we reached the point where we can offer the following guidance on Greg’s 
original question:


1)      A compliant IBIS 5.1 model MUST include an analog model in the .ibs file

2)      The IBIS 5.1 AMI flow does NOT support “inclusion” of the analog model 
in the .dll

I would like the committee to provide guidance on this, in addition to 
discussing the future direction of the spec.  Greg is correct -  some vendors 
produce algorithmic models without analog sections and expect customers to use 
them. The problem is that neither they (nor their customers, usually) 
understand how this compromises the accuracy of the final result.

Todd.


Todd Westerhoff
VP, Software Products
Signal Integrity Software Inc. • www.sisoft.com<http://www.sisoft.com>
6 Clock Tower Place • Suite 250 • Maynard, MA 01754
(978) 461-0449 x24  •  twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx>

“I want to live like that”
                                             -Sidewalk Prophets

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of James Zhou
Sent: Thursday, December 20, 2012 12:49 AM
To: Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>; 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL

Arpad,

I respectfully disagree with your comments below. Fangyi's comments are 
directly applicable to the existing 5.1 spec, page 122, section 6c, paragraph 
2. It is incorrect to dismiss them as irrelevant to the existing spec. And it 
is neither practical nor necessary to write a new BIRD every time there is a 
question/comment about the spec, due to the overhead and time involved.

As you have stated, "this ... would require a lot of additional detail on where 
this analog portion begins...", a lot of details are indeed still missing  on 
AMI analog models. And that is the main reason, in my humble opinion, why 
different EDA tools generate different results using the same AMI model.  If 
ambiguities in the spec can be arbitrarily categorized as vendor proprietary 
"features", then what is the purpose of writing a spec that anyone could 
interpret it in their own way, and produce their own results that is "better" 
than others? The fact of the matter is that, although certain things are 
governed  by IBIS spec, but everything is governed by laws of electronics. We 
need to make sure that the former must agree with the latter, not the other way 
round.

James








From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 19, 2012 7:00 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL

Fangyi,

While I don’t dispute that the “ Tx DLL’s output waveform ” could be
“ the voltage waveform of the ideal voltage source that is connected to the Tx 
analog portion”,
according to the AMI flow in the IBIS v5.1 specification it is
not.  So we can’t clarify something in the specification that
wasn’t mentioned.  We can write a BIRD, though, to introduce
this as a new concept in the spec… but that would require a lot
of additional detail on where this analog portion begins in [Model],
and/or whether it applies to any kind of [Model] (I-V and V-t
curve based models, or S-parameter models only, if the latter,
are we talking about the input to [External Model] only, if
so with which languages, etc…).

But I would like to say here that we did have a discussion in
the ATM meetings in the days when we were re-writing the AMI
flow for v5.1 whether we should mention such alternative methods.
The committee’s decision at that time was that we did not need
to mention all the possible alternate ways of how EDA vendors
could possibly implement the AMI flow in their tools.

So my position on this now is that we should only add things
like this to the specification if the information is relevant
to other aspects or areas of the specification in any way.  If
there is another keyword or parameter that has any kind of a
dependency on this information, we need to spell it out.
Otherwise it is only a private or proprietary matter of an
EDA vendor for their own implementation.

Thanks,

Arpad
================================================================

From: fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx> 
[mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Wednesday, December 19, 2012 8:41 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL

We should make it clear that Tx DLL’s output waveform is the voltage waveform 
of the ideal voltage source that is connected to the Tx analog portion.

Fangyi

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 19, 2012 5:00 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL

“So, are the analog buffer and AMI block connected or not? ”
In the real physical world they are, i.e. EQ, CDR, DFE, etc…
are connected to the analog “front end” of the buffer, but in
IBIS-AMI simulations the specification treats them as two
independent animals.  According to the IBIS-AMI spec, they
are not connected in an electrical sense, i.e. there are no
voltages and currents flowing between the analog models and
the AMI DLL-s and consequently no electrical interactions are
possible between the two domains.  The AMI DLL only supposed
to know about the analog model through the impulse response
of the channel.


“Is this connection point (or "isolation point" as you have been referring it 
as)
the same as D_drive or A_signal in Table 12 (also depicted in  Fig 19) of IBIS 
5.1? ”

It is D_drive, not A_signal.

I hope this helps,

Arpad
================================================================


From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Wednesday, December 19, 2012 6:30 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL

Hi Arpad,

Your comments help to clarify the spec on some issues and are appreciated.

With the sole purpose of correctly interpret the spec, when putting your words  
together with the spec, I couldn't make sense out of them:
Arpad:     In IBIS v5.1 the analog buffer models were not intended to be 
connected to the AMI model using such electrical connections.
IBIS 5.1:     The transmitter equalization, receiver equalization and clock 
recovery circuits are assumed to have a high-impedance (electrically isolated) 
connection to the analog portion of the channel.

So, are the analog buffer and AMI block connected or not?

Is this connection point (or "isolation point" as you have been referring it 
as) the same as D_drive or A_signal in Table 12 (also depicted in  Fig 19) of 
IBIS 5.1?

James





From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 19, 2012 3:20 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL

James,

You caught me!  … but not quite…

Changing the wording of that sentence to clarify what it says
might be a little different from adding a bunch of technical
details that hasn’t been mentioned in the spec yet.

In the framework of IBIS v5.1, that sentence seems to be sufficient
in what it says.  In v5.1 legacy [Model]-s are two-port blocks
between the signal pad and ground and/or power, but there is no input
to output relationship as in a 4-port.  On the Tx side, [External
Model] is kind of an exception when the external model’s language
can only have analog ports (SPICE and Verilog-A) because these
can have an input port as well, but note that IBIS v5.1 really
doesn’t provide connection access to these inputs to the external
world.  The same is also true on the Rx side.  An [External Model]
Rx might have an output port, but again, IBIS v5.1 doesn’t provide
connection access to this port for the outside world.

The analog model was supposed to be used to generate the impulse
response of the channel and the AMI DLL-s were supposed to be
working with the impulse response of the channel, but not the
analog models in the channel.

I am not saying that these types of flows couldn’t be done in
practice to achieve the same results.  I am just explaining
what IBIS v5.1 says and what is “legally” possible in IBIS v5.1.

Having said all this, I don’t see why there is a need in IBIS
v5.1 to spell out rigorously what the driving and loading
impedances are at that isolation point.  That point is not
available for electrical connections for the user or the model
maker as far as IBIS v5.1 goes.  This is why I thought it might
be “sufficient” as is within the v5.1 framework.


On the other hand, I agree completely that as soon as we extend
[Model] and/or [External Model] to the world of S-parameter
modeling, we will need a more detailed definition for this
boundary.  This is why I wrote BIRD 152 (to accompany BIRD 116).
So your suggestion to write BIRDs to clarify the boundary
conditions has already been taken care of.

The only issue that I see left is the discussion on the nature
of the input port to the Tx [Model]s and the output port of the
Rx [Model]s.  This is a new topic that surfaced after BIRD 116
and 152 were written and submitted, so this topic is not addressed
in them.  I was hoping to have some discussion on that in the
Interconnect meeting today, but we didn’t get to it.

I hope this clarifies the apparent contradiction you found in
my words.

Thanks,

Arpad
===================================================================


From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Wednesday, December 19, 2012 3:42 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL

Arpad,

The comment  of  "that sentence, as it is written today in v5.1 is actually 
sufficient"
seems to contradict with your earlier comment of   "I agree, the wording could 
be better"

It was recommended in yesterday's call  to draft a new BIRD to clarify this 
part of the 5.1 spec. Due to the fact that the work group had spent much time 
debating this issue, using some simple math (which of course we had all failed 
terribly in school) together with word engineering might be the way to go in 
drafting the proposed new BIRD.

James

________________________________

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.

________________________________

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.

Other related posts:

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