Prev: Oil sources Was: Re: Would magn. pole reversal actually mess up electronic equipment?
Next: Oil sources Was: Re: Would magn. pole reversal actually messup electronic equipment?
From: D Yuniskis on 18 Jan 2010 15:37 Hi, Of course, this is *highly* subjective -- but, I'd enjoy hearing folks' "conventions" used when preparing schematics (that *others* will consume -- how you scribble for your own purposes isn't important as it depends a lot on what *you* want out of the drawing). I try to follow some general rules -- but also feel free to bend them as needed. Most have evolved over the years from different employers, standards, experience, etc. E.g., I *tend* to prefer landscape orientation -- though I drew a B size "portrait" this morning in lieu of a C size landscape. I try to include a block diagram of any "sizable" design early in the document. I try to draft the individual pages so that they roughly correspond with the blocks in that diagram. I prefer spreading things over one sheet instead of trying to cram everything onto one sheet -- unless the design is small enough to do so without making that sheet cluttered. I.e., it is easier to trace a signal on a single sheet than to have to flip to another sheet; but, if there is a ratsnest of signals on that one sheet, then tracing the signal can be perilous. Smallest page size to realistically support the design subject to the remainder of these criteria. E.g., sure, you can fit everything on an E-size drawing, but reproducing that drawing (either full size or in "published" documentation) and *using* that drawing become a real PITA! [I vacillate between preferring B or C size drawings. C is nice in that it reduces to A nicely (i.e., with the same aspect ratio) OTOH, B is nice because reducing to A leaves room along the binding edge -- which must be located "above" the drawing! -- for three hole punch *or* more professional binding. And, B size can always be reproduced full size with "fold outs". (frown) B size (reduced or otherwise) is currently en vogue -- perhaps a consequence of my aging eyes? :> ] Aside from "general power", all signals that span pages *must* come to the edge of the page. I don't like hunting for signals in the middle of a page even if there is a grid reference to help me locate it. It's just easier to conceptualize: "OK, this is used elsewhere" or "This comes from someplace else" so I know when something I am interested in involves other sheets. One signal, one name. One *instance* of that name per sheet! Signals spanning pages are named at the edge of the page. For designs of "suitable complexity" (in terms of sheets/signals), I tag off page references with locations of the other "end(s)" of the signal. If its a small design -- or, if the schematic is broken down intuitively -- I assume the "other ends" will be self explanatory. "Left to right, top to bottom" Eschew buses -- except on "block diagrams". Show individual signals. Avoid unnecessary "bends" in signals. *Most* signals parallel to page edges (some tools prevent you from doing otherwise). Symbols oriented horizontally and suggestive of the direction of signal flow (i.e., a gate in a feedback path can point to the left). "Rocket ships crash (and burn)" :> Exploit symmetry and repetition. Step and repeat is your friend. As with *anything*, color has no significance! Avoid 4-way streets -- unless their use significantly cleans up the appearance. "Dots" (big ones!) on all connections (mandated by the relaxed 4WS rule). Descriptive symbols (e.g., a diode bridge looks like a diamond) and informative symbols (e.g., IEEE unless the device *really* is a "black box" -- I don't consider *memory* to be a black box!) DeMorgan equivalents as appropriate. (I won't get into the rules I use for building symbols as they get pretty involved) Reference designator before device name/value. Either both to one side (left/right/top/bottom) or one on each side (left/right, top/bottom). Unless a connector(s) inherently *merits* location on a separate sheet (e.g., a PCI connector whose "pins" feed many other sheets), locate the connector with the signals that tie to it (i.e., no sheets full of connectors). Don't tie the schematic to a physical implementation. I.e., the symbol for a connector shouldn't physically look like the connector just as the symbol for a transistor doesn't look like the transistor itself! If you need to clarify the appearance or pin layout of a component, do so in text or other documentation outside of the "schematic" itself. Decoupling caps specifically required by individual components located proximal to the component symbols themselves. Other "general" bypass caps grouped on a single sheet. Power and ground connections not explicitly shown on components tabulated on that same sheet, if possible. Only *terse* notes re: layout/manufacture/test on the actual drawings; anything more verbose goes on a "notes" sheet. On analog portions of the design, test voltage annotations and 'scope traces, where *essential*. Remember, everything you put on the drawing has to be *maintained*! If you make a change, are you prepared to capture another 'scope trace? :> Document history on the cover page *only*. One firm I worked for used to summarize *all* revisions of a schematic *on* the schematic. I.e., lots of little "windows" showing portions of the schematic as they existed previously. I think this is a poor man's way of *not* using "proper" document retrieval systems (i.e., if I need Rev C of a design, then I should fetch the Rev C documents!) I suspect there are many more that I just take for granted and have failed to mention, here. :< *Somewhere* I have a document formalizing all of these things. Though I suspect it is in a format particular to a DTP program that I no longer have on-line! :-/
From: Jon Kirwan on 18 Jan 2010 19:05 On Mon, 18 Jan 2010 13:37:16 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Of course, this is *highly* subjective -- but, I'd enjoy hearing >folks' "conventions" used when preparing schematics (that *others* >will consume -- how you scribble for your own purposes isn't >important as it depends a lot on what *you* want out of the >drawing). ><snip> I was trained at Tektronix for drafting electronics, so my preferences come from there. >Aside from "general power", all signals that span pages *must* >come to the edge of the page. I don't like hunting for signals >in the middle of a page even if there is a grid reference to help >me locate it. It's just easier to conceptualize: "OK, this is >used elsewhere" or "This comes from someplace else" so I >know when something I am interested in involves other sheets. ><snip> Let me state the following rules used at Tek: (1) Unless clearly justifiable for other reasons, electron flow from bottom of page upwards to the top. All parts oriented so that this is obvious. (No BJT spun around to make electron flow go otherwise, unless I can _justify_ clearly why it reads better.) (2) Signals flow from left to right across the page. I think of these two rules, easily. The electrons flow like a waterfall upwards (or positive charges flow down, your choice) in order to "permit" signals to flow across, from left to right. The signals ride across the sheet on the flow. (3) Don't bus power around unless there is some physical characteristic that must be emphasized by doing so. If the emitter of a PNP BJT is tied to +5, I don't bus the emitter over to some heavy black line tied to power. I just stub it right there to the named +5 rail. It does NOT help readability to have lots of black lines running all over the place, almost as though they are signal lines. In fact, it distracts from understanding. You don't need to know any of the other connections to that named +5 rail to know what is happening at the BJT. All you need to know is that it is at that rail's potential. The wire just adds "noise" to the page and makes you go trace around looking to see that it actually _is_ a rail and not something else. That's enough for now, I suppose. Jon
From: John Larkin on 18 Jan 2010 19:13 On Mon, 18 Jan 2010 13:37:16 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi, > >Of course, this is *highly* subjective -- but, I'd enjoy hearing >folks' "conventions" used when preparing schematics (that *others* >will consume -- how you scribble for your own purposes isn't >important as it depends a lot on what *you* want out of the >drawing). > >I try to follow some general rules -- but also feel free to bend >them as needed. Most have evolved over the years from different >employers, standards, experience, etc. > >E.g., I *tend* to prefer landscape orientation -- though I >drew a B size "portrait" this morning in lieu of a C size >landscape. We do everything B size, landscaps, an we have a couple of B size laser printers. > >I try to include a block diagram of any "sizable" design early >in the document. I try to draft the individual pages so that >they roughly correspond with the blocks in that diagram. Our first sheet is a block diagram and table of contents. ftp://jjlarkin.lmi.net/22SS346A.pdf > >I prefer spreading things over one sheet instead of trying to cram >everything onto one sheet -- unless the design is small enough >to do so without making that sheet cluttered. I.e., it is easier >to trace a signal on a single sheet than to have to flip to >another sheet; but, if there is a ratsnest of signals on that >one sheet, then tracing the signal can be perilous. We avoid high density in favor of clarity. The schematic I'm checking now is 34 sheets. > >Smallest page size to realistically support the design subject >to the remainder of these criteria. E.g., sure, you can fit >everything on an E-size drawing, but reproducing that drawing >(either full size or in "published" documentation) and *using* >that drawing become a real PITA! > >[I vacillate between preferring B or C size drawings. C is nice >in that it reduces to A nicely (i.e., with the same aspect ratio) >OTOH, B is nice because reducing to A leaves room along the >binding edge -- which must be located "above" the drawing! -- for >three hole punch *or* more professional binding. And, B size >can always be reproduced full size with "fold outs". (frown) B >size (reduced or otherwise) is currently en vogue -- perhaps a >consequence of my aging eyes? :> ] > >Aside from "general power", all signals that span pages *must* >come to the edge of the page. I don't like hunting for signals >in the middle of a page even if there is a grid reference to help >me locate it. It's just easier to conceptualize: "OK, this is >used elsewhere" or "This comes from someplace else" so I >know when something I am interested in involves other sheets. I'd expect that rule to make things quite a bit uglier. > >One signal, one name. One *instance* of that name per sheet! >Signals spanning pages are named at the edge of the page. > >For designs of "suitable complexity" (in terms of sheets/signals), >I tag off page references with locations of the other "end(s)" >of the signal. If its a small design -- or, if the schematic is >broken down intuitively -- I assume the "other ends" will be >self explanatory. > >"Left to right, top to bottom" > >Eschew buses -- except on "block diagrams". Show individual >signals. Avoid unnecessary "bends" in signals. *Most* signals >parallel to page edges (some tools prevent you from doing otherwise). Right. No busses. > >Symbols oriented horizontally and suggestive of the direction >of signal flow (i.e., a gate in a feedback path can point to the >left). "Rocket ships crash (and burn)" :> > >Exploit symmetry and repetition. Step and repeat is your friend. > >As with *anything*, color has no significance! > >Avoid 4-way streets -- unless their use significantly cleans >up the appearance. "Dots" (big ones!) on all connections >(mandated by the relaxed 4WS rule). We use big (75 mils in PADS) dots. There's nothing wrong with a 4-way connection if the dots are obvious. > >Descriptive symbols (e.g., a diode bridge looks like a diamond) >and informative symbols (e.g., IEEE unless the device *really* >is a "black box" -- I don't consider *memory* to be a black box!) >DeMorgan equivalents as appropriate. (I won't get into the rules >I use for building symbols as they get pretty involved) > >Reference designator before device name/value. Either both to >one side (left/right/top/bottom) or one on each side (left/right, >top/bottom). R12 4.7K I hate the "4k7" notation. > >Unless a connector(s) inherently *merits* location on a separate >sheet (e.g., a PCI connector whose "pins" feed many other sheets), >locate the connector with the signals that tie to it (i.e., no >sheets full of connectors). OK > >Don't tie the schematic to a physical implementation. I.e., >the symbol for a connector shouldn't physically look like >the connector just as the symbol for a transistor doesn't >look like the transistor itself! If you need to clarify >the appearance or pin layout of a component, do so in >text or other documentation outside of the "schematic" itself. OK > >Decoupling caps specifically required by individual components >located proximal to the component symbols themselves. The trick is to get the layout person to actually place them that way! Other >"general" bypass caps grouped on a single sheet. Power and >ground connections not explicitly shown on components tabulated >on that same sheet, if possible. We are lately making all pins visible... no hidden power/ground pins. > >Only *terse* notes re: layout/manufacture/test on the actual >drawings; anything more verbose goes on a "notes" sheet. If it's useful, put it there. > >On analog portions of the design, test voltage annotations >and 'scope traces, where *essential*. Remember, everything you >put on the drawing has to be *maintained*! If you make a change, >are you prepared to capture another 'scope trace? :> > >Document history on the cover page *only*. One firm I worked for >used to summarize *all* revisions of a schematic *on* the schematic. >I.e., lots of little "windows" showing portions of the schematic >as they existed previously. I think this is a poor man's way of >*not* using "proper" document retrieval systems (i.e., if I >need Rev C of a design, then I should fetch the Rev C documents!) We document no changes on the schematic. We maintain separate change files. We do have a NEXT folder on a server, with a sub-folder for each board. That contains text files like "B_to_C.txt" where anyone in the company can add notes, requests, suggestions of things to consider for the next rev. John
From: John Larkin on 18 Jan 2010 19:26 On Mon, 18 Jan 2010 16:05:19 -0800, Jon Kirwan <jonk(a)infinitefactors.org> wrote: >On Mon, 18 Jan 2010 13:37:16 -0700, D Yuniskis ><not.going.to.be(a)seen.com> wrote: > >>Of course, this is *highly* subjective -- but, I'd enjoy hearing >>folks' "conventions" used when preparing schematics (that *others* >>will consume -- how you scribble for your own purposes isn't >>important as it depends a lot on what *you* want out of the >>drawing). >><snip> > >I was trained at Tektronix for drafting electronics, so my >preferences come from there. > >>Aside from "general power", all signals that span pages *must* >>come to the edge of the page. I don't like hunting for signals >>in the middle of a page even if there is a grid reference to help >>me locate it. It's just easier to conceptualize: "OK, this is >>used elsewhere" or "This comes from someplace else" so I >>know when something I am interested in involves other sheets. >><snip> > >Let me state the following rules used at Tek: > >(1) Unless clearly justifiable for other reasons, electron >flow from bottom of page upwards to the top. All parts >oriented so that this is obvious. (No BJT spun around to >make electron flow go otherwise, unless I can _justify_ >clearly why it reads better.) PNP emitters up, NPN emitters down! John
From: John Fields on 18 Jan 2010 20:10
On Mon, 18 Jan 2010 16:13:23 -0800, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >We use big (75 mils in PADS) dots. There's nothing wrong with a 4-way >connection if the dots are obvious. --- If one knows what's happening at that junction, that's fine, but it's happened more than once that a drafting droid saw two lines crossing and figured they should be connected. Resolving that ambiguity by breaking that "intersection" into two tees disappears the problem. JF |