Schematic preferences

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

d

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.

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

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

Exactly. Virtual paper is cheap.

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

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

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

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.

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!

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

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.

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

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.

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.

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

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.

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.

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

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

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.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

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

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

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

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

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

Thus my layout guy can then zoom in for something he can't quite make out. (The ultimate check is called "LVS", layout-vs-schematic, where netlists I generate are compared to the netlists that the layout program generates.)

I've also kissed off Power Point for presentations. I can do it better in Acrobat with "push/pop" hierarchical schematics, allowing me to zip around during design reviews to exactly what the audience wants to see.

I can print up to 13" x 19" on my wife's HP Officejet Pro K850, but I rarely do. ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
I love to cook with wine.     Sometimes I even put it in the food.

-- snip --

-- snip --

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.

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

--
www.wescottdesign.com

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

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

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

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

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

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

I generally like at least 2 "grids" between junctions. If a schematic gets very dense I tend to make hierarchical "lumps" to keep it readable (*)... I like schematics to be readable enough that it's clear what the circuit does.

(*) Also makes it easier for my layout guy. For instance, for tracking, I may have an array of series and paralleled resistors. I put them into a hierarchical block. On the main schematic you just see a block saying, for example, "VCO_ResistorArray_1". ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
I love to cook with wine.     Sometimes I even put it in the food.

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

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.

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.

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.

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.

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.

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

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

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

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.

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

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

Just wait. ;-)

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

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.

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

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

Exactly. Bundling signals that are naturally bundled makes schematics

*easier* to read. That's the whole point.

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

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

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!

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

Agreed!

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

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.

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

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.

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

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

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.

In many cases, yes.

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.

"leftist targeting the lowest common denominator"

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

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

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.

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

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

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

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.

A possible solution to avoid confusion and blotch botches: All 3 or 4 wire connections shown with de dots, if a wire must cross another but NOT connect, then use a half-circle to graphically show one "goes around" the other. Consistent use of this scheme gives:

1) If a blotch or mistraken dot is seen at a half-circle, then the obvious interpretation is correct and the blotch can be safely removed. 2) If 2 wires cross and there is nodot, then the obvious interpretation is correct and adot can be safely added.

Ain't dot nice?

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.

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.

Pitchfork in the ground.

No, it hangs from it. ;-)

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

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