[SignalTap] How to always keep the latest trigger until I stop the acquisition?

[alexislms]

How to always keep the latest trigger until I stop the acquisition?

I need to see the latest trigger that has happened when I stop manually the acquisition.

For example, I have a signal that goes high and low several times, I'd like to capture the last time it transitioned after I hit the stop acquisition button.

Segmented buffers working as a circular buffer would be perfect.

Is there a way to do it?

Regards,

[sstrell]

So is the signal in question part of your trigger condition or are you saying that you have some trigger set up not involving this signal, but you want to see what's happening with this signal without adjusting your trigger condition to make use of it?

If you can't change your trigger condition, I guess the best solution would be to use a storage qualifier.  You could use the transitional qualifier to capture samples whenever this signal transitions.

If you can change your trigger condition, you could simply trigger on this signal transitioning low.  If it had to be after a certain number of times going low, you could use a state-based triggering flow to count how many times it has transitioned low and then trigger at that point.

Maybe a little more detail would help.

[alexislms]

Thank you for your reply. I've checked the SignalTap templates without finding my happiness...

To improve the example:

* Let's say the signal is a valid signal and is the unique trigger condition, I want to capture other data signals when the valid signal goes low for the last time after I hit the stop button.

* The valid signal can be asserted/deasserted a random number of times, unknown.

Unfortunately I don't know how many times it transitions, that's why I really need to always keep the latest trigger occurrence.

I don't really mind to have a fixed trigger condition at compile time, I can set it up to "falling edge" and be good with it.

Something like a dual-buffer with one buffer that always keeps the latest occurrence until I manually stop the acquisition.

If that can help, in other words, instead of keeping the data from the first trigger occurrence, I'd like ST to always keep the most up to date trigger occurrence(s) until I stop the acquisition.

Regards,

[sstrell]

So it sounds like an autorun trigger is your best bet.  Set your trigger condition to catch the falling edge of the signal in question.  If you use autorun instead of standard run (the button to the right of the Run Analysis button), the logic analyzer will repeatedly trigger and capture data until you manually stop it, emptying and refilling the buffer as it runs.

You could also use a segmented buffer.  That way, each buffer segment will fill based on the trigger and the logic analyzer won't stop until you stop it or until all buffer segments are filled.

You have a lot of options for doing what you want.

[alexislms]

The Autorun feature isn't hardware, my signal moves much faster than the refresh time. It doesn't keep the latest trigger occurrence.

"Segmented buffers" isn't a solution, the signal triggers millions of times.

In fact, the Autorun feature in hardware is exactly what I would need.

Regards,

[sstrell]

Not sure what to tell you then.  Can you make your trigger condition more specific?  Maybe I'm not getting what you are going for.  If you want to manually stop at a certain time for a signal that is transitioning that much, there's no way you can do that by clicking the button.  I thought this was a signal toggling rarely, but I guess not.  A more specific trigger that catches a certain sequence of events (multiple trigger condition columns or a state-based trigger) seems to be what you're looking for.

[alexislms]

I first wanted to ask here if it was possible. If not, I'll implement that by myself or try to find an alternative using available templates.

I thought always keeping in hardware the latest trigger occurrence would be something basic and useful for lots of design.

At one point, the signal stops transitioning, that's why I'd like to see exactly that moment, and this moment is statically undefined.

Example flow:

1. Run the acquisition

2. Run my test, run my design and so on

3. My system is stuck at one point, I stop the acquisition.

4. Offload the data so that I can see the last transition that happened.

[sstrell]

With a bench logic analyzer with GB of buffer space, this would be no problem.  You'd be able to look way back in the buffer.

With Signal Tap, you don't have that luxury so you either have to have more specific trigger conditions or use storage qualification to capture in the buffer exactly the samples you want to see, dropping samples you don't care about.

If there's a certain period of time between the last good transition and when you know there's a problem, you could use a counter in a state-based trigger to count that time.

[alexislms]

I've done similar projects to keep the latest packet/data/frame/whatever several times.

What is needed is just a ring buffer and memory, no need of said huge buffer space, just the double of what is currently required.

We can imagine all sorts of solutions.

When a trigger occurs, the data before the occurrence is copied and is overwritten at each new occurrence. The remaining bits are copied if no new trigger occurs during that time.

Memory space still depends on the number of windows, their size and the number of signals to be captured/triggered.

Indeed, in my situation, I can define an arbitrary timeout, but I don't know if the state-based trigger works the way I want.

I'll try to play with it hoping it's a good workaround.

Thank you for your help!

[RichardTanSY_Intel]

I believe sstrell help to answer your inquiries. Do you need further help in regards to this case?

[alexislms · Accepted solution]

I got the solution from the Intel Premier Support.

For reference:

It is possible to always keep the latest trigger occurrence by using segmented buffers and State-based trigger using segment_trigger.

Adding 2 conditions, one REAL condition and one FALSE/DUMMY condition.

The FALSE/DUMMY condition is Advanced and the Result is inputted with a Bit Value set to 0.

The State-based state machine looks like this:

if ( REAL_COND )
	segment_trigger;
else if ( FALSE_COND )
	trigger;

It internally triggers a segment at a time thanks to segment_trigger at the real condition (falling-edge in my case).

And the false/dummy condition never triggers. It does trigger only when I click on the stop button.

This allows me to always keep the latest trigger occurrence and is a solution to my question.

Regards,

[RichardTanSY_Intel]

I’m glad that your question has been addressed. With that, I will now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Best Regards,

Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos and select the best solution.