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: krw on 19 Jan 2010 22:28

On Tue, 19 Jan 2010 17:54:15 -0800 (PST), MooseFET
<kensmith(a)rahul.net> wrote:

>On Jan 19, 8:30�am, John Larkin
><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote:
>> On Tue, 19 Jan 2010 06:20:27 -0800 (PST), MooseFET
>>
>>
>>
>> <kensm...(a)rahul.net> wrote:
>> >On Jan 18, 7:02�pm, John Larkin
>> ><jjlar...(a)highNOTlandTHIStechnologyPART.com> 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.
>>
>> >We haven't done that since the 1980s. �The technicians were the ones
>> >that
>> >suggested the change. �We used to do boards with things like RA12
>> >meaning
>> >column A row 12.
>>
>> We sometimes did that for classic arrays of TTL cans.
>>
>> One division of GE just used a number for the designator; 94 might be
>> a resistor, 95 a capacitor.
>>
>> The opposite extreme is amateurs that make up prefixes... TR for
>> transistor, RV for pot (RV actually designates a Recreational
>> Vehicle), LED for LED even!
>>
>> Most annoying, especially when combined with the dreadful 2K7 notation
>> and the accompanying bad circuits.
>
>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.

From: krw on 19 Jan 2010 22:30

On Tue, 19 Jan 2010 18:15:25 -0800 (PST), MooseFET
<kensmith(a)rahul.net> wrote:

>On Jan 19, 4:50�pm, krw <k...(a)att.bizzzzzzzzzzz> wrote:
>
>[... schematics ...]
>> >> work fine.
>>
>> >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.
>
>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.

From: krw on 19 Jan 2010 22:34

On Tue, 19 Jan 2010 18:12:16 -0700, Jim Thompson
<To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com/Snicker> wrote:

>On Tue, 19 Jan 2010 19:00:26 -0600, krw <krw(a)att.bizzzzzzzzzzz> wrote:
>
>>On Tue, 19 Jan 2010 12:04:48 -0700, Jim Thompson
>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com/Snicker> wrote:
>>
>>>On Tue, 19 Jan 2010 18:53:02 GMT, nico(a)puntnl.niks (Nico Coesel)
>>>wrote:
>>>
>>>>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.
>>>>
>>>>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 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. ;-)
>
>But I have. On complex chips like the first Garmin GPS chip, I sat
>there in Burlington with the IBM test guys correlating test data to
>the test plan, and creating a final probe test procedure.

You're still not probing the circuits so don't need all of the
information contained in the schematic. The logic guys haven't even
used schematics for thirty years. Before VHDL they used flow charts.

>Rare now-a-days, everything always comes up working ;-)

Even when it works we have to prove it. It's not like chips where we
throw it over the wall to the test guys and forget it (until they come
back with failing patterns our simulation didn't catch ;-).

From: D Yuniskis on 20 Jan 2010 00:58

krw wrote:
> On Tue, 19 Jan 2010 11:42:32 -0700, D Yuniskis
> <not.going.to.be(a)seen.com> wrote:
>
>> krw wrote:
>>> On Mon, 18 Jan 2010 13:37:16 -0700, D Yuniskis
>>> <not.going.to.be(a)seen.com> wrote:
>>>
>> 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.

I prepare the documents mostly for myself. I may have to revisit
a design years later. I don't want to have to waste the time
*then* trying to figure out what I did previously. Clients
frown on you billing them for "time to remember what I did" :>

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

The problem is, you (I) want a block diagram that gives
folks a general feel for what is where in the design.
But, hierarchical tools have to account for *everything*.

So, if you have tucked a voltage regulator on a sheet in
"Block A" that is also used in "Block C", the block diagram
wants to show that signal connecting the too. Even though it
isn't significant enough to elevate to the level of
prominence that you would typically embody in a block diagram.

I.e., block diagrams should deliberately hide details.
Yet, this "niggling detail" gains a place of prominence
on a par with major signal flow, etc.

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

Different scale entirely. Imagine hundreds (thousands?) of
files of code. Probably hundreds of lines of code in each.
With descriptive names on the files -- at least in terms of the
guys who named them! :>

CPU comes out of reset. Which file documents the first instruction
that it will execute? (assuming I can figure out which *other*
files it will eventually wander into or through)

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

I try to work off the screen as much as possible. Printed copies
while I am creating the schematic. And, as part of the deliverables.
Most of my time spent with a design is consulting it while writing
software (to make it do its thing). My designs themselves tend to
work "out of the box" (unless a defective part gets stuffed, etc.)
so I don't need to spend much time fretting over the hardware
itself.

I just don't have much desktop space free for paper, binders, etc.
Too much equipment in too little space :> And I'd rather have
the equipment than space for paper! ;-)

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

