Smart Debugging, debugging without preparation

Do you always write your HDL-code properly and simulate it properly before going onto the hardware? I do. Surely. Well, most often I did. Admitted, sometimes I did not exactly and hence afterwards I had to check why things did not work on the board.

What do you do in such a situation? Probably you think of where things may have gone wrong and then you put in some internal logic analyzer or add some probes. So, either you re-implement, add some probes in the implemented design and then re-create a bit-stream. In all cases you spend some time waiting for the tools to finish. And in some cases it may even happen that the error does not appear anymore. That is the worst situation.

Wouldn’t it be nice to completely avoid the reimplementation and manual probing? Yes, it would. My colleagues Rajesh and Apurva have recently created some videos showing how to exactly do that: debugging without altering your design and without having to wait for the tools.

Too good to be true? Not really, this is the feature called SmartDebug in Libero SoC. This tool allows you to connect to your Microchip FPGA via JTAG and read out all Flipflops and all Block-RAMs in your design asynchronously. And all that without having done anything upfront! This is real innovation!

I tried that with a very simple design, the “Hello World” of FPGAs, some blinking LEDs. Actually, a bit more, some LSRAM BlockRAM is also part of the design to also try that.

I have a 24 Bit Counter where the MSBs are toggling two LEDs and bottom bits are driving address-lines and data-lines of an LSRAM. The FCCC is a Clock Conditioning Circuit, a PLL.

The AND-gates are an old, simple and dirty way to keep the LSRAM as part of the design and not have it optimized out. This design I have targeted for a very simple but still versatile board, the SMF2000 from Trenz on which a SmartFusion2 M2S010 is populated.

After a short implementation run I had the bitstream which gets transferred onto the FPGA via the on-board USB to JTAG connection. After that simply start the SmartDebug Feature from the Libero GUI:

On the upcoming GUI select “Debug FPGA Array…”:

With that you get a GUI where to choose either on logic from your design or from the RAMs:

Checking RAM-content

When the intended RAM is selected you can read its content asynchronously and get the appropriate memory-values displayed:

What is going on here? Is this the data that is expected here? The first 32 Entries are 0 and then the entries are “something”. Let’s have a look back at what the memory is connected to:

The bottom five address-bits are connected to the counter and the 8 data-bits are connected to 0. So the initial 32 entries are continuously written with 0. This is correct. What about the other RAM-locations? Well the Igloo2-LSRAMs are not initialized on reset, hence random startup-values are present. So from that perspective that behavior is correct.

After changing the data-lines to an 8 bit counter the exercise is repeated and the LSRAM read out again. The first read works properly, the first 32 entries are populated with incrementing values:

Reading again after a short period of time results in this read-out:

The read-out shows the effects of the asynchronous reads, the first seven addresses have been updated, the following 25 addresses are from the previous write-cycle. What is possible here too is to manually enter data into the LSRAM via this GUI as done on address 0:

In this case the value is overwritten, however in cases where wrong ROM-content causes wrong behavior this is a simple way of fixing something.

Checking Logic

Similar to reading out RAMs the same approach can be applied to flipflops:

All the data here is collected without any preparation of the design, only based on the project-information from Libero and from reading the FPGA array data via JTAG.

Multiple reads here show that the CNT_net is incrementing, however the visible steps are far beyond the single increments as expected by a slow asynchronous read via JTAG. So this reading is a pretty good way to get some general information about the design-behavior or about slow signals. The bottom signal in the screenshot shows the value of a debounce-chain of 4hF, so properly pulled up to ‘1’ on the input.

Also here on the flipflops the output-value can be altered via JTAG.

Realtime Behaviour

With asynchronous reads you are constrained as shown above. However using the LiveProbe feature one can also route out any two flipflop-output from the design to two dedicated FPGA-pins without having to implement probes or recreate the bitstream. So you can see at the original speed of the signal what is happening. For viewing these signals you require a scope and connect them up on your board.

Conclusion

The SmartDebug Feature in Libero SoC is a really powerful means to do initial debugging on a design before starting to put in a virtual logic analyzer and can save a lot of time in the lab by not having to wait for bitstreams being created. From my perspective this feature is so powerful that any user of Microchip FPGAs should really be aware of that.

And yes, designs are still to be simulated properly before going into hardware.?