3rd Place

Bruce Pride
Gilsum, NH USA

Slic Stepping Debugger

Design Objective:

To design an FPSLIC based embedded system for the Circuit Cellar "Design Logic 2001" contest.

Project Goals:

Design a system that will:

1. be used as an engineering tool to aide in microprocessor embedded system development and verification.
2. utilize the capabilities of the FPSLIC system on a chip.
3. contain modular reusable Verilog HDL modules.
4. contain modular reusable AVR assembly routines.

Resulting Project:

A microprocessor bus cycle translating embedded system based upon the FPSLIC system on chip device.

System Overview:

The Slic Stepping Debugger system is a bench top device that connects up to an external circuit board’s microprocessor bus. It monitors, captures and then converts a single microprocessor bus cycle into useful engineering data. That data is then displayed to the user via the systems integrated LCD (Liquid Crystal Display). The system is used in conjunction with a single stepping software debugger, on a PC, which is connected to the processors debug port. Every time the user steps through code with the software debugger, the Slic Stepping debugger captures the first bus cycle and displays the Address bus value, Data bus value, whether it was a read or write cycle and how big the current transfer size was. This allows the engineer to monitor and verify basic microprocessor bus cycles during development of new hardware and software designs. Of course, there are many families of microprocessors and all have different bus protocols. The first microprocessor protocol and bus that will be interfaced to will be the 32 bit PowerPC 860 family.

System Applications:

When it comes to debugging embedded systems, single step debuggers are one of the best solutions. They provide many useful debugging features at a fairly low cost. The one problem with a debugger is that it's not a true interface to the physical hardware under test, like a processor emulator. The debugger sends commands to the host processors BDM (Background Debug Mode) or JTAG (Joint Test Action Group) port telling the processor what to do. How do you actually know if the code you are stepping through is controlling the processor and it’s bus correctly? How do you know what's really happening on the physical target board’s bus? Of course, you could use a Logic analyzer to see what's going on.. Better yet, you could buy the disassembler for the processor you're working on, so the Logic analyzer could translate all those waveforms into some actual assembly code. This is the best method for verifying an embedded system’s performance and timing, but is a little overkill for the engineer who just wants to peek onto the processor bus and watch some basic system functionality. This would also be expensive (well over $50K for each analyzer system), difficult to use and time consuming to setup for a novice user. So, what kind of low cost, easy to setup (plug a connector into your board and your reading translated bus cycles), basic functionality tool can be used to debug embedded systems? This is what the Slic Stepping Debugger offers to embedded system development. By connecting up the Slic Stepping Debugger to an external processors bus, it can capture single bus cycles, translate and then display them (as hex values etc.) as the user steps through the code via the PC debugging program. This gives the engineer basic processor bus cycle information that can be compared to the actual code being stepped through.

As an example application, A hardware/software design team is revising a machine design to include new features. Minor additions have been made to the original known good hardware platform for this design. The software engineers on the project have been developing code for the modified board design prior to its arrival. The board finally arrives, they start up their debugger, connect up to the processors BDM port and begin stepping through their code. Every time the code tries to write to one of the new memory devices on the board, the system hangs up. After hours of troubleshooting the code, they finally call you up the hardware engineer for assistance. After verifying the basic connections to the memory device, the Logic Analyzer must be hooked up to see what’s really going on with the board. Once the companies one and only Logic Analyzer has been found (but must be returned by the end of the day), all the leads have been connected, all the menus setup and the debugging begins, many precious hours have been lost. The software engineer begins stepping through the code as the hardware engineer watches the signals on the analyzer. Once the debugger tries to write to the new memory device, the bus signals are captured on the analyzer. Immediately the problem is found. The address on the bus does not match that of the memory mapped address range for the device. This of course causes the processor to hang up or flag an exception. The code is changed to match the memory mapped region for the device and the system works perfectly. Since there is only one logic analyzer in the company and only one person on the team who knows how to use it, how can the software engineers easily find errors, like the above memory problem, in a timely manner? Of course!, each software engineer will now have a Slic Stepping Debugger connected up to their board. The Slic Stepping debugger could have easily caught the memory access error mentioned above since it monitors the processors address bus as one of its inputs. This would have saved the design team hours of precious debug and setup time. Now, all the software engineers can view the translated bus cycles as address, data and control information. All this without having to operate highly sophisticated, expensive logic analyzing equipment…

There are of course many other ways the Slic Stepping Debugger system can be used as an effective piece of engineering equipment. Most applications will require custom FPSLIC software to take full advantage of the FPSLIC peripherals/capabilities and the current microprocessor’s protocol that will be monitored. This will be discussed more in the "Future System Applications" section.