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

Arpad,

BIRD 122 clearly defines the need for IBIS to enhance analog modeling for
high speed SerDes (AMI) modeling. There is a clear desire for additional
capabilities for analog modeling by finishing the IBIS ISS specification,
by allowing ISS External Models, and allowing AMI parameter selection to
control External Models. SiSoft has no objection to this approach, as long
as the proposed enhancements in BIRDs 116-119 do satisfy the minimal
requirements described in BIRD 122. SiSoft will like to table any further
discussions and actions on BIRD 122 until closure is achieved on IBIS ISS
and BIRDs 116-119.

Walter

-----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