SignalTapII doesn't trigger anything!!!

Hello,

operating SignalTap in freerun mode, with no trigger condition defined is good to see, if signals give reasonable values. However, if a signal is displayed and has transitions in freerun mode, there's no reason why it shouldn't also work as a trigger.

Could it be, that you have overlooked an additional trigger condition, may be in a group?

Or if you have a trigger condition from several signals, it must not necessarily be ever true.

Regards,

Frank

Hi,

is it possible to post a screenshot of the setup tab of your signaltap ?

Kind regards

Gerd

Hello,

thank you for your answers.

After lots of tests, i've found that it works only with one trigger...

I don't know if it's normal or if it's due to my license.

Actually i don't have time to analyze in depth the problem. I'll try later and keep you inform.

best regards.

Yann.

Hello,

I'm not sure what you mean with "only one trigger"? Quartus Signaltap has multiple trigger levels, in Basic trigger mode, the trigger condition for each level is a logical AND of all active node related condtions. If you select individual conditions, that won't occur in a combination, you get no trigger, as I already mentioned.

SignalTap Operation is documented detailed in Quartus II Handbook.

Regards,

Frank

I've had the same problem with 7.2. The signal tap would trigger on one condition, but not another. Both occurred and you could see both events in the display, but only one would actually trigger the capture. This used to never be a problem, so I must assume that this is a new "feature" that Altera has graciously included. I just loaded SP1, so I'll see if this is fixed in this SP.

The work around seems to be to pick a working trigger or just not use signaltap for that specific condition.

Regards,

Dan

Hello Dan,

I understand, that a certain signal, although it has transitions, doesn't trigger SignalTap at all, with no other trigger conditions in effect? Do you see the issue also with level trigger or only with edge trigger?

Thanks for help,

Frank

Hi Frank,

Yes that is correct. This one signal wouldn't trigger it at all on either level or edge. The signal was very narrow, about 5 ns, but I've had success with this type of signal before. I would guess that it won't repeat, because I've changed the code since then. I know it was triggering, because this particular signal was a write enable for a memory and the memory was filling up, even though signal tap couldn't trigger on it.

Regards,

Dan

Hello Dan,

that sounds plausible to me, although I don't know what's happening in detail. The behaviour most likely depends strongly on your acquisition clock. SignalTap hasn't a glitch detector like e. g. a logic analysator or a digital oscilloscope. It does all signal processing in synchronous logic, being constrained by the same setup and hold requirements as your design under test. Particularly, an edge trigger isn't a FF clocked by the signal, it's a synchronous edge detector. If signal duration is too short related to your acquisition clock, SignalTap could miss it.

I don't know, if there have been changes to trigger logic that may affect behavior with short pulses. It can also be an effect of timing differences from place and route.

As a general rule, I wouldn't expect pulses shorter than a period of sampling clock to trigger SignalTap reliable.

Regards,

Frank

Hello Dan,

I agree with Frank that it could be a problem with the acquisition clock. Maybe you choose a acquisition clock which is asynchronous to your signals ?

Regards,

Gerd

Hi Frank and Gerd,

The signal was slightly over one clock cycle(@150MHz well below fmax), since it was generated by the sampling clock. I've never had any problem with signals like this before. If I triggered on another signal, then the problem signal showed as one clock cycle long. It just couldn't trigger the collection with it.

Regards,

Dan