RE: [IBIS] RE: [ibis-macro] BIRD 122 Sample SPICE Deck posted

Hi Arpad,

Sigrity absolutely agrees with you. We have already learned from history
with IBIS that hard-coded circuits will always hit limitations and tap out
in applicability, as evidenced by the addition of [External Model],
[External Circuit], etc. Standardizing on more hard-coded circuits make
absolutely no technical sense to us whatsoever. Nor does coming up with a
more limited, and redundant way of doing circuit modeling in the AMI space,
rather than enhancing with IBIS-ISS. And keeping a clean delineation between
circuit and algorithmic modeling was a base assumption of the original AMI
spec, and is becoming dangerously blurred in some of the new cases we are
seeing.

Focusing on enhancing circuit modeling to make it more flexible with
IBIS-ISS is the right direction in our opinion, and should much better
position us all to model whatever new circuits are required for the future
IO applications. Define the language and enable the model-makers to model
the circuits they need, rather than define a few hard-coded circuits and
shoehorn everyone into them.

Thanks,
 
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@sigrity.com
 

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi,
Arpad
Sent: Monday, December 20, 2010 4:32 PM
To: ibis-macro@freelists.org; IBIS-users; IBIS
Subject: [IBIS] RE: [ibis-macro] BIRD 122 Sample SPICE Deck posted

Hello Everyone,

Now that we have seen the SPICE netlist of the analog models
of BIRD 122 I would like to make a few comments, raise a
few concerns and make a suggestion.

The introduction section of Algorithmic Modeling in the current
IBIS specification states the following on pg. 139:

"The "analog" portion of the channel is characterized by
means of an impulse response leveraging the pre-existing
IBIS standard for device models."

We are all aware of the shortcomings of IBIS [Model]s, so I
am not going to reiterate them here and argue the need for
improvements. BIRD 122 seems to suggest a solution for that,
but the solution is targeting AMI needs only, and it is
provided as an option: You either go with a less accurate
IBIS [Model] or the more accurate analog parameters contained
in the .ami file.

Pg. 2 of BIRD 122 says:

"Nominally, the simulation uses the traditional IBIS [Model]
data from the .ibs file. This provides the highest level of
model portability between EDA tools but does not always
provide the highest level of simulation accuracy. These
parameters define two additional levels of information
that can be used to model the analog buffer."

The problem I have with this is that the BIRD 122 proposal
does not attempt to solve the real problem, which is the
shortcomings of the IBIS [Model]. BIRD 122 suggests a
solution strictly for IBIS-AMI purposes only and leaves
IBIS modeling untouched. In addition, the suggested solution
in BIRD 122 describes a few pre-defined "special purpose"
circuits which are not accessible to anyone. These circuits
are assumed, which means that they are hard coded into the
AMI engine, they use pre-defined parameters with pre-defined
meaning. This means that no-one can make any changes to the
analog models without changing the specification itself.
Considering that as soon as someone will need to model
something that cannot be described by these hard coded models,
it seems that the BIRD 122 proposal is only a half-baked
temporary solution which does not provide a long term
solution for AMI and does not address any of the fundamental
IBIS modeling limitations at all.

In addition to that, BIRD 122 seems to violate SiSoft's own
recommendations which was posted in a public email on the
ATM email reflector on 12/14/2010 in response to one of my
messages. Mike Steinberger wrote:

"...We need to continually remind ourselves what IBIS-AMI is in
the first place. It's an _interface_ _definition_. That means
that if both the model and the EDA tool comply with the
interface definition, they can communicate with each other
correctly. Period, the end.

IBIS-AMI is not and should not be a specification of
functionality, either for the model or the EDA tool..."

To me, BIRD 122 seems to be nothing but a specification of
functionality for both the model as well as the EDA tool...
All of the discussions (arguments) we have on BIRD 122 in
the ATM teleconferences are happening because we are trying
to define functionality and we are at odds with each other
on the details of that.

The netlist we have seen from SiSoft in the last ATM meeting
indicates that the analog models of BIRD 122 can be described
with IBIS-ISS without any limitations or restrictions. Given
that fact, I do not see why the analog models would have to be
hard coded into the AMI engine and made inaccessible to IBIS.
There is nothing in these netlists which cannot be accomplished
with the proposals in BIRDs 116-118.

In addition, I have demonstrated in BIRDs 116-118 and 125 that
the legacy IBIS [Model] and its package model can be improved
using the IBIS-ISS language in such ways that these improvements
would also be available for AMI purposes. In addition, the
analog model of BIRDs 116-118 is accessible to the model maker
(and user) providing an open and flexible standard which will
be usable in many unforeseen situations in the future without
having to rewrite the specification for each new feature or
capability needed.

Also, BIRDs 116-118 do not define any functionality as far as
I can tell. They describe the interface by which IBIS-ISS
subcircuits can be made work together with .ami and .ibs files.
The rest is up to the model maker. They (should) know which
element in the S-parameter data should be zero or not, depending
on what they put around the S-parameter (ideal source or matched
impedance termination). If some of us feel that model makers
need to be educated in this area, we should do that in a Cookbook,
but not in the specification.

Considering the fact that BIRD 122 needs substantial work to
even just get the figures more understandable and match the
SPICE netlist that we were shown in the last meeting, I would
suggest that we should save SiSoft some time and vote BIRD 122
down in favor of BIRDs 116-118 and 125. After all, these BIRDs
would ensure the highest level of portability AND the highest
level of accuracy WITHOUT having to chose from three different
modeling options and WITHOUT the danger of having to rewrite
the specification in a relatively short time.

Sincerely,

Arpad
===================================================================

-----Original Message-----
From: ibis-macro-bounce@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of Mike LaBonte
Sent: Thursday, December 16, 2010 8:26 AM
To: ibis-macro@freelists.org
Subject: [ibis-macro] BIRD 122 Sample SPICE Deck posted

As promised in the last ibis-atm meeting, the "BIRD 122 Sample SPICE
Deck"
(PDF) from Walter Katz has been posted to the ibis-atm work archive:

http://tinyurl.com/2cqd4zg

Or to avoid tinyurl tracking:
http://www.eda.org/ibis/macromodel_wip/archive-date.html

Mike

---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: http://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@freelists.org
  Subject: unsubscribe

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993