Subject: To bird or not to bird ...

From: [email-masked] (Bob Ward)
Date: Mon, 21 Mar 94 8:05:53 CST

Hey, Ibis guys!

I have been reading the accumulated mail from the past couple of days and see a
thread about whether or not to change the parser for the current sign problem
without a full blown bird.  After thinking about it, it would seem a fairly large
departure from "policy" to do that.  But since I agree with Kellee that _something
is needed here, how about a stand alone utility to check this until we can fully
hash out a bird? ( Hatch out a bird? )  Seems it should not be too mch harder to 
write this than to write the changes into the parser ( He says! ).  Just a
thought ... I defer to the group to determine how good a thought it is.

Thanks,

______________________________________________      ____________________
|                   | Seeking to return to    |    /  __________________O
| Bob Ward          | the North Country, MN,  |   /  /|________________
| [email-masked] | WI, ND, SD, or MT. Also |  /  /_/________________O
| 713.568.4122      | considering Mtn. West.  | /_____________________
|___________________|_________________________| |_____________________O

---

From: "Hobbs, Will" <[email-masked]>
Date: Mon, 21 Mar 94 11:53:35 PST

Bob,

I came to the same conclusion.  My gut says that the parser should only be 
changed to fix reported bugs, which would require a Bird, in my opinion, or to 
undergo a revision to match a new IBIS spec version.  I would still opt for a 
bird in the latter case, just to keep the formality there, a Big Bird, if you 
will, to deal with a big revision.  The detail for such a bird would be 
minimal-- change parser to match spec-- end of bird.

For enhancements, I still think a bird is appropriate, but would not be required
for a standalone sign checker, or one that checked for vcc relativity per 
Arpad's comment.  A bird could be used then to cause the new utility to be 
merged into the parser after it is proven good.

Will

Hey, Ibis guys!

I have been reading the accumulated mail from the past couple of days and see a 
thread about whether or not to change the parser for the current sign problem 
without a full blown bird.  After thinking about it, it would seem a fairly 
large

departure from "policy" to do that.  But since I agree with Kellee that 
_somethin g
is needed here, how about a stand alone utility to check this until we can fully
hash out a bird? ( Hatch out a bird? )  Seems it should not be too mch harder to

Thanks,

---

From: [email-masked] <[email-masked]>
Date: Mon, 21 Mar 94 15:17:05 -0600

I am one of the users that has been "gone to the birds" on the current
sign issue.  I have been getting some of my associates to generate
data.  The rev. 1.0 spec does not mandate the current convention.  The
example in the spec is correct, but there is no statement that it has
to be a certain way.  The confusion is in the current to the load or
from the buffer.

The reason that I think that the parser should be changed, is that at
least one IBIS complient tool has failed to this issue.  I am sure that
most of the vendor tools will fail.  The purpose of the parser is to
provide pertinent information about the file correctness.

There may rightfully be a discussion of which is to come first the
"bird or the egg" (Sorry about that).  I would really like to see the
"current sign issue" resolved by rev. 2.  This would include a little
tighter wording in the spec and an upgrade to the parser.

The issue on monotonicity seems to be between tools vendors.  Some
tools allow it and some tools don't.  We have a CMOS driver that is
non-monotonic  -- but a good editor can take care of that :-).  So, do
we limit the ourselves to a subset of vendors, limit ourselves to a
subset of capabilities, issue warnings only, or let the user beware?  I
suppose this could also become a tool vendor certification issue.

Pardon my ramblings....

+------------------------------------+
|                                    |
| Lynn Warriner  - bert              |
| Somerset Design Center -- Austin   |
|                                    |
+------------------------------------+