phd@SPEECH1.CS.CMU.EDU (Paul Dietz) (03/08/88)
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. This is a difficult project to get started, so maybe we should make some initial comprimises in order to get the ball rolling. 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. Thus, I might be able to reach a large enough audience to generate a real interest in getting together a universal schematic format. So, what do you all think? Is this a viable way of dealing with this problem until we get a real solution, or am I shutting out too much of the sci.electronics community? Paul H. Dietz ____ ____ Dept. of Electrical and Computer Engineering / oo \ <_<\\\ Carnegie Mellon University /| \/ |\ \\ \\ -------------------------------------------- | | ( ) | | | ||\\ "If God had meant for penguins to fly, -->--<-- / / |\\\ / he would have given them wings." _________^__^_________/ / / \\\\-
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
bill@sigma.UUCP (William Swan) (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!!!!!!!!!!! >[...] >Proposal: If I get sufficient feedback, I will start posting schematics >in binhexed MacPaint format. You'd shut me out for sure. I have no regular access to *any* graphics capability (unless it's a file of graphics "plot" commands suitable for dumping to an Epson!) For simple stuff there's always (ugh!) SPICE format (oh, you said "readable"..). For more complex circuits, well, I dunno... -- William Swan {ihnp4,decvax,allegra,...}!uw-beaver!tikal!sigma!bill
faustus@ic.Berkeley.EDU (Wayne A. Christopher) (03/09/88)
The SPICE format does have the advantage of being pretty much universal, but it is limited by a maximum of 26 device types, and isn't really appropriate for higher-level blocks. (You can have a .subckt opamp, but there's no agreement on what this will look like.) Also there's no easy way to specify how the circuit should look graphically. You need to give positions and orientations to the devices, and the routings of the nets (unless you expect the tools to figure all this out for themselves). I like the idea of EDIF better. Wayne
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
root@sbcs.sunysb.edu (SBCS Systems Staff) (03/09/88)
Why not just pump schematics around in PostScript format? Easier to print for the poor souls without Mac's.. Rick Spanbauer SUNY/Stony Brook
flaig@cit-vlsi.Caltech.Edu (Charles M. Flaig) (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!!!!!!!!!!! For my $0.02 worth, how about using the TeX picture format (whatever it's called, I'm a novice)? I know I used a simple CAD program to draw a lot of circuits and convert them to this format for inclusion in my Master's thesis. Many graphics machines (such as the SUNs I use) have a preview program to display TeX output on the screen, and you can get high quality hard copy on your local graphics (laser) printer. Alternatively, maybe we could use a generic CAD language including lines, object definitions, rotations, and labels. Different scripts could then be made available to translate these into whichever CAD program the user has access to. ______________________________________________________________________________ ___ , , ,;,;;;, / Y /| /| Charles Flaig ;/@-@\; | |/ __, ,__ |/ flaig@csvax.caltech.edu | ^ | | /^\ / | | | / /\ /\ \=/ \____/| \_/|_/\_/ \_/ \_\/_/_/_/ "What, you think they PAY me for this?"
malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) (03/09/88)
In article <1059@PT.CS.CMU.EDU> phd@SPEECH1.CS.CMU.EDU (Paul Dietz) writes: >WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!! Check out the EDIF (Electronic Display Interchange Format??) standard. A number of vendors are supporting this standard for interchanging IC and PCB databases. It is a Lisp-like langauge for specifying a heirarchical design. Malcolm P.S. The only vendor I am 100% positive is supporting EDIF is Cadnetix. I believe most of the rest of the industry is also supporting it but I don't have their names.
richardk@puff.cs.wisc.edu (Richard Kottke) (03/09/88)
_]
I think that the MACPAINT format is fine for showing layout and other graphic
stuff, but that the poster might also include a SPICE format file or something
similar to help us folks who don't have direct access to a MAC. There need
be no ambiguity on subcircuits - if you say "X741 ..." I can assume that you
mean a 741 op-amp and that the pins are listed in order etc.
What exactly is the BIN-HEX format? It looks like it uses 8 6-bit chars
to represent 6 8-bit bytes, and says that an "!" is a zero. Once I have a
binary file, is there any other decompression to do? Help!
-Rich
Richard Kottke
kottke@puff.cs.wisc.edukhayo@sonia.cs.ucla.edu (Erazm J. Behr) (03/09/88)
No, no, not "TeX graphics" but PostScript! It's becoming a
standard for many high-quality (== laser?) printers and is
also a good practice for any CS undergrad (RPN, anyone?)
I even have a bunch of macros for the most common symbols,
but I'd be ashamed to show them in public (moreover, if my
ex-PhD advisor is reading this group too, you'll soon see
"*****, GET BACK TO WORK !!!!!")
A question, then: since laserwriters aren't very common
in private hands, are there any translation programs which
would take a PostScript input and drive a med-resolution
dot-matrix printer (ImageWriter, for instance?)
By the way, the suggestion is wonderful, and it shouldn't
be limited to schematics (PC layouts, too !) If we could
only get NSF funding for slaves who would write the stuff ...
Eric
___________________________________________________________
Please use khayo@MATH.ucla.edu instead of CS.ucla.edufmr@cwi.nl (Frank Rahmani) (03/09/88)
> Xref: mcvax comp.lsi:342 sci.electronics:2060 comp.lang.postscript:384 > 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. > Translation programs exist > to go between PostScript/Interpress and other graphics description > languages (such as HPGL). ... ... I would really be very interested in such a conversion program (PD if possible). That means from PostScript (or a subset thereof) to HPGL. _NOT_ the other way round, as that was posted on the net some time ago. Many thanks in advance for any help. Regards fmr@cwi.nl -- It is better never to have been born. But who among us has such luck?
lharris@gpu.utcs.toronto.edu (Leonard Harris) (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. > >This is a difficult project to get started, so maybe we should make >some initial comprimises in order to get the ball rolling. > >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. >Thus, I might be able to reach a large enough audience to generate a real >interest in getting together a universal schematic format. > >So, what do you all think? Is this a viable way of dealing with this >problem until we get a real solution, or am I shutting out too much >of the sci.electronics community? > >Paul H. Dietz ____ ____ >Dept. of Electrical and Computer Engineering / oo \ <_<\\\ >Carnegie Mellon University /| \/ |\ \\ \\ >-------------------------------------------- | | ( ) | | | ||\\ >"If God had meant for penguins to fly, -->--<-- / / |\\\ / >he would have given them wings." _________^__^_________/ / / \\\\- How about posting things in postscript format - readable by macs, lasers and has the potential to be converted to other formats. /leonard
craig@sauron.Columbia.NCR.COM (craig) (03/09/88)
Why not use Xwindows? It seems to be becoming the standard. To use a Mac file I would have to get someone else to convert it to Xwindows for me. Craig -- -Craig Williamson Craig.W@ncrcae.Columbia.NCR.COM
conte@uicsrd.csrd.uiuc.edu (03/10/88)
Another thing to think about when considering schemes that are purely
declarative (i.e., no graphics information, just net lists and devices)
is that displaying these schematics is a non-trivial task. It is pretty
easy to go from a schematic to a netlist, but not so easy to go back
again.
The problem with a purely graphical description (MacDraw, Postscript,
PiCTeX, pic, etc.) is that this does not specify any standards on how
to draw a device. My op-amp may look like an op-amp to me, but you
might be totally confused by it (``what the heck *is* that darn thing?'').
What is needed and has been needed for some time is an annotated netlist
declarative language that specifies circuit elements from a standard library,
their positions on a plane, and the connections between the elements. The
library would contain a graphic element for each curcuit element listed,
a part number, specifications, etc. Then, this annotated netlist could
be run throught a front end to display the circuit, or through another
filter to produce SPICE output, or through another filter for, say, an
automated wire wrapper. As a final proviso, the language should be
relatively human-readable. Commenting should be supported.
This is pretty close to the file format for the SCHEMA circuit design
package except for the commenting.
------
Tom Conte Center for Supercomputing Research & Development
University of Illinois
The opinions expressed are my own, of course.
uucp: ...!uiucdcs!uicsrd!conte bitnet: conte@uicsrd.csrd.uiuc.edu
arpanet: conte@uicsrd.csrd.uiuc.edudenbeste@bgsuvax.UUCP (William C. DenBesten) (03/10/88)
In article <1059@PT.CS.CMU.EDU> phd@SPEECH1.CS.CMU.EDU (Paul Dietz) writes: > > WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!! > >Proposal: If I get sufficient feedback, I will start posting schematics >in binhexed MacPaint format. MacPaint stores files as a compressed bitmap. I have documentation that describes the method that it uses for compressing. I also have a program that runs on a unix host that will take a file out of binhex format. If circuits begin appearing in MacPaint format, I could post these and a sufficiently motivated (ie no mac) news-reader could write a program to display the bitmap on their favorite computer. -- William C. DenBesten | denbeste@bgsu.edu Dept of Computer Science | CSNET denbeste%andy.bgsu.edu@relay.cs.net Bowling Green State University | UUCP ...!cbosgd!osu-cis!bgsuvax!denbeste Bowling Green, OH 43403-0214 |
rees@apollo.uucp (Jim Rees) (03/10/88)
I've often thought that usenet needs a way of transmitting graphics, and that at least the viewing ought to be built into the news reader. Unix already has a standard for graphics output (see plot(5)). It's so incredibly low-tech that it would be trivial to implement even on non-unix systems in just about any news reader that talks to a device capable of any kind of graphics. And output translators are available in the public domain for a variety of devices. I've been meaning (for about 4 years) to put together a working example, in my copious spare time...
dave@sun.soe.clarkson.edu (Dave Goldblatt) (03/10/88)
From article <1038@sauron.Columbia.NCR.COM>, by craig@sauron.Columbia.NCR.COM (craig): > Why not use Xwindows? It seems to be becoming the standard. > To use a Mac file I would have to get someone else to > convert it to Xwindows for me. Funny, it's not a standard on my PC, and I doubt it'll be one soon on the Macintosh.. :-) If you look in the X11R2 distribution, I'm fairly sure there's a program called Xmac (written by naughton@sun.soe.clarkson.edu, Patrick Naughton) which displays MacPaint pictures under X and can also convert them to PostScript.. I'd suggest using MacPaint format (uuencoded). Programs to uudecode exist on just about every system I've ever seen (and are easy to write), and programs to display and/or convert MacPaint images are almost as widespread. -dg- -- Internet: dave@sun.soe.clarkson.edu or: dave@clutx.clarkson.edu BITNET: dave@CLUTX.Bitnet uucp: {rpics, gould}!clutx!dave Matrix: Dave Goldblatt @ 1:260/360 ICBM: Why do you want to know? :-)
gwu@clyde.ATT.COM (George Wu) (03/10/88)
[ Standard disclaimer: I alone am responsible for this article's content. ] In article <999@spar.SPAR.SLB.COM> malcolm@spar.slb.com (Malcolm Slaney) writes: >In article <1059@PT.CS.CMU.EDU> phd@SPEECH1.CS.CMU.EDU (Paul Dietz) writes: >>WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!! > >Check out the EDIF (Electronic Display Interchange Format??) standard. >A number of vendors are supporting this standard for interchanging IC >and PCB databases. It is a Lisp-like langauge for specifying a heirarchical >design. > > Malcolm >P.S. The only vendor I am 100% positive is supporting EDIF is Cadnetix. >I believe most of the rest of the industry is also supporting it but I >don't have their names. Let's go over what we really want to be able to do with this description: o Describe the circuit in some graphical manner. We'd want this to be as global as possible, so as many people as possible can see it. I'd suggest Postscript, since it is widely used, and is essentially a standard. What I believe is/will be *the* standard interface for displays on-screen is X-Windows, and I'm sure there is/will be a filter between X and Postscript format. Anyone know for sure? o An ASCII description of the circuit. That is to say, there should be a public domain filter which would extract just this information, for those of us who don't have access to an appropriate graphics device. But what circuit descriptions are available? Spice? That limits what type of devices we can have very much. EDIF? That's supposed to be a standard. Does anyone know more about it; I don't. o A chip and wire level schematic? I'd guess that's what most people here would want, since they may very well go off and build it themselves. For a chip specification, CIF (Caltech Intermediate Format) seemed to be the standard when I was into VLSIC CAD. Is EDIF a chip level or a mask level description language? Or is it general enough to do both? As of yet, I don't think any of the proposed formats fits these major requirements. I think the really tricky part is how to take a graphical description, such as Postscript, and extract circuit information from it. Any ideas? And finally, could someone follow up Malcolm's EDIF suggestion with a reference and where to get a copy of the paper? It's an IEEE standard, so has a definitive article been published in a journal or magzine somewhere? Note that it'd be better to use a magazine article, rather than a formal paper, considering the logistics of distribution and such. (How would IEEE respond if N-hundreds of us requested the same paper? Slowly, at best.) Further note that this would have to be a good, detailed article, since many people would have to know very specific details about EDIF to write filters and such. A quick blurb wouldn't do at all. And really finally, kudos to Paul for this idea. I think the net has just justified some of it's operating costs. Hear ye, management? -- George J Wu UUCP: {ihnp4,ulysses,cbosgd,allegra}!clyde!gwu ARPA: gwu%clyde.att.com@rutgers.edu or gwu@faraday.ece.cmu.edu
straka@ihlpf.ATT.COM (Straka) (03/10/88)
In article <1454@puff.cs.wisc.edu> richardk@puff.WISC.EDU (Richard Kottke) writes: >I think that the MACPAINT format is fine for showing layout and other graphic >stuff, but that the poster might also include a SPICE format file or something >similar to help us folks who don't have direct access to a MAC. There need For the Mac world, the best method (I believe) is to paste a object-style graphic (from MacDraw or some other package) into a MacWrite file. Almost everyone has MacWrite or a compatible package, and the object-oriented graphics lets users modify the diagram after receiving it. MacPaint files, being bit-mapped, offer limited resolution and require a fair amout of data. The vehicle could be a BinHexed (7-bit ACSII) file. I would also assume that there a lot of people like me who have a Mac (or at least access to one through a friend) than those who have access to SPICE capable machines. From my .sig, I admit to some bias. :-) -- Rich Straka ihnp4!ihlpf!straka Advice for the day: "MSDOS - just say no."
johnson@c10sd1.StPaul.NCR.COM (Wayne D. T. Johnson) (03/10/88)
In article <1025@sbcs.sunysb.edu> root@sbcs.sunysb.edu (SBCS Systems Staff) writes: > >Why not just pump schematics around in PostScript format? Easier to >print for the poor souls without Mac's.. > unfortunatly, not all of us can use PostScript. It is apparant that the only possibility would be a generic format, somthing that all of us (even us poor AutoCad) users can use.
ward@cfa.harvard.EDU (Steve Ward) (03/11/88)
In article <329@nancy.UUCP>, magnani@msudoc.ee.mich-state.edu (Steven Magnani EE) writes: > (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. > > There are three functions to be served by electronic schematic interchange: 1. provide distribution of the schematic drawings via e-mail 2. provide electrical netlist of the circuit via e-mail 3. provide readily computer-manipulable version of schematic so that most anyone can edit the schematic Items one and two are easily met, but three is not. First, the most universal graphics file description capability found on software systems that edit and generate schematics is HPGL, or Hewlett-Packard Graphics Language. I strongly suggest this file format be used for distribution of schematics. As I said, most, if not ALL schematics editors already can generate HPGL files of schematics. Also, many people have access to HP pen plotters to plot the files. Additionally, many software packages exist which permit plotting HPGL files on laser printers and even the lowly PC/IBM printer (FPLOT for $64 from Horizon Software) can emulate an HP pen plotter and plot HPGL files. The HPGL language description is simple and well documented, lending itself toward simple manipulation for scaling, rotation, etc. I suggest including an ASCII text netlist file to describe the circuit electrically. This would be a simple connectivity netlist of the kind generated by most, if not all schematics editors for wirewrapping, printing signal connection lists, etc. There are many formats{, and any of them would be fine. One netlist format should be chosen and a description/specification of the netlist format should be distributed. The netlist is useful for wirewrapping, parts lists, and even automatically reading the circuit into a few "smart" schematics editors that can process netlists for various things. PCB layout packages are also usually driven by a netlist file, too. I personally think that item three is not worth pursuing at this time because everyone except those having the ONE schematic capture package using the chosen format would have to write software conversion routines to convert from the chosen schematics capture package file format into their local software format, and in general this is a royal pain, not the least of which is that most schematic packages do not document thoroughly (or at all) the file format of schematic files. Since these packages do generate HPGL files, this is the way to go. Most of these packages DO NOT generate postscript files, though if this were wanted then the best way to do this would be to write and distribute an HPGL-to-Postscript translation program! How about it? Maybe we can get some netlanders interested in writing and distributing HPGL emulators like the one I mentioned (HPGL to Epson/IBM printers) as well as HPGL-to-Postscript. Since HPGL is a vector/line description it is easily scaled and then rasterized. I believe the IBM printer will do at least approx. 200 dots/inch, so that using an IBM printer should still allow scaling down a large (D or E) schematic onto a wide-carriage printer sheet at very readable resolution. The reason most schematic capture packages that print directly to IBM printers have poor resolution is that dump an internal PC bitmap (scaled to Hercules or EGA resolution) to the PC printer and if scaling is done, it is done via bitmap scaling from an already low bitmap resolution to an even lower resolution.
markz@ssc.UUCP (Markz Zenier) (03/11/88)
Some comments. 1. The IBM PC news group uses something called GIF 2. Pick something a cheap CAD schematic capture program can deal with. Even better, something a cheap PC board package can deal with.
richardk@puff.cs.wisc.edu (Richard Kottke) (03/11/88)
I support the idea of using HPGL to transmit the graphic representation of a circuit, and an ASCII net description. Those of you advocating the use of POSTSCRIPT should remember that while it is a standard, it is a standard for big machines, and some people (like me) are going to have to write a filter to convert the uploaded material; I do not envision myself developing an enourmous program to interpret POSTSCRIPT files. HPGL sounds like a format that can be easily converted, perhaps in as few as 200 lines of BASIC (please! no flames. I have nothing better and am a starving student.) -Rich Richard Kottke richardk@puff.cs.wisc.EDU
bkc@sun.soe.clarkson.edu (Brad Clements) (03/11/88)
From article <329@nancy.UUCP>, by magnani@msudoc.ee.mich-state.edu (Steven Magnani EE): > (I have added comp.lang.postscript to the discussion to get sone > feedback on this idea. Note that followups go to sci.electronics --SJM) > > 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 One thing to consider is using more of the power of PostScript. These schematics could be encoded in PostScript Arrays in the form of standard Netlists and a 'PostScript Program' could read the array/ netlist and generate the drawing. The 'program' could be just some standard PostScript which wouldn't need to be copied around the net, but rather one copy kept at each site. Concatenation of the PostScript/netlist file with the 'program' and send it to a Laser Printer or PostScript screen previewer would give a drawn picture. The netlist/arrays could easily be edited. In other words, don't encode the schematic as individual graphical commands, but rather use the power of PostScript to read data arrays of netlist info and draw the diagram from the arrays. I have already done something like this for drawing the Network Topology of our Campus Ethernet using a hosts.txt file converted to postscript arrays and concatenated with the 'PostScript Program'. It works great! No more painstaking hand drawing of our network and any updates to our hosts.txt file is 'automatically' incorporated in the drawing. An example netlist could be layed out as (for those into PostScript) /component_name [ component_type (component name) (component data) [ (pin textural name) (signal name) (otherinfo) (destination pin name) destination_component] ] def The component_type is a composite array describing how to draw the component, how many pins and what their names/placements are. The sub-array of pin connections can go on for ever. The destination component is the name (literal) of an array (not the array itself) which is the same kind of array as the source component. Editing this kind of structure is easy. And writing PostScript code to parse the arrays and automatically draw the schematic isn't too difficult. Example: /Part_resistor [ {procedure for drawing one} {procedure for labeling} [ (pin1) (pin2) ] ] def /Part_transistor [ {procedure for drawing one} {procedure for labeling} [ (cathode) (anode) (gate) ] ] def % begin dummy schematic /part_one [ Part_resistor (R1) (220ohm) [ (pin1) (Oscillator Output) (otherinfo) (anode) /part_two ] [ (pin2) (some other signal) (otherinfo) (cathode) /part_three ] ] def /part_two [ Part_transistor (T1) (22227) [ (cathode) (+5V) (otherinfo) (pin1) /part_four ] [ (gate) () () (pin2) (anode) /part_three ] ] def /part_three [ Part_transistor (T2) (25634) [ (gate) (ground) () (pin2) /part_four ] ] def /part_four [ Part_resistor (R2) (345ohm +-1%) ] def Anyway, you get the idea. Notice that each part only lists what it connects to, not what connects to it. There would have to be more stuff in the structures etc, but I think this is a basic netlist with [] added. How easy is it to change the wiring of this? Easy. Then just feed it to your laser printer... The style of the drawn schematic could be hand tailored to each site if desired. It's time to start thinking of PostScript as a programming language, not just a graphical one. Brad Clements
dambrose@drivax.UUCP (David Ambrose) (03/12/88)
In article <1332@pasteur.Berkeley.Edu> max@eros.UUCP (Max Hauser) writes: >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. >> >>WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!! I would vote for using either Postscript or CGM for schematics. Most graphics packages now take CGM and Postscript printers are very common. The Mac format is rather clunky for both rendering and using due to the translation steps. It is also harder to revise since it isn't object-based. Postscript to HPGL translators have been posted to the net so they should be available to all. -- ______________________________________________________________________________ David L. Ambrose, -- Digital Research, Inc ...!amdahl!drivax!dambrose DISCLAIMER: Don't blame DRI. They wouldn't approve of this anyway. r}ix NO CARRIER
howard@cpocd2.UUCP (Howard A. Landman) (03/30/88)
>In article <1059@PT.CS.CMU.EDU> phd@SPEECH1.CS.CMU.EDU (Paul Dietz) writes: >>WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!! Yes. >>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. Pardon me while I puke. An ASCIIzed bitmap raster as the standard? Gack. In article <1332@pasteur.Berkeley.Edu> max@eros.UUCP (Max Hauser) writes: >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. Excellent foresight, Max. However, there is already a standard emerging for transfer of schematic, simulation, layout, and various other information. I refer, of course, to EDIF. This has the advantage of having been carefully designed and reviewed by numerous very bright people in both academia and industry, and also is officially supported by too many companies to name here (including TI, Daisy, and soon maybe even Intel :-). There is even a committee working on convergence between EDIF and VHDL (VHSIC Hardware Design Language), so even behavioral information may soon be representable. EDIF syntax is based on LISP, which makes the language easily extensible, if somewhat prone to large numbers of parentheses. I would STRONGLY recommend that anyone seriously interested in the easy interchange of electronic design data should educate themselves about EDIF before making ludicrous suggestions for formats like Paul's. -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET
phd@SPEECH1.CS.CMU.EDU (Paul Dietz) (03/30/88)
In article <1213@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >>In article <1059@PT.CS.CMU.EDU> phd@SPEECH1.CS.CMU.EDU (Paul Dietz) writes: >>>WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!! >Pardon me while I puke. An ASCIIzed bitmap raster as the standard? Gack. (Followed by plug for EDIF...) Ok gang. I promised myself that I wouldn't post on this subject until the end of the month. Well here it is, the end of the month... For those of you who remember, I am conducting a vote on wether we should encourage posting of MacPaint format files as a TEMPORARY solution to the schematics problem. Response has been pathetic! More people sent me email with alternative suggestions, than voted! (By the way, the vote so far is a resounding "NO!") I also requested for people who were willing to champion the cause to step forward, and offer up their services to the group. No one has come forward. Ok. So I'm a little disappointed. Almost everyone seems to agree that we need this sort of a facility, but almost no one can agree on a format. And what if we all agreed on EDIF tomorrow? Who's going to port it to the 5 million different net.machines that people expect to be able to read it on? This is why I proposed a TEMPORARY, if somewhat inelegant, solution to the problem. Just to get the ball rolling. But I guess it just wasn't meant to be. So, would some kind soul PLEASE come to our rescue?! Does anybody know a way we can get this thing started without being in a perpetual state of discussion? Paul H. Dietz ____ ____ Dept. of Electrical and Computer Engineering / oo \ <_<\\\ Carnegie Mellon University /| \/ |\ \\ \\ -------------------------------------------- | | ( ) | | | ||\\ "If God had meant for penguins to fly, -->--<-- / / |\\\ / he would have given them wings." _________^__^_________/ / / \\\\-
max@trinity.uucp (Max Hauser) (03/31/88)
To hear all the exotic ideas that came tumbling forward when this topic
first appeared (some of them independently on sci.electronics and comp.lsi,
against my entreaty to keep the discussion on sci.electronics where it
began), one might infer, first, that everyone wants to use a "format" that
is already available to them (no surprise); and, second, that there is no
common vision or assumption about just exactly what this format is
supposed to DO. Allow me to address this point and then (for now) shut up.
Paul Dietz and several respondents seem to have the very specific idea of
posting *pictures*, i.e., strictly-graphic information, incidentally about
circuits. This of course requires a lot of data and an agreeable format.
On the other hand, I feel I have to point out very explicitly what some
have touched on briefly: that if your real goal is communicating circuits
rather than line drawings, requiring actual graphics is unnecesarily
restrictive and it is foolish to limit yourself to that approach. Many
readers have for years been conveying circuits to their CAD software
without so much as a single line being drawn. Before you dismiss this
point because it's not what you had in mind, consider that non-graphical
schematics can encapsulate ALL of the real information a reader needs
to reproduce the circuit; they can (as those not familiar may not realize
at all) be readily readable, easy to compose, and self-explanatory with
the aid of comments (inevitable anyway); they require NO software,
NO graphics device, and NO agreed format; they contain only essentials
(topology, devices and values) and thus require much less net bandwidth
than graphics (while reaching a wider audience); and, finally, we will
have to use them anyway as a lowest-common-denoinator to back UP any
graphics format if we ever want our schematics to be acessible to the
(vast majority of) readers who lack graphics devices or software.
I have of course appended an example, but my point transcends that: if the
real interest is in *circuits* rather than general line drawings, and you
want any substantial fraction of your readers to have access to them, then
an accessible, non-graphics format is obvious, easy, and necessary.
(As one dealing daily with circuit hacking for twenty years, I promise
that it doesn't REALLY matter what direction the transistor points in,
or whether that wire runs above or below, much as some people may have
difficulty imagining a circuit not rendered in their favorite format).
I will say that the process is most straightforward with small discrete
circuits like audio or RF circuits or small logic; if you need to show a
big chip in non-graphic form it becomes a tedious netlist -- but then that
situation is not much different with graphics either.
That was about circuits per se. Now I am the first to agree that it is
also nice to communicate pictures of circuits (as long as we keep in mind
that it is a different objective, with greater obstacles). I have no
easy fix to offer of the kind Paul is calling for, but I certainly agree
with others that they payoff is vastly greater in adopting an established
industrial format where all of the hard thinking and mistake-making has
already been done (by people who know what they're doing). To this end I
reiterate my assertion that in the LONG run we must inevitably adopt
something based on EDIF. Unfamiliar as it might be to many, it's on the
way IN, and it will probably be a lot more familiar to a lot of you in
a few years just in the course of events (just as ASCII is now familiar,
for example, although it brought blank responses when it was new). I
should not have to mention how much it pays to bank on a universal
standard that's on the way IN.
Here's a little circuit in the already-nearly-universal SPICE-type
syntax (in use already at far more sites than the Usenet reaches, BTW).
I'll explain that each line is a device; the first couple of numbers are
node numbers that the device is connected to; and the last number is
a value. It should be obvious that C's are capacitors and R's are
resistors; standard element codes for other common devices exist and
could be readily summarized in a single posting, along with some other
minor details that, if followed, would permit all of the schematics in
this format to be applied directly to SPICE-class circuit simulator
programs so that people could evaluate them without even building them.
Further comments associated with a circuit will readily clarify it
further to human readers. To draw a picture of such a circuit, you start
by getting an idea of what's going on, helped out by thoughtful comments;
you draw numbered points (nodes) according to where you expect the
elements to appear; and then you draw the elements connected to the
nodes. The result may look a little awkward on first drawing but hey,
it's the complete circuit, and it works!
Bridged-T filter; node 0 is gound, 1 is input, 3 is output
R1 1 2 4.7 k
R2 2 3 4.7 k
C1 2 0 100 pF
C2 1 3 330 pF
Max Hauser / max@eros.berkeley.edu / ...{!decvax}!ucbvax!eros!maxmax@trinity.uucp (Max Hauser) (03/31/88)
Sorry, I just noticed that my circuit example in my previous article had extra spaces between the component values and their multipliers, for example "4.7 k"; for standard SPICE format this should have been "4.7k" -- a minor matter but someone might take exception. Exactly such rules can be easily summarized in a posting -- today, if necessary -- in case anyone wants to follow the strict format immediately.
phd@SPEECH1.CS.CMU.EDU (Paul Dietz) (03/31/88)
Max Hauser writes: >Paul Dietz and several respondents seem to have the very specific idea of >posting *pictures*, i.e., strictly-graphic information, incidentally about >circuits. This of course requires a lot of data and an agreeable format. >... consider that non-graphical >schematics can encapsulate ALL of the real information a reader needs >to reproduce the circuit... >(As one dealing daily with circuit hacking for twenty years, I promise >that it doesn't REALLY matter what direction the transistor points in, >or whether that wire runs above or below, much as some people may have >difficulty imagining a circuit not rendered in their favorite format). On this point, I disagree with Max. The purpose of posting schematics is mostly educational: the object is to make them understandable. Like it or not, the way we draw things definitely influences our interpretation. For this reason, I would like to see position information as an elemental part of anything we do. For instance, I can get a feel for a properly drawn 30 transistor op amp in just a few seconds. If you handed me the netlist, it would probably take me the better part of an hour before I had an equivalent understanding. Circuit information comes in many forms: schematics, timing diagrams, mask layouts, pcb's, flow charts, etc. An image representation has the advantage of handling all of these equally well. As Max said: >That was about circuits per se. Now I am the first to agree that it is >also nice to communicate pictures of circuits (as long as we keep in mind >that it is a different objective, with greater obstacles). Now, just to prove my ability to do an about-face, I think Max is absolutely correct in the need to keep our short term goals modest. Circuits is ultimately what sci.electronics is all about! So for the time being, I think a slightly modified SPICE type format will have to do. The modifications are necessary to support rather arbitrary devices. (SPICE doesn't know about things like uP's or the light bulbs in a Wien Bridge...) This will serve two purposes: for circuits that can easily be simulated by SPICE, we should stick to straight (or easily machine translated to straight) SPICE files. I even volunteer to write the C code to do the translation if it is easy enough! For more random type circuits, when SPICE is not appropriate, we will at least have a standard netlist format for various programs to take advantage of. So, let's have some discussion on this! [By the way Max, your SPICE deck will make SPICE rather unhappy. Last I heard, small letters are a no-no, along with no .END card, etc... These are the sorts of things we should modify, to make it more forgiving. As I said, I'm willing to write the C code to do this.] Paul H. Dietz ____ ____ Dept. of Electrical and Computer Engineering / oo \ <_<\\\ Carnegie Mellon University /| \/ |\ \\ \\ -------------------------------------------- | | ( ) | | | ||\\ "If God had meant for penguins to fly, -->--<-- / / |\\\ / he would have given them wings." _________^__^_________/ / / \\\\-
dick_a_wotiz@cup.portal.com (04/01/88)
OK... here's my 2 cents worth....
I think Max's suggestion of a non-graphical format may be the most
practical so far; it sems there are just too many different formats
around to cover a majority of classes of machines.
But... of all the microcomputer-based CAD packages I have ever used,
the most popular configuration seems to be support for an Epson printer.
What about posting a bit-graphics file that can be printed out on any
Epson-compatible printer, even though it can't be displayed on the screen?
Even most of the laser printers around support some form of Epson
emulation in addition to their native mode.
It might take 2-3 minutes to print out, but it sure beats writing a
MacPaint (or whatever)-to-<insert favorite machine here> convert program!
- - - - - - - - - - - - - - - - - - - - - - - -
Dick Wotiz dick@portal.com
dick@cup.portal.com
...!{uunet|sun|atari}!portal!dickhenry@utzoo.uucp (Henry Spencer) (04/03/88)
The problem with the SPICE format is that a *picture* is precisely what
most people want, and constructing one from SPICE format is a lot of work.
I suspect that the thing to use is a simple line-drawing format, the
simpler the better, so that people can easily interface it to their own
particular (peculiar? ;-)) graphics output devices. The weakness of all
the spiffy formats already in existence is that they are non-trivial to
interpret if you don't already have software that handles them. The
thing to do is to think stupid, not spiffy.
--
"Noalias must go. This is | Henry Spencer @ U of Toronto Zoology
non-negotiable." --DMR | {allegra,ihnp4,decvax,utai}!utzoo!henrymax@trinity.uucp (Max Hauser) (04/04/88)
In article <1988Apr2.233629.27043@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >The problem with the SPICE format is that a *picture* is precisely what >most people want, and constructing one from SPICE format is a lot of work. Of course; but much less work than displaying a picture with a graphics device that you don't have, or that's incompatible, or that doesn't yet have software for the graphics "format," or etc. or etc. Like it or not, no major fraction of your readers will have access in the near future to whatever picture format you finally choose, and you need a common denominator, even if clumsy, that can precisely and unambiguously communicate your circuit, if you actually want to make it available to everyone else, rather than to a small clique (which, the way things look, might as well be served by a mailing list rather than a newsgroup in the foreseeable future). Sketching a circuit by hand from a SPICE file, if it's a circuit you want, still certainly beats not having it at all. No one would like pictures more than I, as I've tried in previous postings to make crystal clear. In the MEANTIME we are already posting actual circuits, while the discussion about picture formats continues ... Max Hauser / max@eros.berkeley.edu / ...{!decvax}!ucbvax!eros!max
keithe@tekgvs.TEK.COM (Keith Ericson) (04/04/88)
In article <1213@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: > >I would STRONGLY recommend that anyone seriously interested in the easy >interchange of electronic design data should educate themselves about EDIF... > I don't know about the rest of you, but I will be posting my schematics using a LOGO program to generate a turtle-graphics representation of the schematic. That should take care of it, eh? (Now where _did_ I put that shareware LOGO interpreter...?) keith
styer@pyr.gatech.EDU (Eugene Styer) (04/05/88)
I'll throw in my $.02 on the subject. In thinking about what to do, I came up with the idea of indicating each component and wire by a set of XY coordinates. A wire might be represened by (1,1)->(1,5)->(6,5)->(6,6) and a transistor by something like 2n222 base=(1,1) collector=(1.5,1.5) emitter=(1.5,.5) then recreating the circuit would be simply taking a piece of paper, and drawing at the places indicated by the coordinates. It should be easy to make a format that could be easily translated to a graphics image (for those with workstations, etc.). I'm not sure how easy it would be to generate such a format from a graphics image, but I would appreciate other's comments on the subject. ---------------------------------------------------------------------- Eugene Styer Ga. Tech Box 32036 Georgia Insitute of Technology, Atlanta Georgia, 30332 (404)-872-9185 styer@gitpyr.gatech.edu
straka@ihlpf.ATT.COM (Straka) (04/05/88)
In article <1988Apr2.233629.27043@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >The problem with the SPICE format is that a *picture* is precisely what >most people want, and constructing one from SPICE format is a lot of work. Perhaps some "relatively" common DRAWING interface like HPGL of UNIX(R)'s "pic" language could be of use. HPGL is pretty common, with some translators available, while "pic" is common on Unix systems and is relatively human-readable. Or perhaps some really simple derivation like: resistor 2K 3,4;3,5 capacitor 220pf 3,5;4,5 xistor(ebc) 2N3905 6,7;5,6;6,5 where the last numbers are pairs of GRAPHICAL x,y coordinates. I, too think that a PICTURE would suffice. If we are talking about circuits complex enough that someone wants to avoid the pain of going through schematic capture, *I* would suspect that we're going a bit beyond the scope of the newsgroup (although that level of complexity might be something to drool over). -- Rich Straka ihnp4!ihlpf!straka Advice for the day: "MSDOS - just say no."
rusty@cadnetix.COM (Rusty Carruth) (04/07/88)
In article <5318@pyr.gatech.EDU> styer@pyr.UUCP (Eugene Styer) writes: >I'll throw in my $.02 on the subject. In thinking about what to do, I came >up with the idea of indicating each component and wire by a set of XY >coordinates. A wire might be represened by >(1,1)->(1,5)->(6,5)->(6,6) >and a transistor by something like >2n222 base=(1,1) collector=(1.5,1.5) emitter=(1.5,.5) >then recreating the circuit would be simply taking a piece of paper, and >drawing at the places indicated by the coordinates. Well, I started this out by liking the idea, then decided that it would be very hard to create such a beast. How about using a netlist format? (I can even generate one of those HERE!) If we used a sort-of standard/vanilla version, we might get away with using various different pacakges. Seems to me that there are even PC-based schematic capture tools which can generate and accept netlists? Hmmm...