Project maintainers


Name: wbscope
Created: Jun 21, 2015
Updated: Apr 7, 2018
SVN Updated: Mar 18, 2019
SVN: Browse
Latest version: download (might take a bit to start...)
Statistics: View
Bugs: 0 reported / 0 solved
Star4you like it: star it!

Other project properties

Category:Testing / Verification
Development status:Stable
Additional info:Design done, FPGA proven, Specification done
WishBone compliant: Yes
WishBone version: B.4
License: GPL


This is a wishbone accessible scope or logic analyzer. Connect this scope internally to your favorite 32-bits of information from internal to your chip. You can also place into the scope a clock enable line, to control "when" those 32-bits of information will be relevant. Thereafter, on every enabled clock, the scope will record a sample of those 32-bits to it's local memory. Next, connect a trigger to the scope, just some event that must take place before the data you have placed into the scope is meaningful for you. The last piece of configuration is the holdoff--once the trigger line goes high for at least one data clock, the scope will continue recording for holdoff samples/counts before stopping. Once the scope stops recording, it'll issue an interrupt pulse to any interrupt controller you might have in your design and you can then read all of the bits back out and see what was happening internal to your FPGA.

The entire approach depends upon the existence of a working 32-bit bus and 2 addresses on that bus (one for control, one for data), but after that the core can be exceptionally useful in figuring out what is going on.

I've used this core to debug PS/2 interactions, Q/SPI flash interactions, Xilinx internal configuration access port interactions, as well as wishbone bus problems. For the PS/2, I set the core up to trigger on the beginning of a PS/2 command and set the holdoff to almost the full length of the buffer. From here, I discovered that I really misunderstood how PS/2 works. (Oops) For another problem, I was struggling with the wishbone bus locking up. By using a separate bus driver, and controlling which driver (serial port or compressed serial port) controlled the bus through a manual user switch, I could recover the wishbone bus. I then set the scope to trigger off the bus locking up and the holdoff to zero. When the trigger then went off, I could see 2k words of debugging info (the length is configurable) from before the "event" to see what lead up to it.

Yes, I understand there are proprietary solutions to these problems--many using the JTAG port. This is not that. This is just a simple, pure, Verilog core for debugging and testing. It has been invaluable to me, here it is shared for others to use.