Subject: RE: [IBIS] Comments on BIRD 75.5, part II [LONG]
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Tue Oct 22 2002 - 08:43:30 PDT
Bob,
I am sending a few comments on this one too
similar to the previous one.
Arpad
=============================================
-----Original Message-----
From: Ross, Bob [mailto:bob_ross@mentorg.com]
Sent: Friday, October 18, 2002 8:25 PM
To: Mirmak, Michael
Cc: 'ibis@eda.org'
Subject: Re: [IBIS] Comments on BIRD 75.5, part II [LONG]
"A reason for maintaining legacy rules is for simplicity, consistency,
and ease of understanding. There are several cases where a simple,
absolute rule is used that may force some extra entries, than a rule that
goes through a large number of tests and conditions. So C_comp and
[Ramp] are required for simplicity as in existing IBIS.
It turns out that the [Ramp] requirement is maintained even with
external models because several EDA tools have relied on it
for timing test load simulation time estimations. So it is
there for informational reasons when not needed for actual simulations."
AM: The value that goes into the [Ramp] keyword can be easily extracted
from other information in a model. For example, if there are waveforms
in the model, one can find the 20-80 % points on them, and read off the
dV and dt values. It is that simple. So when we wrote the IBIS 2.1
specification we really had no reason to make it required, even if the
tools didn't support waveforms in their simulation algorithms. Now we
are stuck...
"You are correct. The reason for putting it in is for better error
checking and more robust code development methodology. Some other
areas in IBIS have redundant information that is useful for
checking (such as naming pin names in [Package Model]. The [Node
Declarations] keyword could be made optional or removed. However,
unintended misnamed nodes or dangling nodes might be very hard to
discover in a large file. So the choice is to make it required
for robustness and checking reasons."
AM: Error checking on who's part? The model maker or the tool?
Me as a model maker will now have to check my own work for the
possibility of making more errors, in making inconsistent node
declaration lists. So my work goes up, the tool's work goes down.
This is not exactly user friendliness...
"Your suggestions are excellent. I wish I had the time and energy to to
this. The existing organization has evolved over time as many issues
were presented and discussed. It was designed to introduce a lot of
detail in gradual steps. It does not have an overall context paragraph
or two, but does introduce a lot of technical content from models,
circuit, interconnections, and then more detail in all areas. I agree
that the presentation, in retrospect, could be improved. The same
applies to the IBIS document in genera. However, I am more focused
with getting technical agreement so the technical contents can be
stabized. I am not sure I am able to capture the overall flow in
just one or two paragraphs."
AM: The problem is general readability. Just yesterday I was trying to
look up what the [Circuit Call] does. Wanted to understand the meaning,
and usage of the "Signal_pin" subparameters. The BIRD goes straight into
the ifs and buts and technical details on them, but doesn't tell me what
is, and what it really is used for. This is generally true for many
of the keyword and subparameter descriptions in the BIRD. The reader
barely gets any overviews or definitions. I still don't see any definitions
for "Port", "Node", and "Terminal". I know they are not, but they seem to
be used arbitrarily in some places. As a reader, I just don't know what I
am reading. It takes too many reading, and to much reverse engineering in
my mind before I BEGIN to understand what is going on. And I am supposedly
an IBIS expert. What are those going to get out of reading this who are
just starting out making IBIS models?
============================================================================
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.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 email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Tue Oct 22 2002 - 08:49:56 PDT