Connectors on hierarchical schematics

Flat schematics don't have that problem.

Den tirsdag den 18. november 2014 20.42.45 UTC+1 skrev Tim Wescott:

it is not a strict rule but generally we have all connections to the outside on the top page. So someone hocking it up only needs the first page

Debug connectors and such that doesn't come out of the box might stay one the page where it comes from

-Lasse

They get mighty big, though.

That's a good point. I shall ponder it.

My record for a PCB is about 31 pages.

Our first page is, for non-trivial designs, the block diagram/table of contents.

Where possible option B: Put each connector where it most logically belongs.

I've found it generally results in less missed / mixed up nets during development. It also means not chasing through pages or connector nets when debugging or fault finding.

How you draw the schematic depends on which of its customers you intend to target/favor. As clients tend to redraw any schematics that I create (to meet their own in-house standards/conventions), I draw schematics for myself -- to facilitate drawing them, and troubleshooting it once reified. I'm familiar with the design so I know what to expect, where... and, just need little "assists" to keep me from needlessly flipping pages.

This helps folks who aren't familiar with the design troubleshoot it. It gives them a single place to find their way "in and out".

This is most appropriate for me. I don't end up chasing a signal only to discover it's *just* going to a page of connections. The same sort of thing applies to *real* (physical) connectors. A subsystem that fits on a single page needn't require me to start on a "connections" page, flip to the implementation page, then flip back to the connections page.

I don't (usually) make the schematics, but I have to read them, usually in order to figure out where the inputs and outputs to a processor are.

This is IMHO a pain in the butt, but sometimes unavoidable if you have some really huge connectors that you want to show all together, like a full PCI or VME bus or something like that.

If you have to do this, it helps to write at least the signal/net name on the wire coming from each pin, and give the page number where the other end of that signal/net is.

I find this easiest to follow. If you have a connector that has (for example) both power and signal lines on it, put it where it fits the best - if all the power stuff is on one page and the signals are spread around, put it on the power page, but if all the signals on that connector come from / go to one page, maybe it's better on the signal page. Again, for the wires on that connector that don't go to the page that it's on, have at least the net/signal names, and preferably the page number.

For circuit boards, the thing I find hardest to follow is where a single connector is split up on multiple pages, with no note on where to find the rest of it. Sometimes I want to unplug that connector to probe it, or I don't have whatever piece plugs into it, and I want to know what is going to stop working when unplugged or fail to work if not there. It's hard to figure that out if I have to flip around and look for all the pieces of P3.

One thing that helps for systems with lots of boards is an overview diagram as the first page or two. It has all the major boards, and all the major signal and power connections between boards - maybe not down to the pin numbers, but like with a box labeled "backplane connector" drawn around 30 lines, or a circle labeled "BNC" around one line, or whatever. The board that the rest of the schematic applies to has a "you are here" marker on it.

In perfect world, you have the connector designators from the schematic silkscreened on the board, and all the connectors are different. In the real world, sometimes it's not like that. It can help to put notes like "close to the power supply" or "on the back side, by the display" near the connectors on the schematic.

If your input, output, and power signals mostly each live on their own connectors, you can match the way a lot of schematics are drawn: input connectors on the left, outputs on the right, power on the top.

If you have a connector that you want to draw a lot of attention to, put it at a 45 degree angle on the schematic.

The wiring diagrams in factory shop manuals for cars are a little different, but they have a different problem - lots of devices scattered around a big box, connected by harnesses with lots of wires. A lot of times there isn't an overall diagram, just ones for each subsystem. If all the wires in one connector show up on one subsystem diagram, the connector will be labeled like "P3/J3", but if not, it will say "Part of P3/J3". These diagrams answer the "how do the headlights / door locks / whatever" work.

Then, somewhere later in the electrical chapter, there will be line drawings of *all* the connectors, often looking into the mating end of the unplugged connector, with pin numbers, circuit names, and probably wire colors. This answers the question of "I unplugged this, now where do I stick the meter leads".

Finally: Dig around the net for freely-licensed vector clip art of various critters. Put a little snail on the RS-232 bus and a cheetah on the Gigabit Ethernet lines, stuff like that. Don't overdo it - maybe two or three critters in a 10-page schematic - and be ready to delete them all. The reactions you get will tell you a lot about what kind of place you work for.

Matt Roberds

-----------------------^^^^^^^^^^^^^^^^^^^^^^

I may have misinterpreted Tim's question. I'm assuming the connectors in question are those that connect to the next level in the *hierarchy* and not, necessarily, *physical* connectors.

E.g., design an H-bridge driver and plop 4 or 8 of those on a higher level of the schematic: H-bridge #1, H-bridge #2, etc. (so, the higher level schematic refers to the "H-bridge schematic" AS IF it was a *component*.

I reserve the first page for administrivia; last page for power and decoupling. With a hierarchical design, often the "higher levels" of the design act *as* a "block diagram" thereby addressing two needs -- its role as part of the "signal interconnect" as well as "block diagram"

AND, as it MUST fill both roles (nature of the beast), it ensures that the block diagram is always up-to-date (fail to update it and something won't be connected as it should be -- FOR REAL -- because it is actually part of the netlist!)

E: Have your connectors as multi-part symbols, so that you can put different parts of the same connector on different pages...

More seriously, I usually go for B where possible, but sometimes there will be a mixture. If you have a card with a few major connectors and a number of minor ones (debug port, etc.), then you might those that are of key interest to the user/customer on a page by themselves, and put the minor ones on whatever page is most convenient.

As always, it depends on who the main user will be. Who will be reading the schematics most? If it is you, or other electronics developers, then put the connectors where it is most convenient for /you/. But if it is a service technician who understands connectors but is baffled by microcontrollers and op-amps, then put the relevant connectors he needs on a single page so that he only needs to look at the one page of the schematics.

Thank you Don -- your comment about deciding what customer I want to aim it at and proceeding is a big help.

To date, the bulk of my circuit-design customers take what I give them and don't touch it -- I'm often their entire engineering department for the duration of the project.

Then you have a tougher decision to make -- clearly (?) *you* shouldn't be the intended audience as you will only see them "once". I'd opt, instead, to consider what their techs/support (and customers??) would consider "most useful".

A lot depends on the application domain/market, as well.

E.g., folks in process control industries like to see lots of little, "independent" circuits -- even if they are, in fact, interrelated. It's just more in tune with the way they deal with abstractions ("The speed loop", "the air handling loop", etc.)

And, of course, any regulatory agencies may have a say in it.

I look at hierarchies as components. Do you insist all 8 buffers in an octal buffer be drawn in the same "symbol" -- even if they are being used as 8 individual buffers? What about on the same page? Chances are, you put them where they make the most sense. You probably *don't* have notations on the page that tell you where you can find the other buffers in a particular package found ON THIS PAGE.

Also look at *how* the customer will be viewing the schematic. If they are using a 'free' viewer program they may be able to hop around to find things very easily with an F2 or a ctrl-F to find a compont number or a connector pin. If they're stuck with PDFs (hopefully at least one PDF for all the schematic pages) it might not be as easy to find out where CN134 is connected to. *All* the places it is connected to.

I'm generally of the camp that believes that the external interfaces should exist on the top page, but things like programming interfaces that are not externally accessible don't need to be. I'd hate to have to have a connectors page.

I was speaking of physical connectors, not connections within the schematic.

In any project I am usually putting together quite a complete package of information (System Design, Hardware Design and Software Design). In the documentation scheme I have a page that shows the connectors represented in their position on the physical panel and tags of the signals for each pin with a cross reference of tags into where in the schematics they can find them (tag name and page number is often enough). The connector panel layout(s) are not necessarily drawn with the schematic capture tool. In the schematics I place connectors/pins where they are most related to the functions they support if the drawing packages permits (not all do part connectors easily and where they don't, placing the connector at the edge of the page and referencing the signal to a location on the page is the usual way to go).

Whatever you do choose to do, you should probably write up a documentation standard for yourself so that, if others do work for you, you can demand they follow that and enforce the rules through technical reviews.