Path: utzoo!mnetor!uunet!husc6!uwvax!dogie!uwmcsd1!ig!agate!ucbvax!KNAPP.CS.UIUC.EDU!knapp
From: knapp@KNAPP.CS.UIUC.EDU (David Knapp)
Newsgroups: comp.lsi
Subject: schematic interchange format
Message-ID: <8803091159.AA00803@knapp.cs.uiuc.edu>
Date: 9 Mar 88 11:59:10 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 36

If we need a standard interchange format, what is wrong with EDIF except
possibly that it-is-too-complicated-and-besides-we-don't-need-all-that?

Never mind. A standard that nobody uses, for whatever reason, is about as
useful as King Tut's standards for coffin nails. If nobody wants to use
EDIF then we must simply sigh and develop something else.

I would like to say however that if we do develop a de facto community
standard for schematic interchange, we should not shut out the possibility
of automatic processing for the schematics. This means two things.

1. screen layout information. That is, positions of symbols, text, and
   "routing". This would be addressed by dumping bit maps, but:

2. we also should include circuit information so that we don't have to
   run an extractor on the diagram to recover the circuit topology. This
   means information like the SPICE deck, which unfortunately does not
   include any display layout information. That is, if we want to pictorially
   display it we have to do place-and-route with the screen as carrier.

I would also like to put in support for

1. multipage (or multiscreen?) diagrams. In my limited experience it
   is hard to understand screen displays with a component density of more
   than about 50 components in an 8.5X11 inch format (your Imagen printer).
   (it is also hard to lay them out intelligibly).

2. pointers to behavioral models for the components. If I use a black
   box in my schematic and you want to simulate it you will have a hard
   time doing it with only an English description of what it does. If I had
   my druthers I'd ask for a language like VHDL but there is so little
   software that uses VHDL, I'd settle for Lisp code, or C. Because we
   will no doubt be unable to agree on a standard form for expressing
   behaviors, I am afraid this one has to be given a secondary importance.
   See, for example, EDIF's handling of this issue.
								David