Using small pages limits the number of signals that can be on a page.
E.g., I just drew a page with an SoC which, by its very nature,
has *lots* of things that will want to head off to other pages
(peripherals, etc.). So, there are ~80 signals that leave the
page bound for "parts unknown" :>

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

Quite common for SoC designs! E.g., this chip has 6 or 8
ports on it. Should I bundle each 8 bit port into a little
"bus"? In which case, I doubt all 8 signals in *any* of
those busses will end up on the same *page* -- let alone
the same *chip*!

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

Too late. :>

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

The only time I end up with a single component per sheet is
for things like SoC's. It's just too hard to get devices
with 100+ pins to *fit* on a small (B) size sheet with much of
anything else (besides a handful of discretes)

>>>> 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.
>
> Exactly. Bundling signals that are naturally bundled makes schematics
> *easier* to read. That's the whole point.

Cramming more onto a single page doesn't make things any easier
for me to read.

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

Who said *one* ROM or *one* RAM? Note they each have s's on
them!

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

Do your drawings *always* get rendered in color? Are they
*published* in color? I.e., if they are ever going to be
rendered in black and white, then any information conveyed
by color is going to disappear.

There are industries in which I work where this is actually
part of their "best practices". Because they acknowledge
that there is a huge portion of the population that has
some sort of color impairment in the vision. Likewise,
restrictions on what frequencies to use in audible
annunciators (e.g., if the "Evacuate the building" signal
is at 20KHz, you're pretty sure most of the elderly employees
aren't going to make it out! :> )

I can either adopt two different standards for work done
in those industries vs. work done elsewhere; or, adopt
a standard that works well in *both* places. (I've never
had a client ask for a *color* version of a schematic
from me :> )

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

Yes, I've worked out of "books" of such schematics. I
wonder if anyone has ever *studied* the practice to be
able to quantify how *unproductive* it is?

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

This ignores a huge class of components! E.g., I was just looking
at a PoE controller. Drawn by the manufacturer as a "box".
With pins on all four sides AS IF it was the actual chip itself!
(i.e., pins were numbered sequentially around the "box").
Told me absolutely nothing about what was going on in the
circuit. And, I'd wager it would be just as hard for the
chip's *designer* to sort out the behavior in that circuit!

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

I worked with a system that restricted names to 8 characters.
(or, maybe it was 6?). So, I have to keep my signal names at
6 (or 4?) characters just so I can add "_n" and still fit
in the 8 (6) allowed? :<

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

How is my choice of name *not* indicating polarity?
RUN indicates that the system is RUNning when it is
HIGH. When the STOP signal is high (RUN_n in your parlance),
then the system is STOPped.

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

I do a design. Later, someone decides how to make it real.

>>>> 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".
>
> <frown> "leftist targeting the lowest common denominator"

I don't see anything "leftist" about it! Rather, I don't want
people screwing up my work.

I had a technician prototype a design of mine some 30 years
ago (when we still used to wirewrap things). I pulled the
wirewrap sockets from stock and set them on his desk in a bag.
Sockets were color coded (Augat, IIRC): red and green for
14 and 16 pin devices (I can't recall the colors for the
other sizes).

I came back an hour later to see how he was doing and found
him patiently *unwrapping* his work. I assumed he had just
made a mistake on *that* wrap and kidded him about it:
"Wrong pin?" He replied "Wrong socket." I assumed he
meant he had wrapped pin X on socket Y and it should have
been pin X on socket Z. No. He couldn't differentiate
red from green and had used the WRONG SOCKET for that device.

I've similarly found problems where technicians got wire
colors wrong in harnesses. This can be really annoying if
you're talking about *big* harnesses!

>>> 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.
>
> Yeah, with more of a description than that. What fields of the
> address bus are being decoded and for what purpose?

That's part of the signal name. ROM_Enable, RAM_Enable, ADC_Enable,
etc.

From: Fred Bartoli on 20 Jan 2010 09:06

Fred Abse a �crit :
> On Mon, 18 Jan 2010 16:05:19 -0800, Jon Kirwan wrote:
>
>> I was trained at Tektronix for drafting electronics, so my
>> preferences come from there.
>
> Do you do cowboys and tombstones?
>

Don't know for the cowboys, but aren't tombstones a production thing :-?

--
Thanks,
Fred.