Subject: Re: [IBIS] Comments on BIRD 75.5, part II [LONG]
From: Ross, Bob (bob_ross@mentorg.com)
Date: Thu Oct 24 2002 - 18:29:44 PDT
Arpad:
The responses here are subject to longer discussions where
a number of technical points need to communicated directy
for full understanding. So my responses here are brief.
Bob
Mentor Graphics
"Muranyi, Arpad" wrote:
>
> 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...
BR - This is where we need to get detailed and specific. There are
some valid reasons for maintaining certain legacy stuff since tools
have relied on it for other reasons. There is an underlying philosphy
that the [External Model] extension be done in a manner almost
transparent with existing IBIS model format to be compatible with
existing EDA tool methodology. The [External Circuit] keyword
allows arbitary departure and expandability in a number of areas.
>
> "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?
BR - Both as needed, and the ibischk4x parser will be used to assist
the model developer.
> 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...
BR - Unfortunately no tool can detect unintended mis-connections.
But the ibischk4x would assist the model developer with unintended
misnamed nodes or missing references (and unintended, hard to
detect deviations from what the model developer thinks is being
modeled) as a first level check. The ibischk4x tool will make
such errors easy to detect and easy to correct at the source,
and your models will be of higher quality.
>
> "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?
BR - Your criticisms are valid. This is a very hard document to produce
for some of the reasons you mention (and the long history of IBIS of
multiple meaning of words such as pin and die identical numbering).
I thought I cleaned up some things. However, as an author there are
things that I may be missing. Lets discuss this some more.
-----------------------------------------------------------------
|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 : Thu Oct 24 2002 - 18:39:30 PDT