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).
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
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
GBL# should be driven
appropriately, instead of being pulled up, and transaction codes should be
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
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.
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.
- Learn more about "Troubleshooting, debugging, and getting help" for your PowerPC 750FX/GX systems in Part 2 of this series (developerWorks, October 2004).
- This article series is based on the 750FX-GX Design/Debug Tips application note from the IBM Technology Group Library.
- You'll find much of the documentation referenced in this article -- including the PowerPC 750FX Microprocessor User's Manual, the IBM PowerPC 750GX RISC Microprocessor User's Manual, datasheets, the PowerPC Architecture Book, specifications and reference designs, errata, FAQs, and more -- at the PowerPC Technical Library as well.
- The PowerPC 750FX Power Supply Layout and Bypassing application note describes design considerations for power and ground connectivity, and bypass capacitor selection and placement, for the IBM PowerPC 750FX and 750GX microprocessors.
- Learn more about factors affecting power dissipation from the 750FX and 750GX Power Dissipation Presentation.
- Find timeless tips for prototyping from the University of Nebraska's Electrical Engineering department.
- The PowerPC 750FX Evaluation Kit and PowerPC 750GX Evaluation Kit support benchmarking, reference design, prototyping, and software development. They include all the hardware, software, and documentation required to provide decision support for your design process.
- Your can troubleshoot PowerPC processors with IBM's RISCWatch JTAG-based debugger or with certain third-party JTAG-based debuggers.
- Find links to PowerPC training, documentation, pricing, and tech support at the PowerPC processors Technical support page.
- Have experience you'd be willing to share with Power Architecture zone readers? Article submissions on all aspects of Power Architecture technology from authors inside and outside IBM are welcomed. Check out the Power Architecture author FAQ to learn more.
- Have a question or comment on this story, or on Power Architecture technology in general? Post it in the Power Architecture technical forum or send in a letter to the editors.
- Get a subscription to the Power Architecture Community Newsletter when you Join the Power Architecture community.
- All things Power are chronicled in the developerWorks Power Architecture editors' blog, which is just one of many developerWorks blogs.
- Find more articles and resources on Power Architecture technology and all things related in the developerWorks Power Architecture technology content area.
- Download a IBM PowerPC 405 Evaluation Kit to demo a SoC in a simulated environment, or just to explore the fully licensed version of Power Architecture technology.