Copyright 1994, Jack G. Ganssle

Abstract

This is the first of Jack Ganssle's columns in EDN (the main magazine - others appeared in EDN Products earlier). Its general thesis is to never assume any signal is at a particular level. This is not really a TTL world anymore, yet far too many designers get into trouble making assumptions that it is.

Published in EDN in August, 1994.

When Steve Leibson, Editor-in-Chief of EDN, asked me to write a monthly column about embedded system hardware issues I told him I wasn't sure I had enough to say to fill 2000 words a dozen times a year. Besides, this business changes so fast that all of us are constantly on the verge of becoming technological dinosaurs. Still, some basics of engineering never change, so I agreed to try and pound out a few tarnished pearls of wisdom each month.

I've been fortunate in being a part of the microprocessor revolution almost from the start. My first job as a (very) junior engineer was the design of 8008-based systems. In only a couple of decades this industry has mushroomed from tiny embedded systems with .05 MIPs CPUs running 2k programs to today's inexpensive 50 MIPs+ designs with millions of lines of code. It's amazing and breathtaking to see how far we've come in so little time. While the popular press loves to babble on about the information society, focusing on the widespread availability of the cheap PCs that, to a non-engineer, look like computers, I suspect history will show that the true revolution in late 20th century civilization was the introduction of embedded microprocessors in every bit of our lives. If we could hear the hum of embedded processors quietly computing we'd be overwhelmed by a roar of this new paradigm of society.

It's a terrible tragedy that the great mass of humankind have no understanding of how their lives are subtly enhanced by the embedded microprocessor. Instead most fret and fume if the ATM machine takes an extra second to dispense cash (or issue that oh-so-dreaded "insufficient funds" message), yet few understand that the machine is verifying the card, communicating with mainframes at Visa Central, debiting accounts, and electronically adjusting balances at banks all over the country, just to drop some pocket money into one's impatient hands.

This lack of understanding creates a widespread misconception about the nature of the computer industry. 8 bit designers can't get no respect! After all, it's a 32/64 bit RISC/SPARC/DSP high end 100 MIPs world... ain't it?

Well, no, it ain't. High end CPUs account for a minuscule fraction of the entire computer business. The tens of millions of 386 and up processors shipped are practically an insignificant blip compared to the five billion processors sold each year... most of which are 4 or 8 bit machines; virtually all of which are buried inside millions of embedded systems.

Even in technical publications fast and powerful processors get the glory - no doubt a regression to our past loves of fast cars and flashy clothes. Just as Hollywood's favorites garner the majority of attention from the press while we, the less charismatic and maybe less beautiful people, carry on the real work of society, so do little CPUs shoulder most of the computational burden of the world.

Similarly, while we read of vast team design efforts, of the thousands in involved in coding big weapon systems or the latest Lotus masterpiece, I believe that most embedded systems are born of solitary designers and programmers working alone or with just a few colleagues.

And so I believe the press skews our perception of ourselves. Take heart, ye clever inventors changing the world! You are not working on obsolete technology just because your processor is a Z8 or 6805. Your tiny project team is not a throwback to the days of yore. Don't be lulled into thinking you are out of the mainstream!

Daily I talk to dozens of design engineers in all corners of the globe. It seems the happiest, those most content with this profession, are those working on smaller projects, in small groups, where their impact is immediately important. And so, after this long-winded introduction, I make the following disclaimer: since 4, 8 and 16 bit systems are just as important, and a lot more fun, than the minuscule high end of the market, this column will focus mostly on these sorts of systems. Clocks

I see a lot of embedded systems in my travels, and get to take a look under-the-hood at most of these. Many are wonderfully designed; some are not. One persistent problem I see is a total disregard for data sheets.

For a number of years embedded systems lived in a wonderful era of compatibility. Just about all the signals on any logic board were relatively slow and generally TTL compatible. This lulled designers into a feeling of security, until far too many of us started throwing digital ICs together without considering their electrical characteristics. If a one is 2.4 volts and a zero 0.7, if we obey simple fanout rules, and as long as speeds are under 10 Mhz or so this casual design philosophy works pretty well. Unfortunately, today's systems are not so benign.

In fact, few microprocessors have ever exclusively used TTL levels. Surprise! Pull out a data sheet on virtually any microprocessor and look at the electrical specs page - you know, the section without coffee spills or solder stains. Skip over those 300 tattered pages about programming internal peripherals, bypass the pizza-smeared pinout section, and really look at those one or two pristine pages of DC Specifications.

Most CPUs accept TTL-level data and control inputs. Few are happy with TTL on the clock and/or reset inputs. Each chip has different requirements, but in a quick look through the data books I came up with the following:

8086: Minimum Vih on clock: Vcc-0.8 386: Minimum Vih on clock: Vcc-0.8 at 20 Mhz 3.7 volts at 25 and 33 Mhz Z80: Minimum Vih on clock: Vcc-0.6 8051: Minimum Vih on clock and reset: 2.5 volts.

In other words, connect your clock and maybe reset input to a normal TTL driver, and the CPU is out of spec. The really bad news is that these chips are manufactured to behave far better than the specs, so often they'll run fine despite illegal inputs. If only they failed immediately on any violation of specifications! Then, we'd find these elusive problems in the lab, long before shipping 1000 units into the field.

Fully 75% of the systems I see that use a clock oscillator (rather than a crystal) violate the clock minimum high voltage requirement. It's scary to think we're building a civilization around embedded systems that, well, may be largely misdesigned.

If you drive your processor's clock with the output of a gate or flip flop, be sure to use a device with true CMOS voltage levels. 74HCT is a good choice. Don't even consider using 74LS without at least a heavy- duty pull-up resistor.

Those little 14 pin silver cans containing a complete oscillator are a good choice... if you read the data sheet first. Many provide TTL levels only. I'm not trying to be alarmist here, but look in the latest DigiKey catalog - they sell dozens of varieties of CMOS and TTL parts.

Clocks must be clean. Noise will cause all sorts of grief on this most important signal. It's natural to want to use a Thevenin termination to more or less match impedance on a clock routed over a long PCB trace or even off board. Beware! Thevenin terminations (typically a 220 ohm resistor to +5 and a 270 to ground) will convert your carefully-crafted CMOS level to TTL.

Use series damping resistors to reduce the edge rate if noise is a problem. A pull-up might help with impedance matching if the power supply has a low impedance (as it should).

A better solution is to use clock-shaping logic near the processor itself. If the clock is generated a long way away use a CMOS hystersis circuit (like a 74HCT14) to clean it up. The extra logic adds delay, though. If your system requires clock synchronization then use a special low-skew clock driver made for that purpose.

In slower systems -- under 20 Mhz or so -- I prefer to design circuits that don't depend on a synchronous clock. What happens if you change to a second sourced processor with slightly different timing? Keep lots of margin.

Never drive a critical signal like clock off board without buffering it. There are a very few absolutely critical signals in any system that must be noise-free. Examine your design and determine what these are, and take appropriate steps. Clock, of course, is the first that comes to mind. Another is ALE (Address Latch Enable), used on processors with a multiplexed address/data bus. A tiny bit of noise on ALE can cause your address register to latch in the middle a data cycle, driving an incorrect address to the memories.

OK - so now your voltage levels are right. Go back to the data sheet and make sure the clock's timing is in spec.

The 8088 requires a 33% clock duty cycle. Sure, it's a little odd, but this is a fundamental rule of nature to 8088 designers. Other chips have tight duty cycle requirements as well.

Rise and fall times are just as important, though difficult to design for. Some chips have minimum rise/fall time requirements! It's awfully hard to predict the rise/fall time for a track routed all over the board. That's one attraction of microprocessors with a clock- out signal. Provide a decent clock-input to the chip, connect nothing to this line other than the processor, and then drive clock-out all over the board.

Motorola's 68HC16 pulls a really neat trick. You can use a 32768 Hz standard watch crystal to clock the device. An internal PLL multiplies this to 16 Mhz or whatever, and drives a clock output to feed to the rest of the board. This gets around many of the clock problems, and gives a "free" accurate time-of-day clock source. Reset

The processor's reset input is another source of trouble. Like clock, some processors have unusual input voltage requirements for reset. Be wary.

Other chips require synchronous circuits. The old Z280 had a very odd timing spec, clearly spelled out in the documentation, that everyone ignored only to find massive troubles getting the CPU to start. I think every single Z280 design in the world suffered from this particular ill at one time or another.

Sometimes slew rate is an issue. The old RC startup circuit generates a long ramp that some processors cannot tolerate. You might want to feed it into a circuit with hystersis, like a Schmidt Trigger, to clean up the ramp.

The more complex CPUs require a long time after power-up to stabilize their internal logic. Reset cannot be unasserted until this interval goes by. Further complicating this is the ramp-up time of the system power supply, as the CPU will not start it's power-up sequence until the supply is at some predefined level. The 386, for example, requires 2**19 clock cycles if the self-test is initiated before it is ready to run.

Think about it: in a 386 system four events are happening at once. The power supply is coming up. The CPU is starting it's internal power- up sequence. The clock chip is still stabilizing. The reset circuit is getting ready to unassert reset. How do you guarantee that everything happens to spec?

The solution is a long time delay on reset, using a circuit that doesn't start timing out till the power supply is stable. Motorola, Dallas, and others sell wonderful little reset devices that clamp until the supply hits 4.5 volts or so. Use these in conjunction with a long time constant so the processor, power supply, and clocks are all stable before reset is released.

When Intel released the 188XL they subtly changed the timing requirements of reset from that of the 188. Many embedded systems didn't function with this "compatible" part simply because they weren't compliant with the new chip's reset spec. The easy solution is a three-pin reset clamp. The Moral

Always read the data sheets. Don't skip over the electrical specifications with a mighty yawn. Those details make the difference between a reliable production product and a life of chasing mysterious failures.

One of my favorite bumper stickers reads "Question Authority". It's a noble sentiment in almost all phases of life... but not in designing embedded systems. Obey the specifications listed in the chip vendors' datasheets!

If you've read many annual reports from publicly held companies you know that the real meat of their condition is contained in the notes. This is just as true in a chip's data sheet. It seems no one specifies sink and source current for a microprocessor's output, but the specification of the device's Vol and Voh will always reference a note that gives the test condition. This is generally a safe maximum rating.

Despite our apparent digital world, the harsh reality is that every component we use pushes electrons around. Electrical specifications are every bit as important to us as to an analog designer. This field is still electronic engineering filled with all of the tradeoffs associated with building things electronic. Ignore those that would have you believe that designing an embedded system is nothing more than slapping logic blocks together.