[ibis-macro] Tx and Rx templates, why not?
- From: Feras Al-Hawari <feras@xxxxxxxxxxx>
- To: Todd Westerhoff <twesterh@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 8 Feb 2012 14:08:32 -0800
Todd,
I explained my opinion regarding that many times before, you can review the
previous threads to learn more about that. Here are some reasons:
- IBIS ISS allows us to develop such models and many other models in a
general manner that leaves all the dirty details to the model developer. For
example, till this point Walter is still considering whether to keep or not the
unity gain elements in the templates. He was also asked to consider adding
series resistors to the template. Such templates won't last long as people will
always need to modify/add something to them. So why should we keep running
after these details and then keep changing the spec based on that, especially
when we can save time and effort by putting all of that work in the plate of
the model developer based on the general IBIS-ISS approach.
- Introducing two PCIe-related templates will also open the door to
the introduction of many other templates for all different technologies (DDR3,
USB, etc).
- As technology moves forward, these templates will need to be updated
or even nullified.
Best regards,
Feras
From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
Sent: Wednesday, February 08, 2012 4:48 PM
To: Feras Al-Hawari; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: IBIS Summit
Feras,
And what would your technical reasoning for that be? "Cumbersome" is an
opinion, not a justification.
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: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx]
Sent: Wednesday, February 08, 2012 4:38 PM
To: twesterh@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: IBIS Summit
Todd,
We only support including the [External Model]s for the thevenin and broadband
Tx and Rx as EXAMPLES. Including them as predefined templates and names would
be cumbersome.
Feras
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: Wednesday, February 08, 2012 1:28 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS Summit
Ken,
It seems to me you're failing to distinguish between an approach that allows
pre-defined templates only and an approach that allows a general sub-circuit
but pre-defines common examples for the sake of convenience and automation.
So the question remains - if we go forward with BIRDs 116-118, are you saying
we shouldn't pre-define templates that have proven useful as part of that
effort?
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: Ken Willis
[mailto:kwillis@xxxxxxxxxxx]<mailto:[mailto:kwillis@xxxxxxxxxxx]>
Sent: Wednesday, February 08, 2012 11:42 AM
To: twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx>; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: IBIS Summit
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<mailto:kwillis@xxxxxxxxxxx>
________________________________
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: 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<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 Ken Willis
Sent: Tuesday, February 07, 2012 10:13 PM
To: wkatz@xxxxxxxxxx<mailto: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<mailto:kwillis@xxxxxxxxxxx>
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto: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<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 720.333-1107
Other related posts:
