IBISCHK3 Re: Greetings and status

Atul:

I am glad the parser is progressing well. Here are my answers to your
questions. I may discuss some of them at our Friday, January 9, 1998
IBIS meeting and get more input.

I am copying this response to the ibischk-bug reflector for further review
and comments. This is also being copied the ibis reflector for information
and visibility of what is being considered, and also for any additional
input.

Best Regards
Bob Ross
Interconnectix

> Date: Wed, 07 Jan 1998 20:27:11 +0500
> To: bob@icx.com
> From: "Atul P. Agarwal" <atulapt@giascl01.vsnl.net.in>
> Subject: Greetings and status

> Hello Bob

> Wish you a very happy new year. We are progressing fine with
> the parser and here are some queries.

> 1) If a user does not specify all four hysteresis parameters at the
> same time, the spec says that the simulator will ignore them. For
> parsing purposes should this be an error or a warning ?

I vote for Warning, since the simulator should ignore them anyway.

> Similarly, is it OK for the user to specify only Vinl and not
> Vinh and vice versa ?

Yes. The reason that this is OK is that the original "Vinh =" and "Vinl ="
subparameters are still required for Input and I/O model types. These
can serve as a default for values that are not specified. However,
this would not be a recommended practice.

> 2) I am assuming that the Pulse_low and Pulse_high expect at least
> the thresholds or the hysteresis thresholds to be specified, else
> it will be flagged as an error. Is this correct ?

That is correct. However, as noted above, all Input and I/O
models will have a Vinh and Vinl subparameters, even if they are the
default. If Pulse_high and Pulse_low are included in one of the Output
model types which does not have a Vinh or Vinl subparameter,
then it is good to flag this as an error. Either the Model_type
was incorrect, or the Pulse_high and Pulse_low subparameters
were incorrectly entered.

> 3) The spec refers to [End Electrical Description] to terminate
> the EBD model in some places while in other places it refers to
> [End Board Description]. As an editorial change, this should be
> made consistent.

Good Point. I vote for [End Board Description] to be consistent
with [Begin Board Description]. This would be an editorial
change (possibly a BIRD is required.)

> 4) As I mentioned in the previous email, I am checking for
> some relations among the parameters specified under the [Model Spec]
> keyword. For example, D_overshoot_high > S_overshoot_high. To clarify
> this further, this relation will imply

> D_overshoot_high (typ) > S_overshoot_high(typ)

> if D_overshoot_high(min) is SET
> if S_overshoot_high(min) is SET
> D_overshoot_high (min) > S_overshoot_high(min)
> if S_overshoot_high(min) is NA
> D_overshoot_high (min) > S_overshoot_high(typ)

>
> if D_overshoot_high(min) is NA
> if S_overshoot_high(min) is SET
> D_overshoot_high (typ) > S_overshoot_high(min)

> if D_overshoot_high(max) is SET
> if S_overshoot_high(max) is SET
> D_overshoot_high (max) > S_overshoot_high(max)
> if S_overshoot_high(max) is NA
> D_overshoot_high (max) > S_overshoot_high(typ)

>
> if D_overshoot_high(max) is NA
> if S_overshoot_high(max) is SET
> D_overshoot_high (typ) > S_overshoot_high(max)

> Similar checks will be done for other relationships among the
> [Model Spec] parameters.

This looks OK to me. A Warning should be issued if there is a violation.

> 6) I have assumed that a [Model Selector] name cannot be a reserved word
> or the same as a model name defined in the file. Perhaps this should also
> be highlighted in the document.

Correct, the [Model Selector] name shall not be [Model] name nor shall it
be any reserved word. This would be an Error.

We have had a discussion
in the past whether any of the models listed in the first column of
[Model Selector] could be any of the reserved words - such as NC or GND or POWER.
This should probably be allowed since these are allowable models. It
is conceivable for buffers to be switched in a disconnected mode or connected
to a fixed voltage for some configurations. Simulators may have difficulty
in dealing with this type of flexability since power/ground nets can operate
under different rules than signal nets, and having switchable topology
can introduce major complications for this additional feature.

One real functional extension beyond this which is not supported by IBIS
Version 3.0/3.1 is
using such a feature to convert differential pins into a single-ended
configuration. However the [Diff Pin] keyword itself was never intended
to create a diffential model using one side a reserved word model (GND or POWER).

> 7) Are there any special semantic checks for the models/information
> specified under the [Driver Schedule] keyword besides those specified
> in the document ? For example, the spec states that the models
> under the Driver Schedule are typically Open Sink (Open Drain) or
> Open Source. Should there be any such checks ?

Not at this time. I do not think we need to add such restrictions
since the "next generation" ideas could invalidate them. Also
totem devices with one side very weak would be a practical possibility.

> Thanks
> atul

 
Received on Wed Jan 7 11:34:17 1998