Forum Discussion
Contributor[SignalTap] How to always keep the latest trigger until I stop the acquisition?
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,
Super ContributorNot 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.
ContributorI 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!
