Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,192 Views

Weird SignalTap behaviour

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 ! :)
0 Kudos
15 Replies
Altera_Forum
Honored Contributor I
50 Views

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 I
50 Views

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 I
50 Views

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 I
50 Views

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

Altera_Forum
Honored Contributor I
50 Views

 

--- 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 I
50 Views

Seems the issue could completely eliminated by lowering SignaTap clock (tried 120 MHz). Still don't understand the reason...

Altera_Forum
Honored Contributor I
50 Views

 

--- 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 I
50 Views

 

--- 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 I
50 Views

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 I
50 Views

 

--- 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 :(
Altera_Forum
Honored Contributor I
50 Views

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 I
50 Views

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 I
50 Views

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 I
50 Views

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 I
50 Views

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?