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
9 years ago
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.
Altera_Forum
Honored Contributor
9 years ago
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...
Altera_Forum
Honored Contributor
9 years ago
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.
Altera_Forum
Honored Contributor
9 years ago
Should also verify that the 210 MHz PLL is stable locked.
Altera_Forum
Honored Contributor
9 years ago
--- 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...
Altera_Forum
Honored Contributor
9 years ago
Seems the issue could completely eliminated by lowering SignaTap clock (tried 120 MHz). Still don't understand the reason...
Altera_Forum
Honored Contributor
9 years ago
--- Quote Start ---
I don't have any constrains at this part of the project
--- Quote End ---

Means what? The 210 MHz clock is unconstraint (not defined as clock)?
Altera_Forum
Honored Contributor
9 years ago
--- Quote Start ---
Means what? The 210 MHz clock is unconstraint (not defined as clock)?
--- Quote End ---

You are correct. Only purpose of 210 MHz PLL output - to provide clock for SignalTap
Altera_Forum
Honored Contributor
9 years ago
Defining the 210 MHz clock correctly in it's own clock group should assure that the signal tap logic is working correctly inside, or if not possible with the given clock report a timing violation. Signals from a foreign clock domain can cause metastability near the edges but should read correct level in-between.
Altera_Forum
Honored Contributor
9 years ago
--- Quote Start ---
Defining the 210 MHz clock correctly in it's own clock group should assure that the signal tap logic is working correctly inside, or if not possible with the given clock report a timing violation.
--- Quote End ---

Have very limited experience with time analyzing, not sure how to define a clock for SignalTap correctly :(

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