Hello, Recently I have had a design where SignalTap ignores my triggers no matter what trigger I set. Each time I hit Run, SignalTap comes back immediately as if I had no triggers set. That data seems right though. I am assuming this has to do with timing not met - and indeed I do see that some signaltap signals do not meet timing. Am I correct in this? Most often I do have signal tap violating timing but it is because I have a number of clock domains being monitored and I do need to see all of those signals. Do you guys have any advice on how to handle this? Do I have to CDC all of the signals I need to capture so that they are all in the clock domain of the clock used by signal tap? Thank you!

When monitoring signals in different clock domains you need to use signaltap with multiple clock domains. There is an option to select to create extra clock domains. Then your capture runs all domains at same trigger point which could be inserted in any of domains.

If the failures are because you're capturing data from another domain, it would not cause SignalTap to not trigger. I've seen this done and just makes the data "inexact". For example, if you're capturing a bus of data from another domain, you might have cycles where some of the bits are new data and some is old, making it very hard to read. Hopefully you're sampling with the faster clock. But as long as you know this, you can possibly weed through it. Just remember anything crossing domains is "suspect". Are your triggers in other domains? THat might cause problems, but I would it expect it to be sporadic, not a constant failure. In general, SignalTap should meet timing pretty easily on its internal stuff that it runs off of. I've never seen timing issues make it not trigger. I'm assuming the two are unrelated, although it is possible they're not. Has SignalTap ever worked?

I will try to configure SignalTap with multiple domains and see. The odd thing is that I have never seen this before - even with multiple clock domains. SignalTap was working perfectly on this project until I added a DDR controller and since then, for some compiles signaltap works, for others it does not. I have had other designs in the past with DDR and had no issues with signal tap. First I thought it was my cable, but that was not the issue because I tried it on a different project - same board though. Yes, I did specify the fastest clock in my design just to avoid trigger misses. The missed trigger happens whether I put it on a signal from a slow domain or the same domain as the sampling clock.

I saw one desing with the JTAG signals running alongside a memory interface(it was a much slower interface than DDR, but the traces ran alongside each other for a long distance). Ended up being noise coupled onto the TCK. A pain to debug. Here's a post I did after it: http://www.alteraforum.com/forum/showthread.php?t=687 I'm not saying that's the issue, but it is strange. Possibly try a) making your signaltap as simple as possible. b) removing the DDR from the design, if possible, and see if everything starts working. Good luck.

I did that before. The good news is that simplifying my design makes signaltap work again. But, adding my stuff back breaks it. I am currently removing pieces at a time to see that is causing the issue - 45 minutes at a time. :-) I will try to report back if I find anything. I looked at multiple domains using signaltap. So far it is looking that each domain will need a different instance, which may not allow me to mix signals I need to see. About the xtalk, the traces were all simulated and the DDR works fine with no errors.

SignalTap and Timing | Altera Community

12 Replies

Altera_Forum
Honored Contributor
14 years ago
When monitoring signals in different clock domains you need to use signaltap with multiple clock domains. There is an option to select to create extra clock domains. Then your capture runs all domains at same trigger point which could be inserted in any of domains.
Altera_Forum
Honored Contributor
14 years ago
If the failures are because you're capturing data from another domain, it would not cause SignalTap to not trigger. I've seen this done and just makes the data "inexact". For example, if you're capturing a bus of data from another domain, you might have cycles where some of the bits are new data and some is old, making it very hard to read. Hopefully you're sampling with the faster clock. But as long as you know this, you can possibly weed through it. Just remember anything crossing domains is "suspect".
Are your triggers in other domains? THat might cause problems, but I would it expect it to be sporadic, not a constant failure.
In general, SignalTap should meet timing pretty easily on its internal stuff that it runs off of. I've never seen timing issues make it not trigger. I'm assuming the two are unrelated, although it is possible they're not.
Has SignalTap ever worked?
Altera_Forum
Honored Contributor
14 years ago
I will try to configure SignalTap with multiple domains and see. The odd thing is that I have never seen this before - even with multiple clock domains.

SignalTap was working perfectly on this project until I added a DDR controller and since then, for some compiles signaltap works, for others it does not. I have had other designs in the past with DDR and had no issues with signal tap. First I thought it was my cable, but that was not the issue because I tried it on a different project - same board though.

Yes, I did specify the fastest clock in my design just to avoid trigger misses. The missed trigger happens whether I put it on a signal from a slow domain or the same domain as the sampling clock.
Altera_Forum
Honored Contributor
14 years ago
I saw one desing with the JTAG signals running alongside a memory interface(it was a much slower interface than DDR, but the traces ran alongside each other for a long distance). Ended up being noise coupled onto the TCK. A pain to debug. Here's a post I did after it:
http://www.alteraforum.com/forum/showthread.php?t=687
I'm not saying that's the issue, but it is strange. Possibly try a) making your signaltap as simple as possible. b) removing the DDR from the design, if possible, and see if everything starts working. Good luck.
Altera_Forum
Honored Contributor
14 years ago
I did that before. The good news is that simplifying my design makes signaltap work again. But, adding my stuff back breaks it. I am currently removing pieces at a time to see that is causing the issue - 45 minutes at a time. :-)

I will try to report back if I find anything.

I looked at multiple domains using signaltap. So far it is looking that each domain will need a different instance, which may not allow me to mix signals I need to see.

About the xtalk, the traces were all simulated and the DDR works fine with no errors.
Altera_Forum
Honored Contributor
14 years ago
With multiple instances of same signaltap you will be running all instances together each clocked by its clock and having any signals you add.
The tigger can be made in one of them or a common signal shared across
Altera_Forum
Honored Contributor
14 years ago
kaz,

Let's say I create 3 instances of signaltap for 3 different clock domains and want to see the state of the 3 groups when a trigger happens. Do I have to have the signal to trigger on present in all 3 instances or can I link them somehow? If I have to have that signal in all 3 instances, wouldn't that mean that I will have the same CDC issues?
Altera_Forum
Honored Contributor
14 years ago
Good point, you can choose a level trigger rather than edge trigger. A signal that goes low to high in clk domain1 would soon be detected by other clock domains. Timing violation is possible but the level will soon settle and you may have one or more samples offset depending on lowest frequencies.

I don't see timing violation to be an issue here since the signaltap uses dual port ram and if in doubt you may synchronise that trigger signal to each domain then use some tricks to best align them in time.
When running signaltap each instance will be triggered by its own trigger moment.
Altera_Forum
Honored Contributor
14 years ago
The interesting part is since signal tap uses a dp ram, why would there be timing violations? I am suspecting that most of them are false paths. This is unless the triggers happen at the dp ram input and not the output, which should be in the trigger clock domain.
Altera_Forum
Honored Contributor
14 years ago
I should correct myself. It uses dual port ram but one clock is on read in side(sampling fpga signals) and the other for reading out from its buffer.

by the way I used to use a trigger from a manual switch onto 3 clock instances and it worked well even though it was asynchronous to any clock.

Forum Discussion

SignalTap and Timing

12 Replies

Recent Discussions

Failing IO buffer

Quartus/Signaltap complains about wrong version

Perpetual license Quartus II doesn't allow to build Cyclone V devices anymore.

Highlight similar instances of a selected word fails when scrolling

Board-Aware Flow autoring