[Design Application]
Don't Be Afraid Of Debugging Symmetric Multiprocessing Systems
Using Conventional Logic-Analysis Tools And The Pentium Pro Architecture, These Tips Can Help You Tame Your System Problems.
The day when you'll be responsible for designing a system involving symmetric multiprocessing (SMP) may be closer than you think. Clearly, multiprocessor systems are becoming more commonplace. And, having the up-front knowledge about what hooks should be designed into your system, and what it will take to get your design through the debug and verification phase will go a long way toward making your efforts in this new and exciting area a success.
Unquestionably, SMP systems can be intimidating at first glance, with endless complexities and possibilities for failure. Fortunately, traditional debugging tools are still quite useful for multiprocessing systems. If you know how to use them properly, you can track and discover the root causes of most difficult problems.
Understanding the need for debugging your SMP systems before you begin your design can greatly improve effectiveness. If you know which tools you'll need for debugging, and the design hooks into your hardware required to use them effectively, you will be able to predict accurate schedules and budgets, and possibly even cut down on debugging time.
For example, your logic analysis system will need all of the features used in a single processor system, as well as processor-specific probes designed for multiprocessing systems. These probes have new features designed to find problems like transaction tracking, interrupt handling, I/O and memory access difficulties, data corruption, and cache coherency problems. Also, deep acquisition memory and time-correlation between multiple-analysis systems are required for a multiprocessor debugging setup. Advanced methods of displaying and manipulating the information are useful for handling the large amount of data acquired in the process.
Processor-specific run-control tools also have the ability to operate symmetric multiprocessing systems. The SMP run-control tool needs to be able to control how the processors run, stop, and step in a way that will give the most information with the least amount of interference and intrusion. The ability to set breakpoints on each processor using registers is required, and the ability to read or write memory through a specific processor in the system can help solve coherency problems.
Through answering some of the tough questions that come up in debugging SMP systems, this article will concentrate on the shared-memory multiprocessor design most recently used in the Pentium Pro architecture. In this design, all processors share a common bus with other agents, using arbitration to decide who owns the bus at any time. Physical memory and access to I/O is identical for each processor, although each processor has its own first and second-level cache. If the processors didn't have their own caches, the system bus would quickly become overloaded with memory requests. Unfortunately, this means that some information never reaches the bus, requiring caching to be turned off. However, turning off caching can hide some of the problems you are trying to debug (fig. 1).
Setting Up For Debug How do you set up a logic analyzer and run-control system for debugging a multiprocessing system? Only a single logic analyzer and probe are needed for the system bus because it is shared by all the processors in shared-memory SMP systems. This setup is the same as the one used for debugging single-processor systems. But, additional logic analyzers may be needed for probing additional buses for I/O or memory.
The logic analyzer probe attaches at a single processor socket. Because the bus on a symmetric multiprocessing system is shared, most information that you might want to collect from any processor will be available at the logic analyzer probe, no matter where it's physically attached. This simplifies the connection to the system bus and minimizes the additional electrical load. SMP processors will have some signals that aren't shared, so you may need to select a specific processor if you are trying to sample these signals.
Only one run-control system is required, because the processors share a single debug port. A debug port needs to be designed into the target system so the run-control setup can communicate with it. If you can't design in a debug port, you may be able to purchase interposer cards that have debug ports on them. In multiprocessing systems that use JTAG for their debug ports, all the processors and other devices on the board are connected into a single chain that can be accessed through the debug port. It is important that your connections are correct, otherwise damage may result when the processor probe is attached to the system.
The run-control software needs to know which devices (and their order) are on the debug port to interpret the data correctly. This information is known as a "scan chain." In some run- control systems, the scan chain is determined automatically by sending identification queries to all locations on the chain that can contain an agent. If you allow the run-control unit to "autodetect" a scan chain, make sure you know that the operation is safe. Some devices may not be built to the correct specifications of the scan chain, and could be damaged by the commands used while autodetecting. Make sure that you know all of the devices on your board, then your run-control system can detect those devices without damaging them. On most modern Intel-designed boards, the only devices on the scan chain are the processors, which are safe to autodetect. Again, if you did not design the board, and you aren't certain, contact the board's designer or manufacturer, and ask them what your scan chain is.
Reprints
