Schematic preferences [Design]

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: Joel Koltner on 19 Jan 2010 13:12

"Jon Kirwan" <jonk(a)infinitefactors.org> wrote in message
news:gpibl5l1cktp3hdqqahk8lk7pc5b7fist5(a)4ax.com...
> Suddenly, I decided to redraw it this way:

[snip]

I agree with you, that way does make it a little more obvious where the
"functional" splits of the circuits are.

Popular Electronics (and similar) other create quite horrific schematics in a
quest to reduce the number of pages needed for display, unfortunately.

---Joel

From: Joel Koltner on 19 Jan 2010 13:22

"mpm" <mpmillard(a)aol.com> wrote in message
news:3845b39c-4e2e-4e73-86b3-a5e9a27719a1(a)p8g2000yqb.googlegroups.com...
"I once worked for a video company that had a PLL circuit that
traversed 6 or 7 different circuit boards."

That sounds familiar. We'll often have, e.g., an RF board, a digital board, a
display board, a power supply board -- or some assortment thereof -- and
different engineers working on each one. Out of necessity (chicken and the
egg problem) initially sometimes not all the net names for connectors going
between these boards match up, but by the time you're going to fab real
production boards they should. Getting everyone to agree on the names sooner
rather than later is better, though, as if 3 months have gone by people will
have sometimes become rather attached to *their* net name, used it in their
C/assembly/VHDL/Verilog/etc., and be more reluctant to change it to what "the
other guy" used.

The main exception to that idea is when you have, e.g., serial transmit and
receive lines -- you don't want to just use "Tx" and "Rx" since one board's Tx
is the other's Rx. The best resolution there that I'm aware of is to label
one connector's nets, e.g., "uC_Tx" and "uC_Rx" on, say, the board with a
microcontroller on it, and then "DSP_Rx" and "DSP_Tx" on the board with the
DSP on it. (One could go for, e.g., uC_2_DSP_Tx everywhere, although that can
get overly wordy fast, and it still looks a little odd on the DSP board.)

When labeling pins on "user definable" parts like FPGAs and microcontrollers,
I always have signal names be *with respect to that same part*. E.g., Tx, Rx,
Ready, Ack, Request, etc. -- that sort of thing.

---Joel

From: D Yuniskis on 19 Jan 2010 13:42

krw 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).
>
> I really want the same thing out of the schematic as do my
> "customers". In a year I won't remember what I did, so it's got to be
> readable (source code is the same deal - in spades).

Exactly. I commented recently to a friend: "Schematic *is* your
'product' (deliverable)."

For the past dozen years or so I have taken to preparing formal
"circuit descriptions" (as well as for the accompanying software)
so that I can *talk* to my future self (or customer). It is
especially helpful when you've done something unusual and may
need to clarify that for someone else (or yourself).

It is invaluable for documenting differential stuffing options
which, otherwise, could be too verbose to add to a schematic
(e.g., install X & Y but only if Z is depopulated and W is
increased to a 1/2W device to get the following capabilities...)

>> 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.
>
> Yes, Landscape always seems to work out better. I just use 11x17 and
> stick it in a notebook sideways, with a fold. I'd do longer (I really
> print with a 1" offset so it comes out 11"x18") but haven't found I
> need more space that direction (without running out of vertical space
> first). OTOH, the other engineer likes C-size prints. I find they're
> a PITA on the bench (or pretty much anywhere). I end up printing his
> on 11x17 and squinting. ;-)

C on B is readable. C on A is just smudge marks. :>
B on A leaves the nice inch or so along the binding edge.
B on legal is suitable for troubleshooting (though not
publication)

>> 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 try, though the drawing tools suck. I'd much prefer a hierarchical
> design, killing both birds, but the software isn't up to it.

I played with that early on but often there are too many
"little things" that want to cross over between "blocks"
that muddy up the general flow that it intended to be
conveyed in that document. (BTW, this is something that
is sorely missing in the documentation of most software
projects -- you can't even sort out which file has the
*start* for the program!)

If the (hardware) design lends itself to a clean partitioning,
a block diagram often points you to *the* page that you need
to consult (plus power/ground distribution) whether you are
debugging software or troubleshooting the hardware. The rest
of the schematic can sit in a drawer...

>> I prefer spreading things over one sheet instead of trying to cram

Grrrr... s.b. "over MORE THAN one sheet"

>> 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.
>
> I can usually keep off-sheet connectors to a minimum, placing an
> entire "channel" or such one sheet - maybe two. There is usually a
> logical break somewhere. It often costs a bit of paper, though.

Exactly. Virtual paper is cheap.

>> 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!
>
> Sooner or later the design is going to overflow a sheet. Not only is
> "E-size" a PITA, but so is "C-Size", IMO. Larger pages have more
> signals running around, too. Long wires are hard to follow.

I developed the preference for seeing each signal *as* a signal
(no busses, etc.) when I would check boards (layouts) by hand.
A yellow highlighter and a schematic with all "wires" shown
as *signals* made it much easier to tell when you had finished
checking a net.

The preference has been a win at other times, too, as I can
tell when I have examined each place that a signal runs
without having to examine a fat bus looking for each "peel off"
to see if that might be the signal I am interested in.

But, as you say, when pages get big, it is easy to lose track
of a signal as you try to follow it around the board (it's
as if your eyes "twitch" and, when they come back into
focus, you are never sure they have locked back onto the
correct signal or one adjacent to it).

>> [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? :> ]
>
> Get glasses. ;-) Bifocal reading glasses (two strengths, both for
> close work) work for me.

I have several pair around the house but rarely need them
for paperwork -- if I avoid C reduced to A, that is! :>
I find reading glasses troublesome when I need to look
*up* at something (e.g., the screen, if I am debugging).
Makes the world swoon a bit.

>> One signal, one name. One *instance* of that name per sheet!
>> Signals spanning pages are named at the edge of the page.
>
> Good idea, when it's possible without making the sheet look like a
> rat's nest. It usually is, though there are exceptions.

If you favor smaller drawings, this is usually OK. If, OTOH,
you start making bigger drawings with lots of signals and
devices, there tends to be more spilling over onto other
sheets and this can result in the page looking like "ruled
paper"

>> 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.
>
> *ALWAYS* include off-sheet references.

<frown> I don't do that. E.g., I have a set of little boards
that I'm just designing. Three sheets, tops, for any of the boards.
If you're on the "Power Supply" page and can't figure out that
a signal comes from or goes to the "CPU" page, you shouldn't be
reading the drawings! :>

>> "Left to right, top to bottom"
>
> Left to right (bidirectionals go either way unless there is tristate
> output on the net - then it gets more complicated). Top and bottom
> are for power only.

I've favored putting BiDir pins on the right side of components
though suspect the left side may be a better choice. <shrug>

>> 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).
>
> Wrong! Busses wherever they make sense. *NEVER* connect bussed
> signals off page. Off-page connectors on busses are shown as busses
> *only*. They get fanned out to nets on the page, as close to the part
> as possible. Do you really draw 64 individual wires with 64 off-page
> connectors for each wire in a 64-bit data bus? Ick!

I dislike busses because you can never tell *easily* if a signal
entering a bus is going to come out of it on that page *anywhere*!
All the bus lets you do is "save ink" and cram more stuff onto
a single page. I don't mind having a page with ROMs on it
and *another* page with RAMs, etc. I don't need to have a single
"(all) Memory" sheet.

>> Exploit symmetry and repetition. Step and repeat is your friend.
>
> Hierarchy is your friend. Schematic entry tools aren't. ;-)
>
> Be careful with step and repeat. It's *really* easy to forget to
> change all instances of facilities that differ between copies. DRC
> and browsing the netlist can help here.

Yup. I find that showing "identical copies" of something (be it
a subcircuit on a schematic or a bit of code that gets repeated)
helps people understand what is going on. "Oh, this is just another
copy of _______".

The flip side of this is that if you make a subtle change to that
"copy", you need to do something to make it noticeable so a
lazy observer doesn't assume it is identical and miss the
difference!

>> As with *anything*, color has no significance!
>
> Significance, no, but importance, yes. IOW, the netlister shouldn't
> care about color but the human reading it does. It *must* be
> consistent.

No. Too many people are colorblind (7+% of men). If you put
meaning into color, then that portion of the population will
miss your meaning. And, if the document is (will be!)
reproduced, chances are, at some point, it will be rendered
in B&W.

>> Avoid 4-way streets -- unless their use significantly cleans
>> up the appearance. "Dots" (big ones!) on all connections
>> (mandated by the relaxed 4WS rule).
>
> I don't have problems with 4-way streets. Dots are plain enough to
> see.

I don't llike them unless they improve the appearance or
readability of the schematic. I see people going out of their
way to avoid a 4WS and, as a result, putting lots of doglegs
into signal paths (which are *more* annoying, IMO)

>> 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!)
>
> IEEE symbols suck. Rockets and bullets, everything else is a box;
> clocks and active levels marked appropriately

Boxes are a cop-out. :> They don't encourage you to think
about how you want to draw that symbol. They don't convey
any added meaning (why not draw *everything* as a box? Try
reading a 200 page schematic where everything is drawn as
a box and you will see how quickly the schematic ceases
to be working *with* you but, rather, *against* you! :> )

I want my schematics to tell me what's going on in the circuit.
Just having a box with a pin with some cryptic label doesn't
tell me what to expect to see at that pin nor what to expect
from the circuit as a response to activity on that pin.

Granted, in this day of ever increasing integration, many
devices *are* becoming "just a box". But, memory can still
look like memory, counters like counters, etc. I don't want
to have to keep space for several OPEN databooks on the
bench in addition to the circuit under test *and* the
schematic if the schematic can serve this other purpose.

>> DeMorgan equivalents as appropriate. (I won't get into the rules
>> I use for building symbols as they get pretty involved)
>
> Yes, and signal names must match the symbol's polarity.

That's tricky. I used to be a fan of the FOO/BAR notation
when I would draw everything on tenth ruled vellum (i.e.,
READ/WRITE where the symbol to the right of the / represented
the "negated" version... as if the / had slid off the top
of the word to its right).

But, in the dozen? or so schematic and layout packages I've used
over the years, I found some placed restrictions on signal names
that forced me to be more conservative. I.e., '/' may not be
tolerated in some netlisters; ditto for '+' or '-'. Prefacing
a signal with 'N' ends up giving you a sh*tload of signals
that sort into that group (too much "noise"). Following a
signal name with 'N' can lead to problems with already cryptic
names (is ROM_EN actually /ROM_E or ROM_ENable?).

So, I will often label signals ignoring any "negated" convention.
E.g., RUN and STOP instead of RUN and RUNN (or NRUN).

>> 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).
>
> That depends. Sometimes a connector sheet can be used to show the
> layout of the connectors. This is very handy when there are a lot of
> the same kinds of connectors. Again, the idea is to convey as much
> information as possible about the board.

I disagree, there. The schematic should convey information
about the *circuit*. The *layout* should convey information
about the *board*! :> I should be able to change the layout
irrespective (?) of "pictures" on the schematic.

>> 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.
>
> Diagree. It's very handy to have our XLR connectors look like XLR
> connectors, in the proper orientation. Information. Interboard
> connectors and headers also are drawn physically (in order, odds on
> one side and evens on the other). BNCs are drawn big-circle little
> circle/dot (dots=male, circles=female).

You're tying the design to the physical implementation. I leave
leave the choice of connector, etc. until layout. "I need a 6 pin
connector, here". I want to decouple the two processes as much as
possible. If the physical constraints that show up *in* layout
(is the board going to be long and skinny? square? *ROUND*??)
suggest that some particular implementation is preferable to
another, then I don't want to have to "fix" the schematic to
show pictures of those different connectors, etc.

>> Only *terse* notes re: layout/manufacture/test on the actual
>> drawings; anything more verbose goes on a "notes" sheet.
>
> We put ECO notes on the sheets in red before the ECO and in blue for

<frown> "Color".

> one revision after, in addition to the "Notes:" block on page-1. We
> also put a note on each subcircuit explaining what it is:
>
> +--------------------+ +-------------------------------+
> | 4-pole Butterworth | - or - | Load Switching Bus |
> | H.P. F0=1kHz G=6dB | +---+---+---+---+---+---+---+---+
> +--------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
> +---+---+---+---+---+---+---+---+
> |8nF|4nF|2nF|1nF|800|400|200|100|
> +---+---+---+---+---+---+---+---+

I like "subtitles" in the schematic "in the general area of"
that portion of the circuit that "does" that "thing".
E.g., "Program Memory", "Address Decoding", "Burger Flipping", etc.

>> 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? :>
>
> No pictures. They take way too much space. Voltages, yes. Keping
> any documentation up to date is a problem. Notes are no different
> than comments in code.

I find scope traces to be invaluable helping others debug analog
portions of designs (e.g., in the power supply). They tend to
be irrelevant in digital portions as many things are aperiodic.

>> 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!)
>
> Disagree, sorta. We put the revisions on the first page of the
> schematic and keep two or three (whatever fits). It's there as a
> reminder only and certainly doesn't supercede the ECO system. We also
> add notes to the schematic (in red) to incorporate if we ever hit the
> board again. Again, those are reminders only and don't supercede the
> problem reports and such.

The problem there is you have two copies of information which will
*inevitably* get out of sync. Someone will read the notes on the
schematic (cuz they are too lazy to pull the ECO from a file)
and fail to see something that was expounded upon in the ECO, etc.

>> 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! :-/
>
> Here's one. ;-) We have schematics that are essentially twelve itsy
> pages of schematics crammed onto one C-sized page. *Very* bad, though
> when I gagged during the interview it made big points with the
> engineering manager. ;-)

A paper cutter is your friend!

I'll add an extreme distaste for "things upside down" (or, more
generally, "not in their proper orientation". A TI schematic
last night had GND symbols pointing up (like antennae). And,
pointing left/right. Sheesh! Couldn't you figure out how
to route the signals so the symbol took its NORMAL orientation??

From: cassiope on 19 Jan 2010 13:34

On Jan 19, 12:17 am, D Yuniskis <not.going.to...(a)seen.com> wrote:
> Hi John,
>
> John Fields wrote:
> > On Mon, 18 Jan 2010 16:13:23 -0800, John Larkin
>
> >> 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.
>
> That's how I used to draw things. But, I found it often resulted
> in clumsy signal routing -- just to avoid a 4WS.
>
> I don't worry about people adding dots to *my* drawings. :>
> The bigger worry I have is when schematics are reproduced
> and it becomes difficult to determine if there is or isn't
> a dot on the junction.

If it really seems necessary to have a 4- (or more) way point, I draw
at least
one of the lines in at an angle (view monospace):
|
|
------------o------------
/
|
|
as well as a dot. That bit of redundancy helps in this unusual
situation.

BTW - as another old ex-Tekie - I have to note that it was always
amazing
to get the first "official" schematics back from the "drawing
droids". Though
both the engineers and the draftsfolk used the same rules, the
drawings
we got back always seems dramatically different than what we had given
them.

From: D Yuniskis on 19 Jan 2010 13:47

MooseFET wrote:
> On Jan 19, 12:29 am, D Yuniskis <not.going.to...(a)seen.com> wrote:
>> John Larkin wrote:
>>> On Mon, 18 Jan 2010 18:39:06 -0800 (PST), MooseFET
>>> <kensm...(a)rahul.net> wrote:
>>>> The reference of a part encodes the page it is on. R307 is on page 3
>>> Yikes! Production would lynch us. After the layout is done, we
>>> resequence the reference designators in physical and numeric order and
>>> back-annotate the schematic.
>> Ditto. The problem I find with EDA tools is they don't let you
>> put "tags" in text on the sheets. E.g., if you have a note:
>> "D1 - D4 installed on heatsink" and you backannotate the
>> schematic, D1 may no longer be D1, etc. So, you have to manually
>> go through and update the notes. It would be nice if you could
>> set up cross reference tags like in DTP tools...
>
> For issues like that:
> Put "NOTE 1" next to the parts on the heat sink with a dashed outline
> Then make NOTE 1 say "These parts are on the heat sink"

Understood. In this case, it would have been too cramped to
put notes next to the sixteen components involved. So, I
opted for "Diodes installed on heatsink" below the bridges.
Or, "Required for Type A application" next to one group of
components and "Required for Type B application" next to
another.

I.e., you learn how your tools are going to screw you and
adopt your documentation style accordingly! ;-)