SignalTap Questions

Altera_Forum · ‎04-10-2008

First off, is there a way to filter out the 'empty' entries in my SignalTap buffer. Much of my limited buffer is wasted on these entries. I'd rather only see valid entires captured if possible. Is this possible?

The 2nd thing I am curious about is this: I am getting a bunch of critical errors when I compile with the SignalTap enabled. The critical errors all have to do with using the NiosII SignalTap plugin. Here's what they look like:

Critical Warning: SignalTap II instance "sld_signaltap:auto_signaltap_0" taps the post-fitting node "main_core:main_core|cpu:the_cpu|A_iw[0]" in a partition with a Netlist Type that is not Post-Fit or Post-Fit (Strict)

I get one for every signal included in the Nios plugin. Any ideas? SignalTap seems to function fine with these errors...

Altera_Forum · ‎04-16-2008

I'm guessing you're using a segmented buffer to acquire data.

   TrigCond 1         TrigCond 2
	|                    |
	V                    V
| ---- Segment 1 -----|     |-- Segment 2 ----|   ...    |---Segment n ----|

Empty samples happens because a trigger condition subsequent to the current one occurs before all of the samples in the current have finished capturing. Let me explain further using the above ASCII diagram.

If SignalTap is acquiring data in Segment 1, and TrigCond1 occurs, it immediately starts evaluating for the occurrance of TrigCond2. SignalTap will try to fill Segment 1 with additional Samples, but if TrigCond2 happens before Segment 1 fills completely, it will start filling up Segment 2. SignalTap II does this because if Segment 1 was forced to fill to completion, it may miss Trigcond 2.

One way around this is to adjust the trigger condition for each buffer in your acquisition sequence. If you expect TrigCond2 to appear immediately or soon after TrigCond1, you can make the trigger position for TrigCond1 closer to the end of the buffer. This way, you can more efficiently use up the sample space in Segment1.

I suggest using the State-based trigger flow control to control the trigger position. Start with the example on page 77 of the SignalTap Chapter and the state based trigger flow section (http://www/literature/hb/qts/qts_qii53009.pdf)

As for the critical warnings, you probably used the post-fit filter when you were adding your signals to SignalTap II. Use the Pre-synthesis filter instead. (This is found in the nodefinder window where you search for your signals). Adding post-fit signals allows you to debug your place-and routed netlist. (take a look at the incremental compilation chapter if you want more details...) Since you're not using incremental compile, your entire design re-synthesizes and re-fits every time you hit compile. If the (post-fit) signals that you add get optimized away for whatever reason during a recompile, it'll show as a grounded signal in SignalTap II. Hence, the critical warning. You were lucky in this case that the signals you picked didn't get optimized away - usually registered signals remain through the compilation process; combinational signals may not fare as well.

Altera_Forum · ‎04-17-2008

Thanks for the response!