- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ! :)Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Should also verify that the 210 MHz PLL is stable locked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Seems the issue could completely eliminated by lowering SignaTap clock (tried 120 MHz). Still don't understand the reason...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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 :(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ---- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page