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

  • From: James Zhou <james.zhou@xxxxxxxxxx>
  • To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 18 Dec 2012 23:06:51 +0000

Arpad,

Based on recent emails and today's call, the following two issues are to be 
treated separately:
(1) clarification of IBIS 5.1 on impedance conditions
(2) future enhancements of IBIS 5.1 on impedance conditions

The action item from the call is to create new BIRD(s) to address these topics. 
I can create a draft doc and send to interested parties for comments.

Your comments touched upon another topic (albeit related) involving D_to_A 
converter and legacy IBIS syntax for AMI modeling. Michael's comments today are 
mostly applicable to this subject. I think we need to get more details on this 
topic from Michael and interested parties before attempting to draw a 
conclusion.

James







From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Muranyi, Arpad
Sent: Tuesday, December 18, 2012 1:37 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL

James,

Regarding the “remaining issue”, the problem is this:
The IBIS v5.1 specification describes the analog model
with [Model], and currently the specification has no
support for S-parameter models.  Even if you used the
more elaborate capabilities of [External Model] inside
[Model], the isolation point is a D_to_A converter.
So that sentence, as it is written today in v5.1 is
actually sufficient in light of what you can put into
[Model].

The problems you are describing with the models you
received from the vendor seem to be related to the
usage of modeling techniques in the analog model which
are currently not supported by the v5.1 specification.
So your question about how to handle the situation as
far as specification enforcement goes is a moot point.
The model doesn’t seem to be IBIS compliant either way.

What we should be extra careful about is how we address
these issues in the upcoming version of the specification
in which I expect that we will have a lot of new analog
modeling capabilities and/or improvements.  We will have
to define this isolation point more carefully to avoid
any ambiguities related to the new capabilities.

Thanks,

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


From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Tuesday, December 18, 2012 2:32 PM
To: fangyi_rao@xxxxxxxxxxx; Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL

Fangyi,

Thank you very much for the clarification. We have so far reached agreement on 
the interpretation of this part of the 5.1 Spec.

Now the remaining issue is that some models we have obtained from reputable 
ASIC vendor(s), created by reputable EDA tool vendor(s), simulated using 
industry leading EDA tool(s), do not follow this convention. It has caused a 
great deal of confusion in the field. I think the ATM work group needs to know 
this and decide what to do (or what not to do).

One approach is simply to dismiss those models that do not follow this 
convention. This approach hardly works in the field. Any problem of such nature 
are always chased down and resolved in the end, involving multiple parties. For 
example, we received two AMI models from the same ASIC vendor, one assumes a 0 
ohm source impedance, the other assumes a 50 ohm source impedance. None of 
these are explicit documented by the ASIC vendor. And you can imagine what 
happened next and the due process to resolve the issue.

An alternative approach is, instead of imposing an assumption on the impedance, 
simply just do not make any assumptions and let the model maker use any 
impedance of their choosing (of course it has to be made available to the EDA 
tool). I personally think this is a much better approach, due to its clarity, 
simplicity and minimal impact to existing 5.1 spec.

James


