Trying to solve a mystery, but after several days ran out of thoughts :( Needed to connect to SignalTap around 100 (probably, a bit less) signals, and at some moment got very strange picture (attached): First (upper) signal – directly from PLL, 14.318 MHz frequency Second signal – inversion of first signal SignalTap clock – second output of the same PLL, 210MHz The behavior of the circuit tells me that the signals are absolutely fine (nothing would work if the picture is true). After removing most of signals to SignalTap (basically, keeping only the mentioned two signals), suddenly everything is OK – no more strange glitches on the picture. FPGA – Cyclone IV, using DE2-115 board Any thoughts would be greatly appreciated ! :)

The purpose of signaltap is to sample a signal on the provided signaltap clock.you should sample signal on same clock that you are planning in the design otherwise clock ratio and timing gives weird results.

I think I have quite a good idea how does SignalTap work :) The question is - why does it behave in this way under these specific conditions ??? The sampling frequency is much higher than the signal being tested, so it should work fine. Of course, there is another thing added to the mystery - why the picture suddenly looks OK after other signals (not related to the signals in question) were removed ? It should have some clear logical explanation, not just general words about synchronous design etc...

I agree that the signal tap picture isn't well understandable at first sight. I presume that the acquired signal are clean PLL outputs, without glitches. The only way to get the high or low level corrupted outside the actual level transitions is that the 210 MHz signal tap logic doesn't achieve correct timing closure. This can happen under circumstances for a wrongly constrained design that tries to fix timing violation in one place and newly generates others instead. What I usually do with signal tap designs is to specify false paths for signals into the signal tap logic (or equivalent clock groups for the signal tap clock) that can't achieve timing closure by nature, if not already achieved by general design constraints. This way I avoid useless timing optimizations and allow timing analysis to focus on the actual critical paths.

Should also verify that the 210 MHz PLL is stable locked.

--- Quote Start --- This can happen under circumstances for a wrongly constrained design that tries to fix timing violation in one place and newly generates others instead --- Quote End --- Actually, I don't have any constrains at this part of the project... It's the biggest problem for me - everything looks VERY straightforward, so I ran out of ideas at the moment :( But I will check if the PLL locked (even if I THINK it's not a reason) - thanks for the suggestion ! - update - as expected, the PLL is reliably locked...

Weird SignalTap behaviour | Altera Community

15 Replies

Altera_Forum
Honored Contributor
8 years ago
I observe the same bogus glitch even with stable signals so I don't buy the metastability theory:

https://www.alteraforum.com/forum/attachment.php?attachmentid=13830

shreg[19] is known to be stable left of the cursor.
Altera_Forum
Honored Contributor
8 years ago
The previous discussion was about unconstraint and possibly too fast Signaltap clock rather than metastability. I explicitly mentioned that metastability won't cause fake signal transitions for stable signals.

Not knowing any details about your design, it's impossible to relate it to the present discussion.

I rarely see unexpected behavior of Signaltap. Few cases I remember are failure of trigger or storage qualifier logic with signals asynchronous to the Signaltap clock. I don't remember a case where a known stable signal showed fake transitions, except for situations where the acquired signal couldn't be correctly transferred due to JTAG signal quality issues. In the latter case, I got different recording each time the signal was retransmitted by pressing "read data".
Altera_Forum
Honored Contributor
8 years ago
Metastability was mentioned as one possible cause.

It is related to the present discussion because it precisely matches OPs behavior.

I think you are on to something on the data transmission from JTAG as I have observed that the glitches occur in different signals at the same time - so JTAG signal integrity had occurred to me as well. I will try "read data" at my next opportunity.

Thanks, SysTom

--- Quote Start ---
The previous discussion was about unconstraint and possibly too fast Signaltap clock rather than metastability. I explicitly mentioned that metastability won't cause fake signal transitions for stable signals.

Not knowing any details about your design, it's impossible to relate it to the present discussion.

I rarely see unexpected behavior of Signaltap. Few cases I remember are failure of trigger or storage qualifier logic with signals asynchronous to the Signaltap clock. I don't remember a case where a known stable signal showed fake transitions, except for situations where the acquired signal couldn't be correctly transferred due to JTAG signal quality issues. In the latter case, I got different recording each time the signal was retransmitted by pressing "read data".
--- Quote End ---
Altera_Forum
Honored Contributor
8 years ago
I tried the reread operation - did not help.

I'm doubtful JTAG transmission is an unlikely culprit as this only occurs on some builds and when it does happen it fails repeatedly.

I have noticed that it fails when I push the capture clock frequency. I still don't suspect metastability because the source signal is stable.

However, when I relax the clock with a lower frequency the problem goes away.
Altera_Forum
Honored Contributor
8 years ago
You didn't yet tell if the SignalTap clock is constrained in TimeQuest and free of timing violation reports.

--- Quote Start ---
However, when I relax the clock with a lower frequency the problem goes away.
--- Quote End ---

What's the frequency range you are talking about? FPGA series?

Forum Discussion

Weird SignalTap behaviour

15 Replies

Recent Discussions

Tensor block usage

When you double click on a word, the other instances do not highlight due to the Find Box being open

jtagserver.exe causing BSOD together with ftdi driver

Automatically added negative node for TDS output doesn't work with Agilex 5

Agilex3 - unknown IDCODE