Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

Weird SignalTap behaviour

Altera_Forum
Honored Contributor II
2,016 Views

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 II
874 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.

0 Kudos
Altera_Forum
Honored Contributor II
874 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...
0 Kudos
Altera_Forum
Honored Contributor II
874 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.
0 Kudos
Altera_Forum
Honored Contributor II
874 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
874 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...
0 Kudos
Altera_Forum
Honored Contributor II
874 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
874 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)?
0 Kudos
Altera_Forum
Honored Contributor II
874 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
0 Kudos
Altera_Forum
Honored Contributor II
874 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.

0 Kudos
Altera_Forum
Honored Contributor II
874 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 :(
0 Kudos
Altera_Forum
Honored Contributor II
874 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.
0 Kudos
Altera_Forum
Honored Contributor II
874 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".
0 Kudos
Altera_Forum
Honored Contributor II
874 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 ---  

0 Kudos
Altera_Forum
Honored Contributor II
874 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.
0 Kudos
Altera_Forum
Honored Contributor II
874 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?
0 Kudos
Reply