[ibis-macro] Re: IBIS Summit
- From: "Ken Willis" <kwillis@xxxxxxxxxxx>
- To: <twesterh@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 8 Feb 2012 11:41:50 -0500
An excerpt from my Jan 18th post on this is below:
- historical perspective
Think back to the original IBIS spec. Basically, a canned circuit model for
IOs was defined. It was very successful, and covered everything that
engineers thought they wanted at the time. But technology progresses, things
evolve and change, and new requirements surface. More and more keywords
needed to be added, as well as more complexity, and resulted in more churn
on the spec (more on this aspect later). Eventually it was decided that if
we could just define a common circuit description language with External
Model/Circuit, we could define any circuit that was needed, and the spec
could stabilize. Finally we realize that Spice is that common language (not
Fork/End Fork for example), and ISS support got added. To me, that should be
pretty much it for circuit modeling.
So the lesson here is that canned circuit modeling runs out of gas no matter
how forward thinking you try to be. This has already been observed once. You
either result in keyword explosion to try to keep up with requirements, or
you define a general language you can use to describe any circuit you need
to. It seems to me the smart approach now is to learn from that and just
define the general language.
- spec churn
Going with canned circuits results in spec churn, period. You either have to
add keyword after keyword, or you have to continually add new canned
circuits to the spec each release. It's the same thing. The resulting churn
leaves model developers, EDA suppliers, and end users constantly chasing the
spec. That is bad for everybody, as it is a tremendous waste of resources.
And completely redundant with a general solution. Stability of the spec is
highly desirable, as end users just want to drop compliant models into
compliant tools and plug-n-play as they wish to get their job done. This
doesn't happen when the spec is in constant flux and everyone is chasing it
on different schedules. Think of measuring the quality of the spec by the
rate at which it needs to be modified.
- circuit modeling not just for AMI
SerDes IBIS-AMI models have 2 parts; IO circuit models and on-chip
algorithmic models for EQ. The circuit model part can come from general
IBIS, and I think the main focus of this sub-committee should be on the
algorithmic part. There is more than enough to do there. But somewhere along
the way the tail started to wag the dog, and proposals started to outline
AMI-specific circuit modeling. Again, I think this is a bad direction. The
algorithmic modeling needs focus, as things are changing there rapidly, and
links to the associated circuit models are absolutely needed. But I don't
like the direction of AMI-specific circuits. Again, a more general solution
for circuit modeling will be much more efficient and serve the industry much
better in the long run.
So, in a nutshell, some basic ideas:
- canned circuits is a bad direction in general
- AMI-specific circuit models falls into that category
- more general solutions where possible and less spec churn is desirable; we
will create enough churn just keeping up with the algorithmic model
requirements
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
_____
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Wednesday, February 08, 2012 8:21 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS Summit
Ken,
What's your reasoning here? The conclusion seems to be "pre-defined
templates are bad", but I don't understand the reasoning behind it.
I can explain why we're advocating for pre-defined templates - if we can
agree on a few cases that address most I/O circuits, we can create tools
that automate the extraction and generation of data for those sub-circuits.
In our experience, automation breeds consistency breeds quality, because we
eliminate manual steps. Computers don't get tired or distracted.
So I ask, what's wrong with that? We're not suggesting limiting the ability
to create new sub-circuits in any way, we're just advocating that we start
with a few that have proven useful in practice.
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 Ken Willis
Sent: Tuesday, February 07, 2012 10:13 PM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS Summit
Hi Walter,
Unfortunately, I had to drop off the call today after about 45 minutes,
right when you were getting to the end of the presentation. I was with you
until slide 19:
- SiSoft would like BIRDs 116 and 118 to include a shortcut syntax for these
four models
"Shortcut syntax" brings us right back to "canned circuit models", which I
still don't agree with.
Putting these models into the spec as examples in standard syntax makes
perfect sense to me. I think we should move forward with that.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
_____
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
<mailto:%5bmailto:ibis-macro-bounce@xxxxxxxxxxxxx%5d> On Behalf Of Walter
Katz
Sent: Monday, February 06, 2012 12:11 PM
To: IBIS-ATM
Subject: [ibis-macro] IBIS Summit
All,
Here are my take-aways as it affects the IBIS-ATM committee.
A Tale of Two Parsers, Bob Ross (Teraspeed)
The IBIS 5.1 .ami parser will only check IBIS 5.1 rules (with some special
code for AMI_Version, and Use_Init_Output).
The IBIS 5.1 .ibs parser will only check IBIS 5.1 rules. To me, this means
that if a .ibs file is Version 3.2, it will not generate any warnings or
errors for IBIS 5.1 keywords.
A System Developer's Perspective on AMI, Greg Edlund (IBM)
This presentation, and the DesignCon Tutorial (8-MP2 AMI Models: How to tell
a Peach form a Lemon) will be an excellent resource for the IBIS Quality
Committee.
Using Function Programming Languages to IBIS AMI Modeling, David Banas
(Altera)
If you close your eyes, you do not have to imagine any changes to the IBIS
Specification to reflect AMI DLLs written in Haskell.
Case Study: IBM 15 Gb IBIS-AMI Model using Dependency Tables, Adge Hawes
(IBM), Walter Katz (SiSoft)
An excellent example of the significance of BIRD 150 (Dependency BIRD) to
AMI Model developers.
Efficient End-to-end Simulations of 25G Optical Links, Sanjeev Gupta
(Avago), Fangyi Rao (Agilent)
The AMI optical link model used Repeaters as described in BIRD 131, with
some possible extensions. SiSoft requested that Fangyi describe any
enhancement that are required to BIRD 131 in order for SiSoft to run these
models.
How did we get here, and how should we go on?, Arpad Muranyi (Mentor)
An excellent presentation that accurately describes the status of BIRDs 122,
116, 117, 118, 129, 144 and 145. Based on discussions I had earlier in the
week with Fangyi, Vladimir, Ambrish and Kumar, I re-affirmed that SiSoft is
is full support of BIRD 117 and 118, with details in my following
presentation.
Ad Hoc Discussion: BIRD116 and "Intrinsic Models", Walter Katz (SiSoft)
I verbally gave the enclosed presentation, which describes the four BIRD 122
Analog models converted to BIRDs 116 and aa8 [External Models]. In summary,
when IBIS 5.2 (BIRDs 116 and 118) is approved, SiSoft will produce AMI
models using this [External Model] format. I believe the only controversial
issue regarding these four BIRD 122 Analog models is the requirement of a
termination resistor for the AMI_Touchstone_Rx. I have added termination
resistors with a value RTref (default 50), which satisfy the needs for
Channel Analog simulators that use S-Parameter arithmetic or a SPICE step
response simulation to generate the Channel Impulse Response. When BIRDs 116
and 118 are approved by the Open Forum, SiSoft will publish to IBIS these
four [External Model]s.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 720.333-1107
Other related posts:
