Schematic preferences

[D Yuniskis]

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...)

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, 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...

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

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.

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.

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"

*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 (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

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.

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!

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.

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)

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.

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).

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.

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.

We put ECO notes on the sheets in red before the ECO and in blue for

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.

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.

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.

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??

 

[D Yuniskis]

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! ;-)

 

[Nico Coesel]

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.

That depends on your printer. On a shitty printer A4/letter size may
be the maximum for a readable diagram while a good printer will allow
for much more on one page.

 

[D Yuniskis]

Good point. With a few macros in your favorite text editor this is
pretty easy to "fix," but I can see how that could be more hassle than
it's worth.

Our schematics often have many hundreds of nets (often over a thousand)
of which typically fewer than 10% are actually named something
meaningful (the rest just being NET0001, NET0002, or whatever the
software uses by default). How about yours?

This is the result of either enforcing a name on every signal
*or* cutting the schematic into too many pieces (I only require
names on signals that go off-page).

I worked on a project for a three letter company many years ago.
The "boards" were mounted on gates (doors?). I would estimate
2,000-3,000 DIPS on a board (plus two or three decoupling caps
per component). Highly repetive design (is that the right way
to say that? seems clumsy). Someone could flip the page in
the "schematic book" while you weren't looking and you would
never know it! Components were all boxes, signals were all
plain vanilla names ("Gee, I thought I was just checking on
NET1234 yet the schematic says NET2042... <shrug>")

You really want the drawing to work *with* you and not
against you (e.g., Sl vs. S1 is not a good idea!)

 

[D Yuniskis]

TR and RV are arguably signs of not being familiar with industry
standards. LED I could imagine someone purposely choosing even though
they're well aware that normally it's just D, i.e., they believe they're
creating an improvement. Whether or not that's really the case is pretty
subjective, although it's pretty hard to argue that someone seeing a
reference designator of LED23 wouldn't understand what kind of component
it is.

Worse yet is using 'D' but failing to use an LED *graphic* to
show that the device emits light!

2k7 is a European thing. As with four-way intersections, historically
there was some decent justification for it (the decimal point easily
getting lost in mechanical reproductions), whereas today it's just a
personal preference, I suppose.

I have mixed feelings about 2K7, etc. If you complain about
dots (disappearing *or* appearing) in 4WS's, then you can
argue that the 2K7 notation reduces the possibility of losing
a '.' in document reproduction. Not a big deal nowadays as
most lettering is done "by machine". But, when it was done
with pointed lead and lettering guide, it would be easy
for "2.7" to look like "27" when reproduced (as the '.' need
not take up as much horizontal space as a digit! i.e., you
won't necessarily see "2.7" appear as "2 7")

 

[D Yuniskis]

Hi Nico,

That depends on your printer. On a shitty printer A4/letter size may
be the maximum for a readable diagram while a good printer will allow
for much more on one page.

I think, nowadays, its relatively easy to get 300 dpi. 600 dpi
will quickly replace that. I never need to turn on 1200 dpi to
get a quality drawing -- even on A size paper.

Inkjet printers are probably *not* a good idea for schematics
as they tend to have larger dot sizes. IMO, inkjet only makes
sense for really low power and/or "color" (neither of which
seem to be necessary -- IMO -- for producing schematics).

I think pen plotters were in the 0.3mm region for line widths
(rapidograph tip). If so, figure ~100 per inch (ignoring ink
bleed). So, every three inches of plotter dimension corresponds
to an inch of 300dpi printer dimension. I.e., an A size sheet
has (roughly?) the same amount of "detail" as a C size sheet on
the plotter. B size print would equate to a D size plot?

I'll have to drag out a plotter and see.

(or, has my mental arithmetic slipped a gear somewhere along
this process?)

 

[D Yuniskis]

Hi Tim,

Having worked on a number of complex boards whose schematics run to a
dozen pages or more, I have developed a great liking for schematic
capture tools that do hierarchical schematics. You do the block diagram,
and then the tool _embodies_ the block diagram.

Yes, even STRIDES was capable of this (1980's?). A shame those
bozos fell on their face with that product! :<

(This, of course, like anything else*, can be misused. But done with a
minimum amount of care and some appropriately gleeful criticism from your
peers, it clarifies things a lot).

* even commas.

You mean, like, *asterisks*! ;-)

 

[krw]

Hi John,



That's how I used to draw things. But, I found it often resulted
in clumsy signal routing -- just to avoid a 4WS.

I'm with you. For hand' drawn schematics maybe 4WS avoidance is a
good thing. CAD does a much better job making things clearer.

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.

That's why OrCrap makes 'em red. ;-)

 

[krw]

IIRC (my copy is at home) an appendix to AoE also makes this
recommendation. Of course, the Appeal to Authority isn't much of an
argument in and of itself.

It does sometimes look more "natural" to connect at crossings (e.g., the
canonical voltage divider, top to bottom, with a signal passing
"through" the junction left to right) but adding a small jog there is a
small price to pay for the avoidance of ambiguity. A "T" always
connects; a crossing never connects. And no humpies.

It's not a small price to pay, IMO. It really constricts flow on
dense schematics.

 

[krw]

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

Well, there aren't too many others that will ever see my schematics.

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).

That's a good idea, but management rarely thinks such things are worth
the effort, particularly on small projects (OTOH, when >200 engineers
are involved in one design things change fast). It would be nice to
be able to tie them together.

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...)

We currently add this information as component properties. A quick
sort of the BOM then gives the appropriate pick-n-place data. Showing
it on the schematic is a more complicated problem.

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 make the symbols small on Ledger. In reality, I use sheets that are
150% of Ledger (11"x17") and then print on Ledger. It seems to be a
good compromise.

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.

If that's the case a block diagram doesn't work cleanly either.
Hierarchical design has so many other benefits. Apparently board
designers don't see the importance because the CAD companies have
blown it so badly.

(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!)

That's easy. My main (VHDL) module is ProjectName_Top.vhd.
Testbenches (the highest level in a hierarchy, actually) are *_TB, so
the top level testbench would be ProjectName_TB.vhd.

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...

Binders keep all the pages together. ;-) I keep the entire project
in one binder. I can look at any component quickly. Well, as long as
someone hasn't borrowed my binder (happens constantly).

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

Took me a few reads but I finally figured out that's what you must
have meant. ;-)

Exactly. Virtual paper is cheap.

It's not virtual, though. We use real printers, too. ;-)

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.

Just highlight the bus breakout. I have no interest in seeing 64 (or
double or triple that) off-page connectors or the wires crossing every
page. This makes me ill just thinking about it.

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.

Seldom does an individual wire of a bus go to a unique place.

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).

When many signals travel in the same general direction I often run two
together and then a space, then three, space, or whatever makes
following them easy (count by inspection).

[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! :>

Just wait. ;-)

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.

You'll get used to it. My bifocals are set for perfect focus on a
keyboard (intended for reading) and screen. I carry them everywhere
because I'm blind now without them. I'm trying to figure out how to
get some for distance because I can't read the dash without them but
can't see distance with them. ;-)

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"

I don't like one component per sheet. I see a lot of that in vendor's
examples. I can't see what's going on at all. I'd do better with a
netlist.

<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! :>

Power supplies are always on globals. No off-page connectors at all.

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

I favor that but often it's better on the left, sometimes both (64 bit
busses). Tristates are the issue, though.

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.

Exactly. Bundling signals that are naturally bundled makes schematics
*easier* to read. That's the whole point.

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.

Ick. One component per page is *ugly*. It doesn't give any
information about how things work.

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!

Be careful that you really do change what is different, too. It's
easy to forget all changes when you cut-n-paste.

No. Too many people are colorblind (7+% of men).

I don't believe in dumbing anything down to the least common
denominator. Color is a useful tool. Use it. This is like saying
that a painter should only use black and white. Nonsense!

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.

Yes, it's still useful, though perhaps less obvious.

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)
Agreed!


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! :> )

LOL! Our schematics *were* all boxes. AND gates, OR gates, DFFs were
all the same sized as resistors, transistors, and capacitors. They
had to be printed on chain printers. Rockets and bullets are a major
move up. ;-) Oh, and full schematics were more like several thousand
C-sized pages (a rack about 2'Wx5'Hx6'L. ;-)

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.

It does. As long as the clocks and active levels are marked, labels
tell pretty much everything you need. At some complexity there isn't
room on the schematic for details anyway.

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.

It's just a matter of were the "just a box" line is drawn.

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).

It does take some thought but clarity often does. I never put both
the positive and negated names on a signal. Well, I do use "RnW" as a
descriptor for Read (not Write) but that's really the signal's name.

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?).

Use the "_n" suffix. This is allowed in every system I know (even
VHDL) and maintains the sort order.

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

NEVER! The signals polarity *must* be noted using some convention.
Not doing so is just asking for disaster.

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.

Disagree. The more information that can be conveyed on the board the
better. Doing the above also gives the layout guy more information.
More information = less chance for screwup. In the same way it
improves the chances that a screw up will be caught before it becomes
a disaster.

You're tying the design to the physical implementation.

In many cases, yes.

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.

External connectors are usually chosen before the design starts. It's
part of the project description. Internal connectors should look
sorta like what they represent to aid in debugging.

<frown> "Color".


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.

Yeah, with more of a description than that. What fields of the
address bus are being decoded and for what purpose?

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.

Yes, but they blow the schematic up by orders of magnitude. Software
doesn't need any help at sucking.

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.

They might stick their tongue on the flag pole, too. Information is a
good thing. It is well known that only the ECO system has the
*correct* information, though.

A paper cutter is your friend!

If you're going to cut a C-Sized page, why not use ten As? It really
is ugly.

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??

Grounds upside down are antennas! Knowing TI's crap, maybe...

 

[krw]

Good point. With a few macros in your favorite text editor this is pretty
easy to "fix," but I can see how that could be more hassle than it's worth.

Yes, then you have to ECO the edit macros. ;-)

Our schematics often have many hundreds of nets (often over a thousand) of
which typically fewer than 10% are actually named something meaningful (the
rest just being NET0001, NET0002, or whatever the software uses by default).
How about yours?

A lot of signals are named. Anything that *may* be referred to
elsewhere is named. Diff pairs, for example, are difficult to tag
unless they're named. Other important signals get named so they can
be picked up easily in layout. Of course anything that gets into the
silkscreen gets named.

Another OrCrap bitch: Signals named on the page are really aliases
for the unreadable netname and are treated differently than other
named signals. Aliases are the only way to name an on-page signal,
though.

 

[krw]

One of the parts of the op-amp show the power pins as does one logic
gate.

I'd prefer the power be on a separate heterogeneous device, but this
is second best. Many of our schematics have it on all op-amps (though
gates get one power/ground per package). I'd prefer to have the power
on a separate heterogeneous symbol so all of the gates can be
interchangeable.

Dots have lead to errors. If the reproduction of the schematic is
less than perfect a mere fly spec can send the technician down a
blind alley.

I think that's more of an issue with hand-drawn schematics. I haven't
seen any problems (other than the damned software gets carried away
with dots) with CAD packages.

[... ground symbols ...]

What do you use for chassis ground?

Pitchfork in the ground.

You mean you don't flaot all your logic on the +5V plane?

No, it hangs from it. ;-)

------
-----! 7805 !--------+--------- Logic Vcc
------
!
+----------------------- Logic grounds
!
/---/ 5.1V
!
+----------------------- HC4051 Vee connections
GND

I really did do this and the technicians didn't even kill me
for it. I avoided adding a switching device to make a minus
supply for the Vee and the minus swings.


Shields are soldered to "mounting holes" and schematically show
as a dashed line running through the hole and around the area.

Our shields mount on solder balls. The balls are shown in the corner
with a billion ground connections. I don't believe the components
under the shield are shown (I agree, they should be).

 

[krw]

My main rule (a preference actually) is that the same name be used in
the callouts when a circuit involves several schematic sheets!

That's often difficult to do. It assumes single instances and no
re-use.

 

[krw]

"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.

There should be a lead designer responsible for all of the interfaces
to the component parts. In large projects we had someone assigned to
"naming conventions", as well. He wrote the naming rules and assigned
global signal names.

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.)

Yes, I generally name things by the "owner" of the interface, usually
the processor. "DSP_Tx" and "DSP_Rx" would show up on the peripheral
component's Rx and Tx lines, respectively. If they were different
devices, then Tx and Rx would swap in the middle of a cable somewhere.

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.

I name them WRT the "owner" of the bus. If the DSP controls the
interface, the FPGA signals get the DSP's signal names.

 

[krw]

I rarely produce paper schematics... everything is distributed via
Acrobat... everything from A to E-size.

You rarely have to sit down in the lab, in front of a scope and debug
the design. ;-)

 

[krw]

Visio does this, but I've never met an actual schematic capture program that
does. I'm not sure I'd want to use such a feature personally, but it would be
a nice option, certainly.

Visio also allows you to leave a break for crossings; much nicer than
speed bumps. Both speed bumps and gaps are programmable.


| |
| |
| |
| |
-------------------------- -------------+---------
| |
| |
| |
|

No connection Connection

 

[krw]

Our shields mount on solder balls. The balls are shown in the corner
with a billion ground connections.

One nice thing Pulsonix lets you do is to "multiply-instance" a component...
you can name, e.g., a mounting hole MH[1:6] and connect it to ground, and on
the layout -- poof! -- you get six grounded mounting holes.

How do you define "MH" and it's connections?

ORCAD of course doesn't do this, having almost zero significant new
development performed in something like a decade now.

Certainly they have. They've developed a *lot* of new crashes.

 

[Tim Williams]

Visio also allows you to leave a break for crossings; much nicer than
speed bumps. Both speed bumps and gaps are programmable.

| |
-------------------------- -------------+---------
| |

I always draw a vertical gap. I think it looks better than a solid cross,
but not as hollow as a horizontal gap, which seems like there's more
missing.

Tim

 

[krw]

I don't mind the 2K7 notation so much as using a 2.7K 5% in a place
where
the design really needed a 1% part. I have seen cases where the
design only
worked because most of the 5% resistors fall inside the 2% range. If
they
all happen to land jelly side down, the circuit fails.

Way back when TR was the ref for a transistor on a lot of schematics.
It wasn't standardized. There was also a symbol that looked like
this:

---
! !
! !
------!>! !-----
! !
! !
---
!
!

That is a PNP transistor

We drew them longer and skinnier,

|
|
+---+
| |
| |
-------| | <=== NPN
| |
|___|
\ /
V
|
|


but more or less the same. Sometimes with two dividers in the middle.
I got to like the symbol for diff-amps, current mirrors, and
multi-emitter TTL circuits.

 

[krw]

[... schematics ...]

I think that's more of an issue with hand-drawn schematics.  I haven't
seen any problems (other than the damned software gets carried away
with dots) with CAD packages.

I often have to support things in remote sites. The schematic is in
the
manual and may be some what degraded.

If your publisher is that bad, find a real professional.