A software engineer offers tips for checking schematics

Taking time out to review a new hardware design is a smart idea, even if you're a firmware developer. This article shows how you can contribute to the effort and includes tips that could make you the hero who saves an extra board spin.

If you're going to develop software for a new embedded target, it's to your own (and the project's) advantage to get involved with the hardware design as early as possible. Most software engineers don't get involved with the hardware until after the design is nailed down and prototype printed circuit boards have been ordered. This is a mistake.

Volunteering to be on the schematic review team is a smart idea for several reasons. In addition to getting early access to the design documents, which helps you do a better job with the software, you might catch mistakes the hardware team overlooked or find ways the design can be improved to make the software implementation easier. Even if you don't find any flaws, you might learn something useful or reduce your learning curve.

Desk checking

Once you've decided to get involved with the hardware design, the key point to realize is that you're looking for honest mistakes. The hardware's designers have probably been looking at the little details for so long they might be missing something at a higher level of detail. If you can step back and take in the big picture, you've a good chance of catching such errors, even if you couldn't generate such a design yourself.

Once you get a hardcopy of the schematic, grab every color highlighter you can get your hands on. Pick a color for each of the following: address bus, data bus, control bus, and any peripheral-specific I/O signals.

Starting at the processor and working your way out from it, trace these different signals, coloring as you go. This should help reveal the underlying structure of what may at first look like a meaningless spider web.

Verify pinouts

After you've traced the signals coming out of the processor, the next step is to verify all of the pinouts. Get your hands on the manufacturer's datasheets for as many of the major ICs on the schematic as you can. In particular, you'll want the pinouts for the processor, memory chips, and key peripherals. At a minimum, verify that the pin name and numbers are correct, even if you don't check what they're connected to.
You might think the pinouts would never be wrong, but the truth is your board probably has at least one part on it that has never been used at your company before. And, though sometimes IC vendors provide pinout data in a format compatible with the designer's schematic entry package, somebody often has to create a “CAD symbol” for the new IC by hand. As the number of pins on modern processors has increased (Motorola's MPC8260 PowerQUICC II has over 200 pins), so have the chances to make a simple clerical error.

Even if you have to draw out the truth tables by hand, it's worth checking the address decoding carefully. Think about how the processor will initially start to run. Will execution begin at address 0x0000000, FFFF:0000, or at an address specified by a vector at some other fixed address? Make sure that the correct type of memory is decoded at the reset address. For example, you can't boot a Z-80 if there's only RAM at address 0x0000.

It's also worth tracing the I/O port connections carefully. You might think this would be a silly thing to check, but once you have the experience (as I have) of discovering that you can't control your prototype board's LEDs because they're hooked up to an input-only port, you'll agree it's worthy of review.

Many modern CPUs have multi-function I/O pins that can be used as inputs, outputs, or interrupt sources”but never more than one at a time. Watch for pins with special capabilities being used as ordinary inputs or outputs, when other (less capable) pins could be used instead.

The data bus wiring should always be checked as well. On some chips, data bit 0 is the least significant bit, while on others it's the most significant. Check each major IC's datasheet and make sure the ICs are all hooked up correctly. This may mean connecting signals together in ways that look backwards (for example, D0 connected to D7, D1 connected to D6). Errors in this area are especially common when mixing chip families (for example, hooking a little-endian processor to a big-endian peripheral).

Many datasheets include partial (or even full) example schematics showing how to connect the part correctly. Compare such reference designs with the schematic in front of you. If something's different between the two and you aren't sure why, don't be afraid to ask the hardware designer. If you haven't uncovered a flaw in the design, you might at least learn something new about the chip and the uses intended for it in this system.

Of course, you can also check schematic updates against older copies of the design. If you're lucky, enough of the designs will be similar that you can compare them by printing them on transparencies or simply by holding them overlaid up to a light to see what's new. Be sure to pay special attention to any changes that you know are supposed to be in the new draft. You don't want to replace one error with another.

Impossible by design

Software is inherently serial in nature. For instance, it can monitor multiple input ports, but only by polling first one, then the next, and finally the other. Each port will have to be read individually, and only then can the input conditions be acted upon. Check that the hardware design doesn't assume that two or more inputs on different ports can be read simultaneously.

Software is also inherently asynchronous. You can usually control one or more output ports, but you may not be able to align their signals with other clocks on the board. Note that because of interrupt latency, this asynchronous property applies even if you're using an interrupt-driven design. The hardware design should not assume any synchronous behavior.

The intended throughput of a design and the underlying assumptions need to be confirmed carefully. This is particularly true if software is responsible for moving data through the system, rather than a direct memory access controller or other peripheral. If another piece of hardware is moving data around in the system, remember that those could be memory cycles needed by the processor to fetch instructions. Throughput often comes down to a matter of raw speed.

Gotchas past and future

The following is a list of things you should always check, even if you don't have the time or the inclination to follow my other suggestions. These are all real problems I've encountered, some more than once.

The “backwards”'575

A 74×575 bidirectional bus driver is often used in the data bus section of a hardware design. For every bidirectional signal supported by the chip, there's an A pin and a B pin on the '575. Another '575 pin, called DIR, controls whether data flows from A to B or B to A.

The gotcha here is that designers universally assume that the normal mode of the chip would be to pass data from A to B and that you would have to assert the DIR pin to go the other direction. In fact, the opposite is true; you must assert DIR to pass data through a '575 in the direction A to B.

Phantom 8259 interrupts

Intel's 8259 interrupt controller was used in the original IBM PC and is still found in some microcontrollers and multifunction support ICs. The 8259 nominally supports eight interrupt sources, with information about which source caused the interrupt passed to the processor as a numeric interrupt type (0 through 7). But it turns out that IRQ's 0 through 7 are not all created equal.

IRQ7 has the interesting “feature” of also serving as the default interrupt generated when the 8259 isn't sure which interrupt actually occurred. (You laugh but it's true!) An interrupt signal on pins IRQ0 through IRQ6 must have a certain minimum duration for the correct interrupt vector to be invoked. If this minimum duration requirement is not met, then the (befuddled?) chip generates IRQ7 instead.

Since this means you can't really be sure which source triggered an IRQ7, my advice is to avoid connecting a source to IRQ7. It also means you must be sure to install an interrupt handler for IRQ7, even though you might think you won't be getting any of IRQ7s.

Analog control

Analog hardware designers just getting into digital design sometimes have a misguided view of the address and data pins on a processor. Since these pins are outputs (yes, I know the data pins are also inputs at certain points in time), they sometimes confuse engineers into thinking they're under explicit software control and that they can be held in special states (say for addressing a peripheral) while the software does other computations.

Always remember that the processor is going to be continuously fetching instructions and data over the memory bus; these are not “steady state” signals.

In-system programming

With most flash-memory chips, you can't read instructions or data from anywhere in the chip while you're in the process of erasing a sector or writing any location. Software like a bootloader that does flash reprogramming needs to execute from another memory device during the reprogramming. You may have to copy the bootloader into RAM and execute from there. Check that the hardware is compatible with this requirement, if flash downloads may be needed.

Wrapping up

I'm probably omitting a lot of good schematic checking ideas. If you have some good tips (or gotchas) you'd like to add, e-mail them to me, and I'll write a follow-up article.

Kevin Banks has been a software engineer for over 20 years. He holds an AS degree from Walker Junior College (now part of the University of Alabama in Birmingham) and is currently on the engineering team at Teracruz.

0 comments on “A software engineer offers tips for checking schematics

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.