Finding Data

Finding Data

Another weekend of weeding. Dark Star – Ceanothus – A California Lilac in the picture. (Not a weed). But enough with weeding. What are some debug techniques that I can use in everyday life? In this installment of using Visualizer Debug Environment – “Finding Data” will offer useful debug and visualizations for everyday debug.

Shorter time weeding this weekend than last time (Weeding Verilog & VHDL), but “deeper”. The aggressive weeds. The hard-to-get weeds.

This week we have the same thing for debug. Deeper investigation into how data is moving around. How data is not moving around.

We’ll do a little debug and check for certain behaviors.

Searching for State Transitions

There’s a state machine, and we want to find the place where the state machine goes from S1->S2->S3. We want to find those three state transitions in a row. Using biometric search those transitions can be colored, and searched for (Next, Previous).

With the state variables in the wave window, the biometric search will color the S1->S2->S3 sequence. (We actually have 6 state machines). Biometric search also supports finding the next or previous occurrence of that sequence (by pressing Next or Prev). In the wave window below, the RED cursor is at the start of the S1->S2->S3 sequence on top.i6.state.

Finding data in packets moving through storage levels

In another part of the design, there are packets transitioning in priority order through levels of storage. The packet ordering coming out of the buffers is suspicious, so some debug is in order.

Using biometric search, the packets can be visualized moving through the buffers according to priority.

The top.clk is close to the top of the waveform. It is followed by the ID value for each packet. The data is flowing from packet0 to packet1, to packet2, to packet3. The data “enters” as packet0, and exits as packet3.

But notice that packet0 ID 4e with priority 1 went in first, followed later by packet0 ID 41 with priority 1. The problem is that packet3 ID 41 came out first, before the ID 4e packet, which went in first. A couple of markers help us think about the ordering. For a given priority, the ordering is not first-come-first-served. Sounds like a bug waiting to happen.

Finding data in a memory

Checking a small memory for certain values.

Just checking the memory in the wave window. The 16 elements can be seen at once in the wave, along with the address and data as they are being written.

The RED boxes in the wave window below highlight the two value columns – one for the RED cursor (C1) and one for the BLUE cursor (C2). The cursors are easy to set with the left and right mouse button respectively.

Cursor1 shows the address of 4 and data of 3, and the left-most RED circle shows the memory location 4 is updated to 3. Cursor2 shows the address of 6, data of 1 and the right-most RED circle shows the memory location 6 is updated to 1.

A simple but powerful memory window can also be used to see the values in the memory at the current cursor1 time.

The memory viewer can move forwards and backwards in time to the next time or previous time that some element was written. Using a memory watch, certain locations can be used as the next and previous triggers – going forward or backward in time to the time when those certain highlighted locations changed. Really a handy way to focus in on a few memory locations that are being changed in error.

End

I’m at the end of the story. All is good. All data is found. The weeds have weakened.

We covered a lot of ground. I’d hate to do that much weeding.

I hope you have enjoyed the search using biometric search with sequences of transitions and the buffered, prioritized packets, with a potential bug, and the memory debug.

Until next time. Enjoy your garden and your debugging.