From the stacks: PowerPC 750FX/GX design and debug tips, Part 1

System design

Soak up some of the wisdom that the IBM PowerPC Applications Engineering team has accumulated from dozens of years of designing, troubleshooting, and debugging PowerPC systems. In the first of a two-part series, IBM Senior Engineer Dale Elson presents tips and best practices for designing applications for PowerPC 750FX/GX processors -- but you can extrapolate much of his advice to other systems as well.


Dale Elson, Senior Engineer, IBM PowerPC Applications Engineering

Dale Elson is an IBM senior engineer and the lead applications engineer for the PowerPC 750 family. He has been helping customers design and debug PowerPC systems since the 601 was designed and has written many of the PowerPC books, manuals, and documents that are available in the IBM Technical Library.

06 October 2004

This article is the first of a two-part series offering design teams some insights from the years of experience, design reviews, and issues completed by the IBM PowerPC® Applications Engineering team. It covers best practices for system design, presenting common topics and comments gleaned from issues, design reviews, and "hallway chats." Part 2 continues and concludes this series with detailed troubleshooting and debugging techniques for PowerPC systems.

Every team has its own way of designing, debugging, and troubleshooting boards or systems. This article isn't intended either to teach basic techniques, or to dictate particular techniques to experienced teams. Also, PowerPC systems are diverse in nature and application, so some of this discussion might not apply to a particular system.

Read the available literature

PowerPC systems are complex; however, you can achieve successful design by a careful reading of the support documents. First, read the user's manual and datasheet for the processor and bridge, then check out The PowerPC Architecture, the FAQ, and the application notes (see Resources).

More about PowerPC 750FX and 750GX processors

The IBM PowerPC 750FX microprocessor was introduced in October 2001. Operating at speeds of up to 900MHz, the 750FX processor is manufactured in IBM's advanced 0.13 micron process. The chip is the first to include copper interconnects, silicon-on-insulator (SOI) transistors, and low-k dielectric insulation technologies, allowing it to deliver significant performance gains over previous 7xx processors while reducing power consumption. It enjoys long walks on the beach and powering Apple Macintosh iBooks (where it's known as the G3).

The IBM PowerPC 750GX microprocessor is architecturally based on the PowerPC 750FX processor and implements several enhancements that specifically address the performance requirements of embedded applications. Some of the PowerPC 750GX's favorite applications include networking, communications, storage, imaging, computing, and consumer applications.

Get the facts

Study the PowerPC FAQ, and follow the recommendations. Most of these frequently asked questions are actually frequently encountered problems that you can avoid by following the recommendations in the FAQ.

Study the IBM PowerPC application notes

Application notes were written in response to the most substantive issues concerning these products. A good understanding of the topics discussed in the notes will help you design and debug your PowerPC board in fewer calendar weeks, with fewer weekends spent in the lab.

Consider that the mere existence of a particular application note is a large hint that there are important things to understand in that area. For example, the existence of the application note "PowerPC 750FX Power Supply Layout and Bypassing" indicates that there are serious and nontrivial issues involved in this area.

Understand the errata

Errata are an important consideration for any device more complicated than a spoon, especially very complex devices such as processors and bridges, and devices that include emerging technology or applications.

Get connectivity information

Check the user's manual and the datasheet for specific connectivity information for each processor. Note that the connectivity recommendations change somewhat from processor to processor, so be careful when upgrading.

Prepare for upgrades

When upgrading from one processor to another, read the "Differences" document for the new processor. You should compare the datasheets and user's manuals for the two processors. Also consult the errata for the two processors.

Consider reference designs

Reference designs incorporate the answers to many questions that designers ask. When deviating from the reference-design implementation, verify that there's a valid reason for the deviation, and that the variation will work.

IBM reference designs are intended to illustrate the use of the IBM processor, and that was the main area of the designers' attention. IBM reference designs are not intended to be a guide to the application of other devices on the board. For example, in an IBM reference design that features a third-party memory controller, the connectivity of the controller to the memory is not covered by IBM. Contact third-party vendors for information concerning their products.

Refine your design: Dos and don'ts

Put robust debug facilities on the board

The wise designer puts robust debug facilities on the board. First, it's extremely difficult to debug a PowerPC system without logic analyser access to the 60x bus, the L2 bus (if any), and the memory subsystem bus.

It is also virtually impossible to debug a PowerPC system without access to the processor via RISCWatch (or some other JTAG-based debugger). There are two kinds of PowerPC designs; those that have the RISCWatch port/connector included in the layout of the board, and those that have the RISCWatch connector attached to the board with hot glue and yellow wires.

Occasionally, a problem doesn't emerge until the system has been in production for a while. These problems are not easy to isolate or you would catch them earlier. Soldering a couple of hundred tiny wires onto the back of a circuit board isn't usually what the team has in mind for the weekend, so we highly recommend that the pad patterns for clean connectors, which minimize the impedance bump, be put onto the board during prototype physical design and also included on the production version of the board.

Buy a socket for the CPU

Having a socket for the CPU greatly reduces uncertainty during debug, when it's unclear if the chip is dead or if the problem is something else. Swap the chip and find out. Of course the socket seriously degrades performance, so a board with a soldered-down processor will probably be the primary debug vehicle. But if the time comes when a socket is desired, you'll want it in a hurry.

Do the electrical modeling

If the bus speed approaches 200MHz, or has multiple drops, or excess length, or is in any other way electrically challenging, simulate the CPU bus using the most advanced electrical modeling technology available to your team.

Don't assume what the processor will do next

It's tempting to make assumptions about what the processor will do next. This is usually a bad idea. For example, following the assertion of ARTRY# by the processor, you can logically assume that the next transaction from the processor will be a castout of the memory from the location that it retried. But that is not always the case. Occasionally, another castout will still be pending, and the first one will go out first, before the one that was just retried. Also occasionally, the processor will retry a transaction not because it had a snoop hit on a Modified block, but because the tags were busy, and the processor was thus unable to snoop the transaction. In this case, the next transaction from the processor will have nothing to do with the retried transaction.

Don't error-check the bus protocol

Checking bus parity is a wonderful idea, and even periodic memory-scrubbing expeditions are useful in some applications, but occasionally a system will monitor the bus protocol and halt the system if something that seems inappropriate occurs (see the section, Don't assume what the processor will do next, for example). This seems like a fine idea for high-reliability systems, but it usually leads to a great deal of trouble. Teams that are considering this should contact IBM for discussion.

Supply the most information, and monitor as little as possible

Related to the previous topic, a good paradigm for bus logic design is to supply as much information to the system and processor as possible. For example, asserting GBL# should be driven appropriately, instead of being pulled up, and transaction codes should be fully encoded.

You should also rely on as little information as possible. For instance, it's more useful in some systems to ignore ABB# as an input, and to reconstruct ABB# in the logic using TS# and AACK#.

Manage power-supply issues

Verify that power and bypassing conform to IBM recommendations

Be sure that the power-supply quality and the bypassing are as specified in the datasheets of the individual devices, and in application notes such as PowerPC 750FX Power Supply Layout and Bypassing and PowerPC 750FX and 750GX Power Dissipation (see Resources). Power supply and ground impedances have a profound effect on the signal quality of the system and can make or break applications. Likewise, robust bypassing is particularly critical in many applications. Many simultaneous switching faults can be overcome with excellent ground planes and bypassing.

Choose local power-supply regulation

Many times a local DC-DC converter, 3-pin regulator, or similar device generates the lower voltage core supplies from the IO bus supply. This is usually a good choice for fast response and low impedance to high-frequency load transients. Be sure that all power supplies are very clean.

Comply with power-supply envelopes

Be sure to comply with the power-supply envelopes shown as notes to the Absolute Maximum Ratings Table in the datasheet. Failure to do so can cause electrical damage to the processor. Many analog step-down regulators do a good job of maintaining these envelopes. You can often solve problems in this area using zener diodes to clamp the supplies, but specifying a power-supply solution is beyond the scope of this note.

Limit current

All electrical devices have the potential to draw excess current because of electrical or physical damage. Be sure that the power supplies include some mechanism for limiting the current to the PowerPC system in case of excess current draw.

Be aware of minimum heatsink requirements

All PowerPC 750FX and 750GX processors must have heatsinks. The heatsink requirements are discussed in the datasheets. The topics covered in the application note PowerPC 750FX and 750GX Power Dissipation are extremely important for correct system design.

Address potential clocking problems

Minimize clock skew

Clock skew (like jitter), subtracts from the timing budget. The processor timings shown in the datasheets include a total of 150ps allowance for clock skew and jitter, but any additional errors must be subtracted from the system timing budget. Calculate clock line lengths to minimize skew. Choose clock buffers carefully.

Reduce clock noise

Likewise, noise on clock lines is Very Bad. Shield the clock lines, and make them point-to-point, with one driver and one receiver, unless the electrical simulation indicates otherwise. Series terminators are often useful on the clock lines, because they are simple, effective, and cheap, and each line can be tuned to the circuit board, to improve signal quality and reduce skew.

Determine acceptable clock jitter

Spread spectrum clocking (SSC) technology allows systems to operate in such a way that they generate less electromagnetic interference (EMI) at a given frequency, which reduces the required amount of EMI suppression that has to be done, which reduces the cost of the system. Unfortunately, it also makes timing problems for the designers.

How much jitter can the processor tolerate and still operate properly? That question has two answers: cycle-to-cycle jitter (short-term jitter) is defined as the max change in cycle time from any given cycle to the next cycle. For the 750 family, the cycle-to-cycle jitter is limited to +/- 150ps. Jitter in excess of that amount can interfere with correct operation.

The second answer concerns long-term jitter, which is most usefully thought of (when talking about SSC technology) in terms of the amplitude and frequency of the signal that is modulating the center frequency of the clock.

Modulation frequencies and amplitudes below certain levels are acceptable to the processor, but they affect system timing by skewing the internal phase-locked-loops (PLLs) with respect to SYSCLK. These errors in system timing must be subtracted from the timing budget. Check the datasheet for the particular processor for a discussion of the acceptable modulation amplitude and frequency for that processor.


With these tips and guidelines under your belt, you can take a confident running start at your first (or next) PowerPC 750FX or 750GX system design. But -- news flash -- all still might not go exactly as planned. Help for those pesky unexpected outcomes is on the way in Part 2, where you'll find debugging and troubleshooting tips and best practices.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into developerWorks

Zone=Multicore acceleration
ArticleTitle=From the stacks: PowerPC 750FX/GX design and debug tips, Part 1