I once heard a fascinating answer to the question of where to place sidewalks on campus after building a new building: Wait a year first. After a year of using the new building, the students and faculty will have created paths to and from your new building. These dirt paths then tell you where to build your official sidewalks.

This has been my experience with the compressed wishbone scope I built years ago.

The compressed scope wasn’t my first bus scope. The first scope was more of a traditional scope that captured every sample based upon a trigger. It’s designed to be a slave on a wishbone bus, and so it fits nicely as a component of a design.

With just a touch of logic, it wasn’t very hard to add a run-length compression feature to the front end of the traditional scope. Although this worked okay, it didn’t handle the trigger properly. I ignored this problem, and used the compressed scope anyway.

I used it to debug a GPS interface, looking for where the PPS signal took place with respect to the UART NMEA stream.

I used it to debug a wishbone bus, so I could skip the idle times or even times when the slave I was debugging wasn’t selected.

More recently, I used it to debug the I2C portion of an HDMI interface.

In all of these, the compressed scope proved its worth particularly for slow interfaces where the scope would allow longer snapshots than could fit in block memory. Indeed, I’m not sure I could have debugged these interfaces without a compressed scope. But, now that I’ve done so, I’ve learned enough to go back and add in some necessary features.

  • The scope needs to have a known trigger point. Given the output stream, and the holdoff you configured the scope with, you should be able to know exactly where the trigger will be in that output stream.

  • If nothing is changing, the scope should have a maximum run length, so that it doesn’t lock up and give you no information.

  • The last piece of memory within the scope’s buffer must be a data point, even if it was part of a run. It cannot be left as part of a run. This is a necessary part of knowing exactly where, within the buffer, the trigger took place.

  • As with the regular scope, the compressed scope should have the option for working off of both a data clock and a bus clock.

  • Timing is important. Working at high speed is valuable. The debugger (i.e. scope) must be able to keep up with your logic when your logic is at high speed. This means that all debug/scope logic should be broken up into pieces small enough to run at the highest speed necessary.

Hence, I just laid my metaphorical sidewalks, and rebuilt the compressed scope according to my needs–now that I knew what they were.

If you have a wishbone bus within your design, then feel free to try it out and let me know how (or if) it works for you.

If you don’t have a wishbone bus within your design, then stick around and we’ll discuss how to build one.