Subject: Re: EGG1.0; specifying the .PKG file

From: [email-masked] (Mike Ventham)
Date: Fri, 4 Mar 94 13:47:31 CST

Gentle IBIS folk,

I pondered upon Eric's directory quandary purporting to package files and
suggest the following.

1) The package file should not be forced to be in the current directory but
   that should be the first place it is looked for.

2) The next place should be a sub-directory called "packages" (radical eh?).
   The subdirectory seperation character would be a conditional compilation
   in the parser dependent on whether it is UNIX or the backward sloping
   operating system developed by some window dressers.
   This enables a central directory for packages to be used by the use of
   links (if the OS supports it).

3) If it is not there then give a polite error to the user.

4) As the packages are likely to be passed via email the package file format
   will need the file name as part of the syntax along with any other data
   appropriate from the IBS file header.

5) Also one of our earlier discussions on packages mentioned the fact that 
   although packages have a standard footprint, the chip size inside will
   vary and therefore affect the wirebond length and thus the package
   inductances. Therefore one package file for all DIP16s may not necessarily
   be be suitable, although I would expect it to be close. The question is :-
   what accuracy does the user want - given what Lynn was saying about IBM's
   308 pin packages.

Comments anyone?

Mike
-- 
+=============================================================================+
|  Mike Ventham   Vice President Engineering                                  |
|  Quantic Laboratories Inc, 1200-191 Lombard Ave, Winnipeg MB Canada R3B 0X1 |
|  Tel: (204) 942 4000 Fax: (204) 957 1158 Email [email-masked]        |
+=============================================================================+
Remember: There are only two ways to develop a bug-free program - and only
	  the third way works.

---

From: [email-masked]
Date: Fri, 04 Mar 94 15:19:11 -0500

To IBIS folks:

  Please forgive my unresponsiveness or any bounced e-mail messages.
Our router is back up now and hopefully will stay that way for a few
days.

To Mike Ventham:

  Could you expand on your Point Number 4 please?  It's not clear
to me what you're saying.

  Regarding your point number 2: the conditional compilation would
work, but wouldn't this mean that we would then need to have two
separate sets of IBIS files, one for Dad's Operating System and the 
other for Eunuchs?  Maybe we should just allow BOTH "\" and "/" as
a subdirectory separation character, and forbid the user from employing
them as regular characters in file names. (This doesn't sound like it
would be too hard a restriction to live by.  "\" is often ignored
in UNIX shells anyway.)

  Regarding your point 5: yes, the vendor should beware.  That brings
up another point.  Even if the die sizes are the same, are the
locations of the bonding pads on the die necessarily the same from one
IC to another?  And what if there are some NC's (do they omit the bond
wires)?  That would alter the RLC matrices.

--Eric

---

From: [email-masked] (Mike Ventham)
Date: Fri, 4 Mar 94 16:24:05 CST

Eric,
Thanks for your speedy reply 
> to me what you're saying.

To clarify, if I receive an email of an IBS together of an email of the
package file I can use the  Keyword:  [File name] to know what filename
to save the ibis file message as. I therefore also need the equivalent
for the package message so that the package file has the right name
for the ibs file to reference. The other keywords I think it will need
are [IBIS Ver],[File Rev],[Date],[Source],[Notes],[Disclaimer].

> would be too hard a restriction to live by.  "\" is often ignored

Actually, I meant that the packages directory is a search path and
does not need to be explicitly mentioned in the file, and therefore
avoid having any seperation characters, thus getting round the OS
issue. This is similar to the include file search in compilers.

> wires)?  That would alter the RLC matrices.
Ezacally my point !

Mike