Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
14953 Discussions

signaltap state trigger false positive

JohnDuq
Novice
277 Views

I have an issue were an internal memory block is reporting data that is shifted by 8 bytes.  I'm trying to set up a SignalTap trigger to catch the discrepancy.  The trigger is activating when it shouldn't so I'm wondering if this trigger is too complicated, or if anyone can suggest a better way to capture it.

Here's my normal data, with the 3dcccccdh data (LD) at address 4034h (LA) in the first memory block (shown), or at a second memory block at address 6834h: 

JohnDuq_0-1606955132675.png

I want to catch when this data doesn't show at this (or the following address).  I set up a simple state machine trigger: 

JohnDuq_1-1606955265464.png

with the following logic: 

JohnDuq_2-1606955293569.png

with the conditions defined as follows: 

JohnDuq_3-1606955325965.png

In my mind that says - trigger when you see the data 3dcccccdh at an address is not 4034h and not 4038h and not 6834h and not 6838h.  If the data shows up at any other address it should trigger. 

I can eliminate the extra parenthesis without having to recompile, so it appears to be following the TCL operator priorities. 

The gotcha is that it is still triggering at 4034h as shown above. 

 

Is there a way around this false positive trigger? A different triger method, maybe? 

 

0 Kudos
1 Solution
JohnDuq
Novice
244 Views

I dropped this back to a simpler filter and got it to work 

Condition 1 : data = 3dcccccdh

Condition 2: address = 403xh

Condition 4: address = 683xh

Trigger on Condition1 && !Condition 2 && !Condition3=4

This won't catch a 4 byte data shift but it will catch an 8 byte or larger shift.  That works for now. 

Thanks for all your help. 

View solution in original post

6 Replies
JohnDuq
Novice
276 Views

This is in Quartus Prime 20.1.0 Lite Edition if it matters. 

sstrell
Honored Contributor III
266 Views

You're looking for a repeating trigger condition, so I think a much easier way to do this would be either with storage qualification or using a segmented buffer.  And you don't need to use a state-based trigger.

With a segmented buffer, you can simply set a single trigger condition to look for the appropriate LD value.  Every time that value is seen, it will trigger and fill a segment of the buffer.  You set the size of the overall buffer and the number of segments to divide it into evenly sized segments in the Signal Configuration section on the right side of the .stp file window.  I don't know how many times you are expecting (or not expecting) to see that LD value, but if all the segments don't get filled, just stop the logic analyzer to see the segments that were filled.

Or you could use the conditional storage qualifier.  Again, set a single trigger condition for the desired LD value and set the storage qualification option to Conditional.  This will add an extra column in the Node list.  Set the condition to be the same LD value.  Now the logic analyzer will trigger when it first sees the LD value, capturing any samples with that value, and then it will continue to capture only future samples with the appropriate LD value.

The segmented buffer might be the better option because based on the trigger position, it will capture samples before and after the trigger whereas the storage qualifier will only capture samples with the matching LD value.  You could try playing around with a Start/Stop storage qualifier to try to capture samples around the matching LD value.

As to why you're getting the false positive with the state-based trigger you have, I'm not sure.  It looks correct to me.

JohnDuq
Novice
262 Views

Thanks for the response.   Under normal operation I'm getting a trigger every 1 ms, and I have to collect data for many hours before the error occurs, and it sometimes occurs for a few seconds, then recovers for a few seconds, then occurs again...  It seems like with your technique i would need a 2nd level of filter to throw out the normal triggers or stop collecting after I get a trigger on an abnormal address.  That especially doesn't help because currently i can only capture 512 cycles of my SignalTap clock; I could maybe break that down to about 32 segments of 16-cycles each. 

You may have pointed me in the right direction though.  I had set my 'storage qualifier' to state-based, but missed that there was a 'Trigger flow control' down below that was still set to 'continuous'.  I changed that to 'State-based'.  Unfortunately now when I compile I get these cryptic error messages: 

Error (272006): Invalid Signal Tap custom flow control description was specified.
Error (287078): Assertion error: Valid clear box generator not found or Errors encountered during clear box generation
Error (12154): Can't elaborate inferred hierarchy "sld_signaltap:auto_signaltap_0|sld_signaltap_impl:sld_signaltap_body|sld_signaltap_implb:sld_signaltap_body|sld_ela_control:ela_control|sld_ela_trigger_flow_sel:\generated:ela_trigger_flow_mgr_entity"
Error: Quartus Prime Analysis & Synthesis was unsuccessful. 3 errors, 27 warnings
Error: Peak virtual memory: 4912 megabytes
Error: Processing ended: Wed Dec 02 23:44:23 2020
Error: Elapsed time: 00:00:15
Error: Total CPU time (on all processors): 00:00:22
Error (293001): Quartus Prime Full Compilation was unsuccessful. 5 errors, 27 warnings

Any clue where I go from here? 

sstrell
Honored Contributor III
255 Views

No, that's the beauty of the segmented buffer.  Just let it sit and every time the trigger occurs, one segment fills, even if it's hours between the trigger events happening.  You could certainly add a second trigger condition for further filtering if necessary.

As you found, state-based can be set for the trigger flow itself and for storage qualification, which I've always found weird because with a state-based trigger, you can selectively choose exactly which samples you want to capture.  In any case, I don't know if that's what's causing the error, but if you want to use the state-based trigger, set the storage qualification to Continuous and the trigger flow to state-based.  You can also use a segmented buffer with the state-based trigger by using the segment_trigger command in the "code" instead of just "trigger."

JohnDuq
Novice
251 Views

Thanks.  it looks like when I had 'Storage Qualifier' set to 'state-based' and Trigger set to 'state-based' it caused the errors causing SignalTap to not be instantiated.  At least I can compile again. 

Now back to debugging this flaky trigger... 

JohnDuq
Novice
245 Views

I dropped this back to a simpler filter and got it to work 

Condition 1 : data = 3dcccccdh

Condition 2: address = 403xh

Condition 4: address = 683xh

Trigger on Condition1 && !Condition 2 && !Condition3=4

This won't catch a 4 byte data shift but it will catch an 8 byte or larger shift.  That works for now. 

Thanks for all your help. 

View solution in original post

Reply