[ibis-macro] Re: canned circuit models and more
- From: Feras Al-Hawari <feras@xxxxxxxxxxx>
- To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 18 Jan 2012 13:31:03 -0800
Arpad,
Good point! I have to admit that you are a very good reviewer as you won't let
any word go by like that.
Anyways, when I said simple below what I had in mind is that let us keep the
boundaries clear without intermixing the AMI and Analog I/O blocks. While I did
not go deep in my thoughts as you did ...
I have to be careful from now on ;)
Thanks,
Feras
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Wednesday, January 18, 2012 2:30 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: canned circuit models and more
Feras,
I also agree with Ken, and those of you who worked with
me for a while heard me say on multiple occasions that
I am a proponent of defining a flexible modeling language
in a specification as opposed to defining high level
keywords with predefined meaning and functionality. This
is why I was so enthusiastic when the *-AMS languages were
introduced in IBIS, and this is also why I was less excited
about the new AMI portions of the spec which are still
fairly keyword oriented. Anyway, I don't want to rehash
that topic now...
Regarding your sentence:
"So let us keep the IBIS specification simple, generic, and less cumbersome."
I think you probably mean "general" not "generic", but aside from
that I see a contradiction in there. Making something general will
almost automatically mean that it cannot be as simple as otherwise.
Think of a voltage source. The simplest source is a DC source with
a constant value.
V1 n1 GND DC=5
In the beginnings of SPICE you couldn't even write node names with
characters, only numbers, and the "DC=" wasn't there either, just
the number. Some flavors of SPICE wouldn't even allow you to
connect both nodes to any node in the netlist, one had to be GND.
That was simple. But was it general? No, by any means. The
various enhancements added to the various sources were all
complicating the syntax (alphanumeric node names, expressions,
etc...) But most of these complications went in the direction
of generalization, making it more versatile and useful.
Another example is our [External Model]. It was kind of invented
to act as an interim solution to improve the guts of [Model],
but [External Circuit] was supposed to become the "ultimate"
solution to replace the [Model] completely with a more flexible
modeling block. The main reason for this thinking was due to the
limited number of (predefined) supply connections available in
[Model]. We started to see a lot of buffers with more than the
usual power connections (PU, PD, PC, GC), and multiple power
distribution rails on the die. We needed more power nodes,
especially if we wanted include some of the pre-driver effects...
Aside from the fact that the [External ***] keywords didn't take
off for buffer modeling because the *-AMS languages did not
become very popular for that purpose, and the available SPICE
languages are all lacking in their behavioral capabilities for
non-LTI buffer modeling, [External Model] is the simpler version
of the two, and [External Circuit] being the more general one.
But with the recent shift towards LTI buffer modeling, it seems
that even [External Model] is too general in some ways... Ha!
Arpad
=================================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Feras Al-Hawari
Sent: Wednesday, January 18, 2012 10:50 AM
To: kwillis@xxxxxxxxxxx; 'IBIS-ATM'
Cc: Feras Al-Hawari; Taranjit Kukal; Ambrish Varma; Terry Jernberg
Subject: [ibis-macro] Re: canned circuit models and more
Hello All,
I agree with Ken.
I also believe that we should keep clear and defined boundaries between the
various IBIS blocks. As of today those boundaries are very well defined and
make sense. Those boundaries are:
1) AMI block (for algorithmic models encapsulated inside a dll to model CDR or
equalization)
2) Analog I/O block (the analog I/O buffer which can be modeled using the
regular VT/VI curves or using an External Model)
3) Package block (can be defined in an IBIS device or an External Circuit)
The above blocks are contained and provide a lot of generality and flexibility.
For example the proposed analog and broadband Tx and Rx constructs belong to
block (b) above (the analog block) and should not be merged or intermixed with
the AMI block (the AMI block should be kept simple and should contain
algorithmic models only). Also, there is no need to introduce new constructs
and keywords to model an analog or broadband Tx and Rx as such models can be
easily represented using a SPICE like language (e.g., IBIS ISS). The SPICE
model can then be wrapped in a subckt that can then be referenced by an
External Model, which belongs to the most suitable block for such models i.e.,
block (b) above.
So let us keep the IBIS specification simple, generic, and less cumbersome.
Best regards,
Feras Al-Hawari
Cadence Design Systems
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Ken Willis
Sent: Wednesday, January 18, 2012 10:11 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] canned circuit models
Hi all,
There was not a lot of air time to be had on this in the last meeting, so I
wanted to follow up with email. This is just opinion of course. But I think
that canned circuit models are a bad idea for IBIS and the industry. Here
are some thoughts on this.
- 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
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