From: fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx> 
[mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Tuesday, December 18, 2012 12:06 PM
To: James Zhou; Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>; 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL

Hi, James;

Regarding your question of

The following statement,

“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”

has a serious ambiguity which is the root cause of the confusion. At the 
interface of core (i.e. Tx AMI block) and analog circuit (i.e. Tx analog), 
there are two impedances, one is the output impedance of the AMI block and the 
other is the input of the analog clock. The wording in the spec did not say 
which is which. Are they both high impedance or only one of them is high 
impedance, and which one?

I agree that the current statement in the spec is not entirely clear. I think 
the correct wording should be:

Looking from Tx analog portion, Tx algorithmic portion is an ideal voltage 
source (with zero impedance). Looking from Rx analog portion, the Rx 
algorithmic portion has infinite load.

Maybe we should make the correction in the next IBIS release.

 Regards,
Fangyi

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, December 17, 2012 10:47 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL

James,

I wasn’t disputing those +/-1 and 0 values, although I
must admit that I didn’t verify whether they are correct
or not.

I have a hard time to understand what you are really
talking about because of the words you are using: “source”
and “sink”.  For example, on slide 2, 2nd bullet says:


“Block A is the signal source…”



Here I am starting to wonder, are you talking about the

ideal voltage ***source*** that acts as the stimulus for

the Tx analog model or are you talking about the Tx analog

model itself?  (We usually refer to this as the analog

driver model in our conversations).



Same problem with the 4th bullet:



“Block E is the signal sink…”



I wonder why you are not using our usual terminology for

this which is Rx analog model (if that is what you are

talking about)?  This made me wonder whether you might

be using different words because you are not talking about

the Rx analog model but say an ideal probe somewhere in

that area.



But let’s put this uncertainty behind, and based on your

last email let’s consider block A the Tx analog driver model

(made up of PU and PD I-V curves and [Ramp] or V-t curves

and C_comp) and block E the Rx analog receiver model (made

up of clamp I-V curves for on-die termination and C_comp).

On slide 7 you state that there is an assumption in IBIS AMI

that the output of the Tx analog model has zero output impedance:



“Signal source has zero output impedance (Sa= -1)”



and that the input of the Rx analog model has an infinite

input impedance:



“Signal sink has infinite input impedance (Se= 1)”



I am not aware of the IBIS specification making such assumptions

or having talked about needing to have any such assumptions in

any of the meetings for the analog Tx and Rx models which are used

with AMI models.  If I understand you correctly, you are incorrect

making this statement.



If I remember correctly, your response to my email in which I said

that was the quote from Section 6C in the v5.1 specification:


“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”

but this sentence has nothing to do with the output of the Tx
analog buffer model and the input of the Rx analog buffer models.
I explained that quoted sentence saying that it refers to the
location between the core and the input to the Tx analog buffer
model and the location between the output of the Rx analog model
and the core (where core really means the EQ, DFE, CDR, etc...
logic, i.e. AMI algorithmic model).  That’s where you would need
to have +/-1-s and/or zeroes in your S-parameter model if you
happen to use currently non-IBIS-compliant methods to describe
the Tx analog buffer model or the Rx analog buffer model with
S-parameters.

So the assumptions you are talking about on slide 7 might at best
refer to the assumptions made at that boundary location, but not
to the boundary conditions at the Tx and Rx pad.

Now, having said all this, the specification doesn’t prohibit
making an analog Tx [Model] that has a (close to) zero impedance
output and put some sort of an impedance model in front of it
(to basically formulate a Thevenin ideal source and series
impedance model for your driver) in some way of shape and form.
But if you did that you will have to end up twisting the IBIS
specification a little, because strictly speaking, according to
the specification you have [Model] and then [Package].  When
making such a model you would have to implement the (close to)
zero impedance I-V curve in [Model] and implement the impedance
of that Thevenin circuit in the [Package].  I have seen it done,
but again, it is not IBIS compliant…

Please explain how am I misinterpreting your slides if I am wrong
with the way I read them…

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

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

Hi Arpad,

Your impression that I am "misinterpreting (and consequently misusing) that 
quote from the v5.1 spec",  is possibly due to your misinterpretation of my 
interpretations of IBIS 5.1.

With reference to "because there is a good isolation between them (core and 
output stage)", this is to say that Sb12=0 (in my slides). If this is 
incorrect, what value should it be set to?

With reference to "in the Rx, the output of the analog receiver stage 
(termination, amplification, etc…) and the core logic are isolated well enough 
so that the core logic doesn’t alter the behavior of the stuff that is in front 
of it" . This is equivalent to set Se=1 in my slides. If not, what value should 
it be?

This issue is one of the examples that  words themselves are not enough to 
produce a unique answer. A little bit of  simple math could help to make things 
clear. After all, none of the EDA tools compute the results in English anyway.

It has been said many time and again, the proposed scheme is a simple but 
important enhancement of IBIS 5.1. We all know that IBIS 5.1 does not support 
analog models inside AMI blocks and the proposal is to lift that restriction 
without  disruption to the 5.1 AMI flow, and can be done at very small 
computational and algorithmic cost, as shown in my slides.

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.

________________________________

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: