[ibis-macro] Re: Analog Buffer Modeling - A Summary

  • From: <fangyi_rao@xxxxxxxxxxx>
  • To: <twesterh@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 19 Jan 2012 23:27:41 -0700


Model developers can use template model for any fixed topology. It's the same 
workload as using canned model.


From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Todd Westerhoff
Sent: Thursday, January 19, 2012 12:15 PM
Subject: [ibis-macro] Re: Analog Buffer Modeling - A Summary


I believe your claim is indefensible.  None of us know what's going to happen 5 
years from now, so let's not assume that we can architect for future needs, 
even if we want to.  While it's certainly true that the Touchstone file (BIRD 
144 included) and Walter's Thevenin circuit are fixed-topology approaches, the 
issue of model complexity, cost and reliability is consistently getting 
overlooked in this thread.

The "general approach is better" argument neglects the fact that the model will 
have more moving parts (subcircuit netlist(s), wrapper(s), control file(s), 
etc.) that have to be developed, validated and deployed together for the model 
to do what it's supposed to do.  There are real costs associated with increased 
model complexity: additional model developer time, users ensuring that they 
have all the model pieces plugged into the simulator correctly, EDA vendors 
supporting additional syntax, and so on.

In a perfect world, we could make models arbitrarily complex and everything 
would just be plug and play.  It's a computer, right?  Who cares how hard the 
computer has to work to pull the pieces together?   In my day to day 
experience, we're a long way from there.  I see plenty of model portability 
issues with just the .ibs, .ami and .dll files we have now.

Don't get me wrong - I don't have a problem with a general purpose subcircuit 
syntax.  What I do have a problem with, is pitching it as a panacea without 
considering the additional workload it places on models developers and end 
users.  This isn't a black or white thing - it's a tradeoff thing, which needs 
consideration and balance.

My $0.02.



Todd Westerhoff
VP, Software Products
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24

"It doesn't matter what you've heard
  Impossible is not a word
  It's just a reason
 For someone not to try"

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Ambrish Varma
Sent: Wednesday, January 18, 2012 1:10 PM
Subject: [ibis-macro] Re: Analog Buffer Modeling - A Summary

I am very intrigued by questions 5 and 6. The answers to both the questions can 
be a 'No' today but the real question back to you is
A) Can you say for sure that 1, 2, 5 years down the road, we will not need new 
reserved models to describe the new analog LTI circuit of the times?

I suspect the answer to that question would be a 'No' as well. Hence the next 

B) Is it better to propose language that works today, and work 1, 2, 5 years 
from now as well, or is it better to take short cuts today, and worry about the 
future when we come to it?

We are trying to write an Industry Standard that should encompass short term 
and long term goals and not merely writing specifications to satisfy existing 

It seems to me more and more that AMI_Thevenin_Tx, or AMI_Thevenin_Rx should be 
examples in the Standard, rather than the Standard itself. As for 
AMI_Tstonefile_Tx, AMI_Tstonefile_Rx, these keywords are AMI centric and can 
very well be replaced by a general solution as proposed in other BIRDs.

Thanks and Regards,


Ambrish Varma   |  Member of Consulting Staff

P: 978.262.6431   www.cadence.com<http://www.cadence.com>

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
 On Behalf Of Walter Katz
Sent: Wednesday, January 18, 2012 12:36 PM
Subject: [ibis-macro] Analog Buffer Modeling - A Summary


I will attend next Tuesday's meeting and will be prepared to discuss the 
following. I will also be prepared to make a presentation to the IBIS Summit on 
any of the following that you do not agree with:

1.       LTI vs Non-LTI Modeling

a.       I will propose that we table any IBIS-ATM discussion until someone can 
present to IBIS a Channel that:

       i.      Channel

1.       A real IC Vendor SerDes Tx and Rx buffer

2.       A real Tx and Rx Package

3.       A real interconnect

     ii.       When analyzing the Channel using

1.       Non-LTI Vendor Models

2.       An LTI approximation of the Models

    iii.      Give results that are different enough to cause the design 
engineer to make substantively different design decisions.

2.       Can anyone provide an IBIS SerDes Tx and Rx Buffer that has a constant 
impedance over the operating range of the Buffer that cannot be accurately 
represented by either the proposed AMI_Thevenin_Tx and AMI_Thevenin_Rx model? 
Please note the following subtle limitation of BIRD 116 described in 3.

3.       [External Model]/Language ISS assumes that the Analog Model LTI. 
Therefore any Non-LTI affects that are caused by time variation that is 
captured in the IBIS Rising and Falling Waveforms. The only way to handle this 
is to change the D_to_A to contain a PWL.

4.       Can anyone provide an ISS subckt that represents a Tx or Rx ISS SerDes 
buffer model that cannot be converted to an accurate Touchstone file?

5.       Can anyone point to an industry standard SerDes specification (e.g. 
PCIeG3, PCIeG4, IEEE 802.3 bj, ap, kr) that does not specify constrains on the 
analog behavior that cannot be represented by the proposed AMI_Thevenin_Tx and 
AMI_Thevenin_Rx model?

6.       Does anyone disagree that any Tx or Rx analog LTI model can be 
represented by one of the proposed models ( AMI_Tstonefile_Tx, 
AMI_Tstonefile_Rx, AMI_Thevenin_Tx, or AMI_Thevenin_Rx model?


Walter Katz
Phone 303.449-2308
Mobile 720.333-1107

GIF image

GIF image

Other related posts: