Z80 Breakpoint Generator

Z80 breakpoint generator wire wrap board (front)

Breakpoint generator for a Z80 around 1981.


Z80 breakpoint generator wire wrap board (back)

The wire wrap side of the breakpoint generator


Z80 single step panel

Assembled breakpoint generator and single step unit. The processor has struck the address match at (hex) 007C with the status LEDs on the right showing control state signals.


Future Work

So why would we document this in 2011? If you take a look at debug units in microprocessors and the patent minefield that surrounds the blatantly obvious, then you need some prior art. We developed a few ideas with FPGA for profiling, code coverage and measuring worst case execution time through various paths in code. This was done over the past ten years, but when we looked at various trace units and debug units, we found several of the ideas we took for granted in the early 1980s were now covered by patents. The new debug testbed will be on another website once this “historical archive” has been completed.

For a hint, consider using less of the address bus for capturing a wider breakpoint, BlockRAM for binning, fast adders for counting matches before triggering, complex triggering, and tracing from a user settable breakpoint. A mapping of the available memory would allow trapping on any adventures into the weeds off the allowable path. This is very important for safety critical testing and knowing with code coverage, that the processor never strayed into the weeds once, or via a trace, how it could recover. A permanent circular buffer of processor activity would allow a trace of interest to include some activity before the diving into the weeds, so at least you know where you came from and can look at that part of the code. With procedure level trace, the travel history would also be available when running a real-time kernel, multi-core or on top of multi-threaded hardware.

We had worked on 8085 and 6809 8-bit microprocessor at university in third and fourth year in 1978/9. The state of the art was nothing compared to some forty years later (the 4004 was announced in November, 1971). When I was in second year one of the final year students hand assembled a 79 line program and then programmed an EPROM with pushbuttons and hex address/ data switches. This was to read voltages on a microelectronics project using the Intel 8080 multi-voltage part. That had me hooked. At least a few years later EPROM, PALs and GALs programmers were a lot simpler and attached to a personal computer.

We had moved some way past 79 line hand assembled programs, and initial work was done by translating Pascal to assembler and then writing in assembler. The linking was flat files, but that soon moved up to cross-compiling in C. However, before anything could be tested in software, you needed running hardware. Once the hardware was up, there was no way of looking at a chip to see what it was thinking. We would develop a breakpoint unit and a single step unit. These were basically wait state generators that waited until a button was pressed. The breakpoint was simply an address match using octal comparators. These functions are now built into hardware as the address on the pins (if there is external memory) is not the address of the instruction being executed on modern cache based processors. The 8-bit and early 16-bit processors were not pipelined, so a simple address match and halting the processor was good enough. The data bus displayed the instruction at the address, and a linker output would be used to see what was being executed.

By guessing where the problem was, you put a breakpoint nearby and then stepped towards the problem after the breakpoint. The binary slice of half way back or halfway forward soon narrowed down the area where the processor took off into the weeds.


Z80 breakpoint displayed

Breakpoint at address (hex) 0059 with FF on the databus. Not sure all these years later, but most likely a read from a databus pulled high.


The breakpoint generator was designed to read the target with a test clip over a processor in the target. This allowed the target to be single stepped with the address and data displayed on the hex displays. The switches were for toggling control signals if enabled for static tests, or for matching comparators to trigger an oscilloscope or breakpoint circuit.

Z80 with test clip and extender cards

Furure Work continued...

The making of test clips, ribbon cable attached PCB sockets to simplify connecting up a logic analyzer (so that when a collegue can borrow it without squabbles due to the tedious removal and reconnection of clips), or other methods to improve debug visibility now move from wire wrapping to netlist assignment in FPGA schematics for test cores that can be configured without recompiling the whole design. This is essentially a multiplexor, but read the list of patents carefully before boasting about these “features” in your own designs. We also thought they were generic, as well as how to get the trace data out of the core, or to use serial instead of parallel connections, or to compress the trace, etc. See Trace and Profile Survey (PDF) 684 kBytes for more details.