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: Nico Coesel on 20 Jan 2010 13:32

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

I always print diagrams. First to place the PCB secondly to probe the
prototype. I always draw components like their actual footprint. That
makes it much easier to find the proper pin.

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

From: krw on 20 Jan 2010 18:59

On Tue, 19 Jan 2010 22:58:52 -0700, D Yuniskis
<not.going.to.be(a)seen.com> wrote:

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

It still takes time. Management usually has other things to do with
my time. ;-)

>>>>> 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? It's not rocket-surgery. OrCrap comes close but botches the net
names completely. VHDL/Verilog is all hierarchical and it seems to
work pretty well. Even the graphics tools drill into the hierarchy
fine.

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

Power supplies are globals.

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

Not buying it.

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

Ever see a processor design? It is *exactly* the same thing.

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

Which file documents the instruction that gets executed in a VHDL
design? ;-)

Just name the main file ProjectName_Main.c or Project_Start.c. It is
*exactly* the same thing.

>>> 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 use both paper and the screen together. Each has its strengths. I
have to support manufacturing, too.

>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 just lost about half my desk space. We moved downstairs to bigger
digs so we have more wasted space and less office space. Well, the
other engineer and the lead firmware guy ended up with a huge offices.
I'm not "supposed" to use my office as a lab anymore. :-(
>
>>> 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" :>

Double ick. I'd throw that schematic away without reading. :-)

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

Yes!

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

If they're individual GPIOs leave them separate because they are. If
it's a bus, draw it as a bus, because it is. It's not a difficult
concept to draw things as they're used.

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

I don't generally put 100 pins on a device. FPGAs and processors get
homogeneous symbols spread where they make sense. The address/data
bus may end up on the memory page. Power on the decoupling page
(often with more than one large component).

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

It's not necessarily more. It's simpler.

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

I don't think we have a board with more than one RAM or Flash. In
particular, memory should be crammed together with busses. These
sheets rarely have problems that need troubleshooting. When they do
it's easier to have everything on one sheet; the whole bloomin' bus.

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

They never get "published", but no, I often print segments in B&W. All
the information is still there, just not as obvious without color
queues.

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

Silly analogy. This stuff is *not* safety critical, nor is any
critical information lost without color.

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

Our "client" isn't about to get *any* schematics. ;-)

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

It was the only way a large system could be managed. Laser printers
soon replaced the chain printers but they were still character based.
Of course everyone else was still hand drafting stuff when we were
auto-routing. As a lifeline to Intel, they got the system (and had
put a usable front end on it so their engineers would use it ;).

>>> 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 didn't say one had to be stupid. Some here are advocating that too.

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

That was certainly dumb. Even 35 years ago we had 32 characters for
signal names, before the hierarchy.

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

Seven lines up:
"So, I will often label signals ignoring any "negated" convention."

>RUN indicates that the system is RUNning when it is
>HIGH.

That is a positive active signal, so has no "_n".

>When the STOP signal is high (RUN_n in your parlance),
>then the system is STOPped.

Again, a positive signal. That's exactly how you match signal name
polarity with component "dot" polarity and DeMorgan correct symbols.
You *are* using proper polarity conventions; they're all positive
active.

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

I do it the other way around. I want control over the product, as
much as possible. I'll often move connectors around so they make more
sense and I want my schematics to resemble reality.

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

It *is* targeting the lowest common denominator. Dumbing everything
down because some are dumb, i.e. typical leftist.

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

Sounds like Augat. Loved their stuff.
>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.

He couldn't count either? I was assigned a dumb technician once too.
It was the last time he worked for me.

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

So they got rid of all color codes? The green wire in your world
isn't ground? Get real.

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

Sure, but I still draw a table with the decode table so it's clear
which address range activates each enable.

From: krw on 20 Jan 2010 18:59

On Wed, 20 Jan 2010 08:33:59 -0800, "Joel Koltner"
<zapwireDASHgroups(a)yahoo.com> wrote:

>"krw" <krw(a)att.bizzzzzzzzzzz> wrote in message
>news:6vmcl55sa9plfqagp853v4knidqmc2tavh(a)4ax.com...
>> How do you define "MH" and it's connections?
>
>It's just a regular part that has one connection on it that -- on the
>schematic -- you connect to a ground symbol. All Pulsonix is doing is taking
>your part, replicating it six times, and connecting them all in parallel.
>
>Besides mounting holes, the common use for this is bypass caps... for the ones
>I want sprinkled around the board, I hook up a capacitor to +3.3V and ground
>(or whatever) and name the part C[1:20] -- poof!, 20 bypass caps.
>
>It's a small little feature, but I do prefer C[1:20] to 20 bypass caps all in
>a big string taking up mondo page real estate.

Ooooh, I don't like parts that aren't drawn.

From: krw on 20 Jan 2010 19:02

On Wed, 20 Jan 2010 08:44:35 -0800, "Joel Koltner"
<zapwireDASHgroups(a)yahoo.com> wrote:

>"krw" <krw(a)att.bizzzzzzzzzzz> wrote in message
>news:57ucl592esdgnir0r2afttvfu58e86nu3n(a)4ax.com...
>> 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.
>
>(cough) Um, I knew a number of digital designers back in the '90s who used
>Xilinx's schematic capture tools to define their logic. Even in the '00s
>people still were, although by then I think there was a sense that you were a
>bit of a fossil if you hadn't switched over to VHDL, Verilog, or similar.

In the '70s they used schematics. In the '80s, flow charts (VHDL
wasn't ready for prime time, though some used it), and late '90s and
'00s VHDL. I moved from schematics to VHDL in '98 or '99.

From: krw on 20 Jan 2010 19:03

On Wed, 20 Jan 2010 18:32:24 GMT, nico(a)puntnl.niks (Nico Coesel)
wrote:

>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. ;-)
>
>I always print diagrams. First to place the PCB secondly to probe the
>prototype. I always draw components like their actual footprint. That
>makes it much easier to find the proper pin.

Ick! You must have small schematics.