[ibis-macro] Re: Analog Buffer Modeling - A Summary
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 23 Jan 2012 20:23:54 +0000
Todd,
Sorry for the slow response...
Your statements come across a little over-reactionary...
Let's try to be a little more factual and reasonable.
The first statement is true. Canned (hard coded) models
are indeed limited as compared with a general solution.
However, this does not equal "bad", and I don't remember
anyone saying that. They may not be as versatile or
useful as the general models, but they do have advantages
too. Technical and practical.
On the practical side we all know that it might be easier
to make models using canned, assumed circuits. We also
know that the EDA tool can make good use of the
assumptions for improving the performance of the tool.
The bad part comes in when we consider the useful life of
these hard coded models. No one can predict exactly when
these will run out of steam, or of they will run out of
steam, but they might.
Is it worth defining them in the spec, knowing that they
may be relatively short lived? Is it not going to be more
confusing to model makers to have multiple options to do
the same? Is it not going to be too expensive for the
IBIS parser? Are we going to be able to deprecate them
when they become useless, or are we going to have to carry
them around forever in the spec? This is where the
"cumbersome" feelings might be creeping in...
An example comes to my mind to illustrate this: Think of
a car vs. train. A train has hard coded routes, schedules,
while a car can almost go anywhere any time. No wonder
cars are more popular than trains. But a train can go
faster, you can rest on it while you travel, go to the
dining room, or rest room without stopping on the way, etc...
but when you depart and arrive you have to rent a car or
have someone pick you up, etc...
At some point we discover that we can do it better, so we
invent the airplane. Now we can travel even faster and
longer distances. We can even cross the oceans. Can we
get rid of the train? Can we get rid of the car? No.
Life just got more complicated. Was it worth it to invent
the train and the airplane? I guess we can all say yes
in this case, but are the benefits that clear in the IBIS
specification?
Thanks,
Arpad
=============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Todd Westerhoff
Sent: Friday, January 20, 2012 7:42 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer Modeling - A Summary
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<mailto: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: Feras Al-Hawari
[mailto:feras@xxxxxxxxxxx]<mailto:[mailto:feras@xxxxxxxxxxx]>
Sent: Friday, January 20, 2012 4:37 AM
To: twesterh@xxxxxxxxxx<mailto: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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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<mailto: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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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.
[cid:image002.gif@01CCD9D7.BE173610]
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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 720.333-1107
Other related posts:
