Top-Down Design Methods Bring Back The Useful Schematic Diagram

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.

Hierarchical connectivity and symbol graphics: Hierarchical connectivity is similar to a C-software-language sub-routine call, where all information passed to and from the function is in the argument to the function call. Unfortunately, the flat interpage connectivity of today's schematics is much more like a BASIC program, where all information is global throughout the main program and its subroutines. But, the same reasons that C is usually favored over BASIC are the same reasons that make hierarchical schematic techniques superior to traditional flat techniques:

All connectivity is centralized. There are no sneak paths that could go unnoticed during a design review.
The interconnectivity is easy to find. If a connection goes off the page, it can only end up on its overlying instance.
It promotes a logical and methodical approach to the design problem.

This doesn't mean that global connections can never be used. Their usage, however, should be limited to a single sheet and to signals that are truly global on that sheet, such as a clock line.

To promote maximum readability, the graphics in each symbol should describe the functionality of its underlying schematic or component. This way, a schematic containing a number of such symbols will automatically become a useful block diagram of that hierarchy level. Therefore, each level of the hierarchy becomes an easily understood level of abstraction of the design. It also assures that the block diagram will always be up to date, rather than a post-project paperwork task that's often neglected by engineers anxious to get on to their next project.

Top-down design: A methodical approach to product development, TDD assures that a design is correct by design, instead of partially correct and requiring subsequent cleanup in multiple board spins and lengthy bench time. TDD also enables the detection of system-level design flaws much earlier in the design process, where they're easier and less expensive to correct.

The top-down method is a natural way to approach a complex design task, mainly because it recognizes the fact that a human being can only deal with a limited number of independent concepts at a time. TDD relies on multiple levels of abstraction to limit the number of independent concepts at each level of the design.

For instance, an architect usually won't approach a housebuilding project by considering the care and feeding of the trees that will form the lumber for the house. Rather, the architect deals with the design of walls, roofs, and fixtures. The carpenter, who is the next level down, handles the actual construction by using wood and nails. At the level below, the lumber supplier provides the wood needed by sawing and drying. Finally, at the lowest level, the forester deals with tree species, sunlight, and water. Thanks to abstraction, the detail at each tier of the hierarchy is limited to a manageable level.

For electronic systems, TDD works in much the same way. The design is broken down into as many levels of abstraction as necessary to keep the amount of detail at each level manageable. In addition, modern EDA tools provide the ability to model and simulate the design at every level. So, each level of the design can be verified against the next one to guarantee that the design is proceeding toward a successful outcome.

Figure 1 shows a flowchart for TDD. Starting at the top of the flow, the design is divided into blocks, which are modeled, interconnected, and then used to simulate this level of the design. This cycle continues until the design has been broken down into its most fundamental building blocks for the particular type of design.

In this example, the fundamental blocks are board-level components and field-programmable gate arrays (FPGAs). Note that after the first iteration, the upper-level requirements of each step should be well-characterized by the model that was created for that upper-level block. Thus, the underlying block diagram can be verified against its upper-level block by side-by-side simulation, and then by comparing the results.

Simulation provides many advantages over other verification techniques, such as building a prototype and performing bench verification. These include the ability to:

Perform system-level investigations that would be impossible to prototype;
View the internal states of components that are impossible to see on the actual prototype;
Probe nets in software, rather than trying to attach to a pin of a fine-pitch part;
Probe hidden ball-grid-array pins;
Create automated test benches.

Be aware that TDD isn't appropriate for all situations. This methodology assumes that as the requirements for each level of the design unfolds, they will be achievable. Any risk should be retired in a separate research project before the TDD development project begins. For such a research project, bottom-up design may be much more appropriate. Bottom-up design ad-dresses the question: "What does the technology allow?" while TDD addresses the question: "What is the best way to proceed from a set of requirements to a finished product?"

Hierarchical top-down design—a real-world application: When the fundamentals of hierarchical schematics are combined with the fundamentals of top-down design, a third "combination" design technique is created, dubbed hierarchical top-down design (HTDD). The real-world application example described here shows how HTDD uses graphical symbols and detailed verification to create an image processor—from the system level, through block diagrams, and down to the FPGA level.

The example uses an image-processor design generated by Camtronics Medical Systems. This system is designed to capture, process, and store cardiac images during a cardiac catheterization or angioplasty (to examine and correct blockages in the cardiac arteries). To illustrate the HTDD technique, the example follows one branch of this design from the system level, down through the temporal-filter pc board, into its motion-sensing spatial-filter circuitry, and finally down to the spatial-filter FPGA.

In brief, the temporal filter enhances images by combining pixels from one or more previous frames to create a low-pass-filtered version of the image. This process reduces the effects of quantum noise and improves the quality of the stationary portions of the image. However, it can cause nonstationary portions of the image to blur. The spatial filter combines adjacent pixels in a single frame to effectively high-pass-filter the image and thereby sharpen its edges to provide more definition for the motion-sensing circuitry.

True to the TDD flowchart of Figure 1, the design is broken into a manageable number of blocks and is verified. The cycle then repeats with each block until reaching the component or FPGA level. In this case, the highest level is the system-requirement document. From that, a system-level block diagram was created and verified (Fig. 2).

System verification is often performed with a mathematical-type simulator or with custom C programs, as in this case. Hardware description languages (HDLs), though, along with their latest analog extensions, are beginning to enter the system space. Performing the system-level verification with HDLs lets a consistent language and set of tools be used throughout the design. It also makes it much easier to integrate the system-level models into the lower-level test benches.

Continuing on with TDD, the temporal filter can be described in blocks using the DesignView tools (Fig. 3) from Mentor Graphics. This tool suite provides a hierarchical design environment supporting a mix of schematic and HDL representations for design entry and verification. The suite's data management allows users to quickly configure design hierarchy to support top-down, bottom-up, and middle-out design and verification methodologies.

In the example, observe the use of hierarchical-schematic techniques to maintain the readability of the schematic. Similar nets are gathered into buses, which are combined into a superbus. Notice also that each graphical symbol on the sheet is a miniature block diagram of the functionality of its underlying hierarchy.

At this stage of the application example, a math-based software package provides verification of the design. Interestingly, in the actual application, the verification stage unearthed several detailed algorithmic problems, which were fed back to the system architects for resolution. Had these problems remained undiscovered until the prototype stage or the production stage, they would have been much more expensive to solve.

The next TDD step follows the design into the spatial-filter block. But before descending into this block, let's zoom into its instantiation on this level (Fig. 4). Now there's a clearer picture of the symbol graphics and more hierarchical techniques in use. These include arrows to indicate the direction of data flow, and cross-reference page numbers in the symbol to help the reader navigate when using paper plots.

Descending into the spatial-filter instance reveals the spatial-filter schematic. Again, true to TDD, this schematic is built of a manageable number of blocks. For the first time, though, some primitive blocks for this pc-board design are visible. Zooming into the top of this schematic sheet reveals the first of the board-level components (Fig. 5).

Notice the use of additional hierarchical design techniques for board-level components, which include bus pins, along with condensed pin numbers and labels. In this case, many of the pin numbers are sequential, so they can be described in a compact form. If the numbers were less compact, the labels and pin numbers could be replaced by aliases and represented in detail in an automatically generated table near the symbol, or on a second sheet. In the actual application, the line buffers and other board-level components were modeled in VHDL, but verification at this level was deferred until the completion of the FPGA design.

Descending further into the spatial- filter FPGA reveals an assembly of synthesizeable blocks provided by the FPGA vendor (Fig. 6). These blocks include simulation models that allow the FPGA to be simulated either alone or in a system using Mentor's ModelSim digital simulator. Having reached a primitive for a pc-board design, the design of this branch is now complete.

Identical TDD techniques were employed on all other branches of the design, until the entire design was complete. At this point, all components were completely modeled, allowing simulation at any level, including a complete board-level simulation.

The finished pc board consisted of 14 custom FPGAs, four hardware multipliers, 18 line memories, 10 static RAMs, and miscellaneous buffers and glue logic. Al-though the modeling and simulation delayed the layout and fabrication by several weeks, many months were saved in the post-fabrication bench testing. In fact, using HTDD and board-level simulation, the entire temporal-filter board was fully tested, in all its dozens of modes of operation, within two weeks of its first fabrication.

The authors would like to thank Camtronics Medical Systems (www.camtronics.com) based in Hartland, Wis., for providing information on the image processor described in this article.

Gary Pratt is a technical marketing manager for the analog/mixed-signal product group of Mentor Graphics Corp. (www.mentor.com), headquartered in Wilsonville, Ore. He holds a BSEE from the University of Wisconsin, Madison. Pratt has practiced as a licensed professional engineer for 18 years, and he has been an enthusiastic proponent of EDA tools since 1982. He can be contacted by phone at (262) 369-5394, or via e-mail at [email protected].

Jay Jarrett is a product marketing manager for Mentor's systems design division. Since 1986, he has worked in the EDA industry in various technical and management roles focusing on design entry, digital simulation, and system integration. Prior to 1986, Jarrett was the lead engineer for ASIC development at a leading telecom manufacturer and a systems integrator for a major defense contractor. His e-mail address is [email protected].