Whatever happened to the good old days when a schematic conveyed useful information about the circuit it represented? As individual components grow to a size that takes up an entire schematic sheet, modern-day schematics are becoming nothing more than inefficiently formatted wiring lists. For many years, top-down design (TDD) techniques have been both well accepted and an essential part of digital-IC design flows. With minor adaptations, board designers can benefit from these techniques in the same ways as their IC counterparts.
Hierarchical schematics: Originally, schematics were a graphical way for a design engineer to efficiently understand, capture, and record the flow and functionality of a circuit. Graphical schematics thus evolved as the de facto standard—as opposed to a wiring list or any other potential technique, proving again that a picture is worth a thousand words. Unfortunately, those days are long gone. Graphical schematics are still around, as they're usually the only format that pc-board layout systems will accept. But the human-usable aspects have disappeared. Traditional graphical schematics are no longer an effective way to convey information to other engineers during a design review, to the service group for test development and board repair, or to the future engineer who will develop the next generation of the product.
Why is this so? Due to today's huge component pin-counts, designers using traditional graphical schematic techniques are fortunate if they can fit a single component on each sheet. With such low density of information, the schematics are void of any graphical intercomponent connectivity.
Instead, all connec-tivity occurs through intersheet connections by net name, which could originate from almost anywhere on one sheet, and connect to almost anywhere on another sheet (or sheets). Cross-references help somewhat, but the overall flow of the circuit is still completely ob-scured.
With all of the confusion and head-ache that accompanies traditional flat schematics, one might as well write up a text netlist. Although equally unreadable, it would at least consume much less paper. In fact, some companies even go so far as to write their own schematic generators, which use a text netlist to generate a schematic. This schematic step becomes almost superfluous, except that it's the only input format that their pc-board layout system will recognize.
Hierarchical schematics incorporate a graphical approach to schematic design, ultimately reducing the number of sheets and making the schematic more readable. This is accomplished through the use of:
- Buses and superbuses between components,
- Bus pins on components,
- Alias tables,
- Hierarchical connectivity,
- Symbol block-diagram graphics.
Buses, superbuses, bus pins, and alias tables: Busing similar signals together can greatly reduce schematic clutter. But, buses don't need to be restricted to the traditional address or data bus. They can include control and any other associated signals. These buses can then be combined with other buses that may have a common destination. Bus labels should be kept as short as possible by using indexes. If the label becomes unwieldy, it can be substituted with an alias, which can then be explained in an automatically generated legend, in an unused corner of the schematic.
Rather than expand the bus at its connection to a symbol instance, designers can tie the bus directly to the symbol via a bus pin. When designing a hierarchical symbol, it's advisable to make the pin label the same as the bus that will connect to it. This will accomplish two objectives. It will make the design much more understandable by maintaining consistent net names throughout the hierarchy. Plus, it will maximize usable graphics space inside the body of the symbol by allowing the redundant pin labels to be made invisible.
But when using multiple instances of the same hierarchical symbol, it usually isn't possible to keep the buses and labels exactly the same. In this case, there's no choice other than to make the pin labels visible. Still, it's advisable to keep the net names consistent throughout the hierarchy when possible, and closely related if that isn't possible.
Likewise, the bus-pin label on a board-level component symbol should be visible because it's most likely used in multiple instances. Furthermore, the bus-pin label should be visible so it can be matched up with the component pin number (to facilitate manual probing of the pins during debug and repair). Once again, use indexes to keep both the pin number and label strings to a minimum length to avoid using up valuable schematic and symbol space.
But in cases where it's impossible to keep the pin number or label strings short, they can be moved to a separate, automatically generated table. Here, the pin number string on the bus pin will be made invisible, and an alias will replace the bus-pin label. This information will then be moved to a separate pin number/label table, which can be sorted by pin number, label, or both. The tables may appear either in an unused corner of the schematic, or on a second sheet.
Reprints
