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

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <twesterh@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 20 Dec 2012 09:39:54 -0500 (EST)

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] On Behalf Of Todd Westerhoff
Sent: Thursday, December 20, 2012 8:31 AM
To: 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

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 20, 2012 12:49 AM
To: Arpad_Muranyi@xxxxxxxxxx; 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] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 19, 2012 7:00 PM
To: 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]
Sent: Wednesday, December 19, 2012 8:41 PM
To: Muranyi, Arpad; 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] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 19, 2012 5:00 PM
To: 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
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] On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 19, 2012 3:20 PM
To: 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
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