Forum Discussion

JohnDuq's avatar
JohnDuq
Icon for New Contributor rankNew Contributor
5 years ago
Solved

signaltap state trigger false positive

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:

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

with the following logic:

with the conditions defined as follows:

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?

  • JohnDuq's avatar
    JohnDuq
    5 years ago

    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.

6 Replies

  • JohnDuq's avatar
    JohnDuq
    Icon for New Contributor rankNew Contributor
    5 years ago

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

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    5 years ago

    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's avatar
      JohnDuq
      Icon for New Contributor rankNew Contributor
      5 years ago

      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's avatar
        sstrell
        Icon for Super Contributor rankSuper Contributor
        5 years ago

        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."