[ibis-macro] Re: BIRD-124: Dependency tables - question?

Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC

Arpad,

 

You said the following statement is simply wrong “IBIS fundamentally does not have the ability to represent broadband differential drivers or receivers”

 

I cannot disagree with you more. How can IBIS today support broadband differential models.

 

I agree that RC circuit is not necessarily more accurate that using IBIS IV and VT curves, but the statement I made was

 “the (IBIS v-i/v-t model)  has been proven to be an inaccurate representation of high speed SerDes devices”

 

And I made this statement as another way of saying that these do not support broadband models.

 

Please let me know if there is something that have been missing all these years and that IBIS has been able to support broadband buffer models. If so, please give me an example of an IBIS file that supports broadband buffer models.

 

Walter

 

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, January 19, 2011 11:57 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?

 

Walter,

 

I understand that you are not a big fan of IBIS I-V/V-t [Model]s,

but please do not make it look worse than it is.

 

“IBIS fundamentally does not have the ability to represent broadband differential drivers or receivers”

 

This statement is simply wrong.  This is almost like saying that

behavioral modeling fundamentally cannot model high frequency stuff.

I agree, IBIS does have limitations as it stands today, but these

limitations are not fundamental to IBIS because it is IBIS.  These

limitations are there because we didn’t provide the necessary

keywords to let it happen.  However, as you can see in BIRDs 116

and 125, these limitations can be removed relatively easily from

IBIS.

 

“Opal, and BIRD 122 describe a simple parameterized generic buffer model that does a sufficient job of describing many SerDes Tx and Rx buffer analog models.”

 

You seem to be saying that the RC model defined in Opal (and BIRD 122)

does a better job than the IBIS I-V/V-t curve based [Model].  Taking a

better look at the circuit:

 

 

I must tell you that there is nothing in this circuit that a legacy

IBIS [Model] cannot do.  The Voh, Vol, Vt parameters can all be

modeled with the various I-V curve reference voltages.  Tf, Tr

can be modeled with [Ramp] or the V-t curves.  Rt can be modeled

with any of the clamp I-V curves.  Rs can be modeled with the

PU or PD I-V curves.  Cc can be modeled with C_comp.  Rd and Cd

can be modeled with the [R Series] and [C Series] keywords.

 

“the (IBIS v-i/v-t model)  has been proven to be an inaccurate representation of high speed SerDes devices”

 

Show me the proof that the above RC circuit is more accurate than

a legacy IBIS [Model].  As far as I can tell, you are not going to

be able to do that because they are equivalent…  I agree that the

S-parameter version may give you a more accurate “broad band” model,

but IBIS can be fixed easily, as proposed in BIRD 116 and 125.

 

Sincerely,

 

Arpad

====================================================================

 

 

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, January 19, 2011 7:55 AM
To: kukal@xxxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?

 

Kukal,

 

There are two fundamental things going on here. First, IBIS fundamentally does not have the ability to represent broadband differential drivers or receivers. More important to your question is the fact that SerDes drivers (and to a lesser extent receivers), are configurable. They contain registers that control equalization, strength and drive impedance. Each configuration of the buffer, particularly when modifying the strength of the Tx, changes the impedance (i/v) of the buffer.

 

There are two choices, the first is to use a model selector and a large number of IBIS models, each one pointing to a different .ami file configuration. This become rapidly unwieldy, and uses v-i/v-t models that are demonstrably inaccurate for SerDes AMI buffers. So it is only natural that when the buffer programming (as defined in the .ami file)  is chosen, the .ami file must determine the analog model that the EDA tool must use to determine the impulse response of the channel.

 

Opal, and BIRD 122 describe a simple parameterized generic buffer model that does a sufficient job of describing many SerDes Tx and Rx buffer analog models. The broadband (Touchstone) buffer model, an alternative option described in Opal and BIRD 122 is a more accurate representation of SerDes Tx and Rx buffer analog models. BIRD 124 is a method that we and several IC Vendors came up with that documents to the EDA tool how the Touchstone file, or the values of the parameters that control the generic buffer model.

 

The short answer is that the selection of values of .ami parameters determine the analog model that the EDA tools needs to use to generate the impulse response of the channel. This is uncontested, and accepted by the IBIS-ATM committee.

 

If you believe your tool can give more accurate results using (IBIS v-i/v-t model) then BIRD 124 allows you to do that by letting you use the reserved dependency table “In” or “Independent” parameter [Model]. A simple example is a Tx model that had an AMI parameter “Strength” that has 128 allowed values (0:127).  IBIS file can have a model selector for this Tx buffer with [Model] Tx_0 to Tx_127. The dependency table would have two columns [Model} and Strength. The user can select a specific [Model] (e.g. Tx_107), and the dependency table would map that into Strength 107.  BIRD 124 does support his flow, but we very much do not recommend it because the (IBIS v-i/v-t model)  has been proven to be an inaccurate representation of high speed SerDes devices.

 

Walter

 

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal
Sent: Tuesday, January 18, 2011 10:57 PM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?

 

Hi Walter,

I am confused here. The parent is the IBIS model and has a pointer to AMI dll (Child) - the association is fixed - so how can AMI dll decide the analog-IO model that needs to be picked. Please explain with an example/flow-steps on how the analog model (IBIS v-i/v-t model) would be registered.

 

rgds

..kukal

 

 

---

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, January 17, 2011 8:26 PM
To: Taranjit Kukal; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question?

Kukal,

 

Your first sentence is not correct, it should have said:

 

“Looks like the Intent is to associate Analog IO model (different IO-model strengths) to AMI-parameter so that correct Analog IO-model is picked when s specific portion of  AMI-code gets executed.”

 

Point being that the user configures the registers in a model, and that the registers in the model not only determine how the algorithmic model works but also determine the analog model needed to generate the impulse response of the channel for the algorithmic simulation.

 

Walter

 

 

From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx]
Sent: Monday, January 17, 2011 9:17 AM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question?

 

Hi Walter,

Help me understand this further. Looks like the Intent is to associate Analog IO model (different IO-model strengths) to AMI-parameter so that correct portion of  AMI-code gets executed according to Analog IO-model that is picked.

 

However, what I fail to understand is that how this association gets utilized. If the user has to manually set a Key-parameter as per the IBIS buffer-strength to allow picking of dependent parameters then why are not let ami-code do it (Let tables be coded inside of AMI dll).

 

To me, it looks like "Good to have" rather than a real need. Please explain with small example if I am missing the point.

 

rgds

..kukal

 

 

---

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, January 13, 2011 8:32 PM
To: Taranjit Kukal; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?

Kukai,

 

The impulse response of the channel must be determined before the AMI DLL is called. The AMI file contains the switches that program the Tx or Rx model. The value of these switches determine the analog model of the driver that is required to determine the impulse response of the channel.

 

Walter

 

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal
Sent: Thursday, January 13, 2011 2:11 AM
To: IBIS-ATM
Subject: [ibis-macro] BIRD-124: Dependency tables - question?

 

Hi,

The dependency tables would be useful only if we want to keep same AMI-code (dll) and just change the dependency outside of the code using .ami file.

 

However, I do not see this as common use-model - I would assume that all such dependency should be handled inside of c-code (Algorithmic...) and that we should avoid overloading of .ami file such tables. AMI-code should be able to handle such dependency by coding the right values for dependent parameters based on Key parameters in ami file.

 

Please let me know if I am missing a use-case where this cannot be handled inside the dll.

 

rgds

..kukal

Taranjit Kukal | Product Engineering Architect

P: 91 120 3984000   www.cadence.com