[ibis-macro] Re: Analog Buffer Modeling - A Summary
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 20 Jan 2012 08:42:23 -0500 (EST)
Feras,
This is exactly the language I'm having with:
"canned models that are cumbersome and short-lived".
That's a sales and marketing statement, not a technical one, and based on
a number of unstated assumptions:
. Canned models are limiting, because they're fixed
. Canned models are therefore bad
. Bad things are cumbersome
. Bad things are short-lived, because they're cumbersome and
people don't want to use them
I don't really disagree with your conclusions, but the lead-in reasoning
is weak.
Todd.
--
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
<http://www.sisoft.com/> www.sisoft.com
"It doesn't matter what you've heard
Impossible is not a word
It's just a reason
For someone not to try"
-Kutless
From: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx]
Sent: Friday, January 20, 2012 4:37 AM
To: twesterh@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Analog Buffer Modeling - A Summary
Todd,
We all know that technology keeps changing, so why chase it with canned
models that are cumbersome and short-lived! The way to go is by using more
general and flexible modeling approaches.
Specifically, the best way to handle the analog Tx and Rx models that
Walter is proposing is by mapping those to SPICE subckts that are wrapped
in an [External Model], which is the appropriate block for such models,
and then we may add those models as extra EXAMPLES under the [External
Model] section in the IBIS spec. With that we can hit two birds (promote
the general approach and eliminate extra constructs) with one stone (an
example that shows how flexible the External Model construct, specifically
the SPICE wrapper, is).
Best regards,
Feras Al-Hawari
Cadence Design Systems
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Thursday, January 19, 2012 3:15 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer Modeling - A Summary
Ambrish,
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.
--
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com <http://www.sisoft.com/>
"It doesn't matter what you've heard
Impossible is not a word
It's just a reason
For someone not to try"
-Kutless
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Wednesday, January 18, 2012 1:10 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Analog Buffer Modeling - A Summary
Walter,
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 question:
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 norms.
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.
Ambrish Varma | Member of Consulting Staff
P: 978.262.6431 <http://www.cadence.com> 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
To: IBIS-ATM
Subject: [ibis-macro] Analog Buffer Modeling - A Summary
All,
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
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 720.333-1107
Other related posts:
