max@trinity.uucp (Max Hauser) (03/09/88)
In article <1059@PT.CS.CMU.EDU> phd@SPEECH1.CS.CMU.EDU (Paul Dietz) writes: >A recurring problem in this news group is the need to post readable >schematics. ASCII circuit representations are just too painfull to >create, and are quite inflexible. > >WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!! > >Optimally, any standard would have interfaces on many standard >hardware configurations. (Mac, PC's, Xwindows, GKS, UNIX Plot, etc.) >Also, for those stuck with standard, non-graphics terminals, a human >readable form should be generated as a side effect. > >Proposal: If I get sufficient feedback, I will start posting schematics >in binhexed MacPaint format. For you Macintosh hackers, this is a familiar >format. I've also heard rumor that various PC programs read MacPaint files. I think this is one of the most constructive ideas I have seen on the Usenet in a while, and I applaud Paul for proposing it. I do also think it could bear some further discussion, since the de-facto schematic representation that emerges may be with us for a while and it would be a pity to foreclose future flexibility or upward compatibility. I have included comp.lsi in the primary distribution here since some of its readers will also have insights on this issue. It is not a new problem; it comes up also with CAD tools for schematic capture and storage, for example, although these products are usually proprietary and the designers have little incentive to create a broadly-readable format. Nevertheless there are bound to be some readers with experience in mail-compatible schematic representation. I don't know anything about MacPaint, except that a lot of readers who will be interested in schematics do not have access to it. Is the proposal to store the schematics in a purely graphic form? If so, is MacPaint the most widely accessible? Can non-Macintosh users still take advantage of schematics rendered that way? Perhaps there is some other format to which a variety of different displays, including MacPaint, can interface or translate easily, just as (closer to my own experience) there are two or three nearly-universal standard formats for graphic representation of integrated-circuit layouts. I am just throwing out ideas here; the prospect of a widely-translatable intermediate representation, if possible one that already exists, is the first. I am aware of the emerging IEEE Electronic Design Interchange Format (EDIF), although I know nothing about it. Does any reader know if EDIF relevantly addresses the issue of schematic communication? Paul rejects "ASCII circuit representations," and I don't know exactly what he means there -- I infer something like SPICE circuit format, where you number the nodes in a circuit and then list each component with its node numbers and specifying information: Q6 5 7 12 2N3906 C2 10 0 47pf Is it not worth discussing this as a pragmatic schematic representation? Although it might at first seem unnatural, it (1) is extremely compact; (2) is inherently ASCII and thus immediately accessible, at once, and unambiguous, to everyone even without graphics terminals (the rules are straightforward and readily summarized); (3) potentially useful as an intermediate form that can be rendered automatically as a graphical schematic, through software; and most important, (4) not only something of a de-facto standard among many professionals already, with tools written to support it, and therefore plenty of software to tap into and people available to answer questions, but in particular, instantly compatible with SPICE-class circuit simulators, which are in public domain and already exist at far more sites than the Usenet reaches. A SPICE node-based circuit representation may seem unnatural if you are unused to it, but with just a little experience it is quite as easy to write down as a graphic schematic, and arguably easier to enter on a computer. And of course there is the huge advantage that the file can come off the Usenet and plug directly into all manner of simulators, verifiers, optimizers and other circuit software (much of it even PC-compatible), discussion of which could easily flourish along with the exchange of schematics. I'm not completely sold on that format myself, but I offer it for consideration as I don't know of a purely-graphical schematic format that would reach nearly as many readers. Max Hauser / max@eros.berkeley.edu / ...{!decvax}!ucbvax!eros!max
magnani@msudoc.ee.mich-state.edu (Steven Magnani EE) (03/09/88)
(I have added comp.lang.postscript to the discussion to get sone feedback on this idea. Note that followups go to sci.electronics --SJM) The problem: In article <1059@PT.CS.CMU.EDU> phd@SPEECH1.CS.CMU.EDU (Paul Dietz) writes: >A recurring problem in this news group [sci.electronics] is the need to post >readable schematics. ASCII circuit representations are just too painful to >create, and are quite inflexible. > >WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!! > >Optimally, any standard would have interfaces on many standard >hardware configurations. (Mac, PC's, Xwindows, GKS, UNIX Plot, etc.) >Also, for those stuck with standard, non-graphics terminals, a human >readable form should be generated as a side effect. > >Proposal: If I get sufficient feedback, I will start posting schematics >in binhexed MacPaint format. For you Macintosh hackers, this is a familiar >format. I've also heard rumor that various PC programs read MacPaint files. >Max Hauser / max@eros.berkeley.edu / ...{!decvax}!ucbvax!eros!max A proposed soultion: If one is talking about exchanging graphics only (ie, not an actual circuit description, such as SPICE or MAGIC could deal with), a graphics description language such as PostScript ((tm) Adobe Systems) or Interpress ((tm) Xerox) might be useful. These files may be stored in ASCII format (perfect for E-mail interchange!), and may be interpreted by programs on widely differing systems. Translation programs exist to go between PostScript/Interpress and other graphics description languages (such as HPGL). Also, PostScript-type printers such as the LaserWriter are becoming more common, so even if a particular site has no tools for displaying the schematic on the screen, a hard copy may be generated. Since the Mac tools are capable of generating PostScript output (correct me on this...) this might be a better idea than posting binary files. One disadvantage of this scheme that *I* can think of is that the PostScript files may not be easily edited. It sounds like MacPaint stores its files in binary format, in which case it is probably unable to accept PostScript files as input. FrameMaker ((tm) Frame Technology) is another such graphics editor. There are editors which *can* handle input like this, but I am not sure how widely available they are. The bottom line, I suppose, is that unless the E-mailed copies are able to be edited, only the original designer of a circuit would be able to post his drawing. There would be no way for anyone else to make changes in the circuit without redrawing it from scratch. Is this a real problem, or not? Are there other serious shortcomings to this approach? Steven J. Magnani "I claim this network for MARS! Earthling, return my space modulator!" {_the_world_}!ihnp4!msudoc!magnani With a domain server: magnani@msudoc.egr.msu.EDU
pfeiffer@nmsu.CSNET (03/10/88)
I agree that schematic-posting mechanism would be a Real Good Idea. The technique used should be graphics-based though; MacPaint would therefore be a better format than Spice. I'm also not familiar with interchange formats, and I'd like to see some thought go into the most appropriate one before we arbitrarily pick one. Two thoughts: (1) As I understand Mac tools, Mac Draw seems better suited than Mac Paint. (2) Tell me more about EDIF -Joe Pfeiffer
jjh@LL-VLSI.ARPA (James J. Hunt) (03/10/88)
> I am aware of the emerging IEEE Electronic Design Interchange Format > (EDIF), although I know nothing about it. Does any reader know if EDIF > relevantly addresses the issue of schematic communication? EDIF is a reasonable means of communicating schematics. EIA has published a document describing EDIF --- EIA Interim Standard No. 44. To the best of my knowledge, EDIF 2 0 0 has be adopted by EIA as a full standard, but I only know the Interim number. Several CAD vendors claim they support EDIF for schematics. I don't know how well any particular vendor lives up to their claim. Also the new Berkeley Oct tools will be supporting EDIF (Some time this spring?). Berkeley may also be distributing an EDIF parser (written in C) with future releases of the Oct tools. It is best to contact Berkeley directly for the ``OFFICAL STORY''. The advantages of EDIF are that it is an ascii format and there is a standard for it. --- JJHunt
ward@cfa.harvard.EDU (Steve Ward) (03/11/88)
There is a real problem with EDIF -- SCARCITY! No low-cost schematic capture products (read PC's, MAC's, etc) that I know of support EDIT (make that EDIF) schematic file generation, general support of EDIF file previewing graphically, etc. If the point is easily exchange schematics then somebody will have to write and give away a lot of EDIF software to run on the PC's and MAC's of the world. This would be great, but how about starting with HPGL????? :-)
jlacoss@VENERA.ISI.EDU (Jeff La Coss) (03/12/88)
The idea of using HPGL as an exchange medium has one benefit: it can be done right now, no hassle. The problem with using HPGL is that no understanding of circuit topology or functionality is communicated to design systems by a series of draw commands. Persons wishing to incorporate a transmitted design would be forced to re-enter the schematic from pen plots. A problem with EDIF arises directly from the rumor mill (a local CAD sales office). I am given to understand one feature of EDIF is provision of a SPECIAL construct, allowing members of the CAD industry to follow local database philosophies. I believe this can be interpreted to mean "As far as being an all-encompassing spec is concerned, EDIF has a hole in it that one can drive a truck through." Don't get me wrong -- I'd love to hear this ain't so Jeff
smb@MIMSY.UMD.EDU (Steve M. Burinsky) (03/12/88)
One of the things that makes a standard a standard is that people agree to use it. Although EDIF may very well have some shortcomings, it does provide all or most of the features everyone would like to see in an electronic design interchange format (what's in a name?). One way to get the CAD market to support EDIF is to create a demand for it. Many examples of how this has worked can be cited. Open standards win over proprietary "standards" again and again. HPGL, Spice, MacWhatever, etc. or a hybrid just doesn't fit the bill. I think it's worth the pain now. Let's try to do it right the first time. Steve
John_Philip_Eurich@cup.portal.com (03/15/88)
In response to the article: >3/11/88 13:35 jlacoss@VENERA.ISI.EDU (Jeff La Coss) > > A problem with EDIF arises directly from the rumor mill (a local CAD >sales office). I am given to understand one feature of EDIF is provision >of a SPECIAL construct, allowing members of the CAD industry to follow >local database philosophies. I believe this can be interpreted to mean > > "As far as being an all-encompassing spec is concerned, EDIF has > a hole in it that one can drive a truck through." > > Don't get me wrong -- I'd love to hear this ain't so > At Engineering DataXpress we are writing a number of data translators to and from EDIF, including Schematic data, and haven't run into this large hole you have described. From my perspective you CAN drive alot of data (trucks?) through EDIF, but must do so on very well defined streets. Jeff, can you be more specific about what your CAD salesman said? Its impossible to respond to such a general accusation. Is this person talking about the latest version 2 0 0, or some earlier version? Is this reference to the natural and legal way to extend EDIF, called "userdata", which is to be used ONLY for data that the standard does not yet represent and only for experimentation? After a year of examining EDIF no one has found a need for "userdata" to represent 2D graphic, schematic, netlist, or masklayout data. This means that EDIF so far has proven to be capable of representing these types of data in a neutral format which is not specific to anyone's database philosophies. Ok, I'll say it. "It ain't so!" John Eurich. dataxpress@cup.portal.com
ward@cfa.harvard.EDU (Steve Ward) (03/17/88)
I may be mistaken, but I thought the original idea was to formulate a simple, inexpensive, universal way to interchange schematics to the great masses awaiting electronic enlightment :-) It does seem to me that there are two ways to go: first, what is admittedly the "right" way, which is to say EDIF. Second, to do something that is readily available and affordable to everyone, including basement amatueurs. EDIF will certainly require lots of programming and the goodwill free dessemination of those programs in order to receive "universal interchange" capability. If there are those out there in netland who are willing to this programming and share it then great, go for it! EDIF is capable of being used to describe the schematic graphically and electrically. Remember, though, that an EDIF-to-plot translator will be needed. The best one would be EDIF-to-HPBL followed by EDIT-to-Postscript, though there HPBL-to-Postscript translator(s) floating around the net, I believe. As I understand it, EDIF allows the definition of graphics symbol to plot mapping to be done by the user. In other words, EDIF does not provide a specific schematic definition methodology such that it defines the graphics plot representation of the schematic. The definition and interpretation of drawing the schematic onto paper or whatever is left to the user. This is really a question, since I am not sure my understanding is correct, and I do hope it is wrong. Someone who really knows should comment on this. If my understanding is correct, then a definition of how to reprsent schematics in EDIF with respect to a coordinate system, scale information, parts (graphics symbols) defiintions (presumably vectors) etc will have to agreed upon. If I am wrong, then EDIF provides a full graphics description capability as well as circuit topology capability and this particular concern is unfounded. In any case, it does leave a lot of software to be generated if the intent is to provide lowly PC (and clones), MAC's, and variouus workstation users to interchange schematics. I suppose the two critical pieces of software would be the EDIF-to-HPGL translator and an EDIF netlist extractor that would generate a generic ASCII wireing list, component parts list, and hopefully an English language ASCII netlis. Come to think of it, I guess a third piece of software is needed: a program to generate or otherwise encode a schematic into the necessary EDIF format. I guess this is the real problem. Who has this capability, and for the masses who do not, how can this capability be easily provided? If there is an easy, simple, universal solution to this last program then please tell us. The second cheap and dirty approach, using a simple netlist and an HPGL file of the schematic has already been discussed. Its merits are that many low-cost PC and MAC programs exist that allow generation of schematics netlist files and HPOBL files, including plotting of HPGL files on dot matrix printers. Also, HPGL dot matrix printer support is simple to implement independently. I certainly favor EDIF if the last problem of how to provide the masses with the means to generate schematic EDIF files can be surmounted. If the idea is really to provide interchange for those using commercial CAE/CAD workstation systems, then NEVER MIND! fMy lowly PC at home and our overpriced CAE system at work can generate netlistss and HPGL files and plot them , but neither know zip from shinola about EDIF. o
dataxpress@cup.portal.com (03/18/88)
In reply to: Re: Posting schematics... 3/16/88 09:25 ward@cfa.harvard.EDU (Steve Ward) >As I understand it, EDIF allows the >definition of graphics symbol to plot mapping to be done by the user. >In other words, EDIF does not provide a specific schematic definition >methodology such that it defines the graphics plot representation of the >schematic. The definition and interpretation of drawing the schematic >onto paper or whatever is left to the user. This is really a question, >since I am not sure my understanding is correct, and I do hope it is >wrong. Someone who really knows should comment on this. A semantic rule of EDIF is that the relationship to SI units and all numeric values must be explicitly specified in the EDIF file. In other words it is impossible to specify a coordinate value in EDIF and not know what that value is in meters, inches, or whatever unit you like to use. Thus if you create a schematic in which all your symbols are one inch square, then all readers of EDIF will be able to determine that your symbols are one inch square. If they want to plot them scaled down by one half, then that's their business. The scaling of all values to SI units is specified in EDIF using the "numberDefinition" and "scale" constructs within the "technology" construct. For example, to specify that all your coordinates are in MILS ( 1/1000 inch ) your EDIF file must contain the following: (technology (numberDefinition (scale 1 (e 254 -7) (unit DISTANCE)))) which states that one distance unit is equal to 254 * 10**-7 meters, which is one MIL. Thus, a circle whose diameter is specified in this EDIF file to be 1000 should be plotted as a circle one inch in diameter (assuming no scaling is applied during plotting). Before EDIF 2 0 0 was published many drafts were released and reviewed by CAD and CAE experts from all over the world. I'm talking about hundreds of people reviewing over twenty drafts. It's unthinkable that such a feature as mapping numeric values to real units could have been left out and still gone unnoticed during the review period. John Eurich dataxpress@cup.portal.com
moto@cad.Berkeley.EDU (EDIF Committee) (03/19/88)
In article <920@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes: > > >I may be mistaken, but I thought the original idea was to formulate a >simple, inexpensive, universal way to interchange schematics to the >great masses awaiting electronic enlightment :-) It does seem to me >that there are two ways to go: first, what is admittedly the "right" >way, which is to say EDIF. Second, to do something that is readily >available and affordable to everyone, including basement amatueurs. > WRONG _ EDIF CAN be "simple" for simple tasks, so far most of the implementations have been for "high end" stuff, but I have written a 100 line program to extract JUST the graphics for a Commodore 64! Leaves out A LOT, but its intended to be SIMPLE! >definition of graphics symbol to plot mapping to be done by the user. EDIF does NOT define symbols, but there exists an ANSI standard for that (I forget the RS number). I.E. EDIF does not say a NAND gate looks like ... >In other words, EDIF does not provide a specific schematic definition >If my understanding is correct, then a definition of how to reprsent >schematics in EDIF with respect to a coordinate system, scale >information, parts (graphics symbols) defiintions (presumably vectors) >etc will have to agreed upon. If I am wrong, then EDIF provides a full >graphics description capability as well as circuit topology capability >and this particular concern is unfounded. In any case, it does leave If I understand the question - you are wrong, EDIF provides definition for scaling, grids etc. for a complete 2D coordinate system. With a trivial extension to the POINT construct it allows N dimensional graphics! >a lot of software to be generated if the intent is to provide lowly PC >(and clones), MAC's, and variouus workstation users to interchange >schematics. I suppose the two critical pieces of software would be the If the data is simple and straightforward the interface should be! Be careful that the data may be MUCH more complex than you think though. >If the idea is really to provide interchange for those using commercial >CAE/CAD workstation systems, then NEVER MIND! NO WAY!!! THis weeks EDN has an ad for PC AT based PCADS interface, ORCAD, and about a dozen other PC/MAC based companaies have translators! They are relatively sophisticated, but for the 20 transistor/gate one page schematic the amateur usually wants a very simple interface should be fine since almost everything is fixed! (library, cell etc.) If I get the time I will resurect my simple C 64 one and post it, but you might get your interface finished by the time I get it! To start: look for "(EDIF", ignore everything looking for "(CELL", look for ports, nets etc. the same way. Leves out A LOT, but it works! Mike Waters EDIF TC