Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

SignalTap fails timing often

Hello,

I have the following problem: When I try to use SignalTap to peek on some of my signals, it often shows values which are not sensible, which is often the result of timing violations between my module and the SignalTap module. I have once manually constrained these paths(with set max delay), and it worked afterwards, but I wouldn't want to do this every time I want to peek somewhere else in my design or when I make significant changes. The SignalTap nodes are generated automatically, so I would have to look at TimeQuest every time and see whether some new register has popped up in SignalTap by my changes.

I am sampling with a clock rate of 62.5MHz on a Cyclone V, so it isn't even that fast for the device.

Is there a way to make the SignalTap automatically constrain the paths it needs?

Have a nice day,

Tibor

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Signaltap is bound by the same constraints for the rest of the design - so if you have specified the clock constraints, the Timequest report will list any failed paths into signaltap

    If there are no errors here, and you're still getting errors - then is it possible you are sampling some signals with the wrong clock?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    SignalTap is just like any other logic in your design and follows the same rules. If you sample signals from other clock domains with the 62.5MHz clock then you will get timing violations unless you tell TimeQuest to ignore timing on those paths.

    Not sure what you mean by: "The SignalTap nodes are generated automatically, so I would have to look at TimeQuest every time and see whether some new register has popped up in SignalTap by my changes." No signals get added to SignalTap unless you manually add them.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    What I meant by that is that I get the timing violations between my nodes that I add in the logic analyser manually, and the registers that are generated to store my signals(acq_data_in_reg[*]). I cannot prepare for these kinds of violations by setting the maximum delay of the signal getting there, as I do not know the required delay before compilation.

    If I have a larger design, checking each and every one of these violations and applying the max delay to them can take a considerably large amount of time, and is generally unpleasant if I have to do this every time I peek somewhere else in my design.

    I do see the violations in the TimeQuest analyzer, I am just searching for a way to generally prevent them, when peeking to various places in my design. I hope I got my message through better now :)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Setting a max delay constraint into the signaltap core is NOT something you should be doing. You do know the required delay, it is the clock frequency.

    If it fails timing simply from the clock constraint, then there is a problem with your design, not the constraints. If you are taking signals from a different clock domain - then again, this is a design problem, not a constraint problem.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Run a timing report in TimeQuest for the failing constraint(s) and in the report look at the launching and latching clocks. If they are not the same then that's your problem. If these are false paths then you can tell TimeQuest to ignore them using the set_clock_groups command. That's a more general-purpose way to ignore the paths than set_false_path or set_max_delay. But if you are getting sampling errors in SignalTap then the paths are really not false and you're violating a very basic design rule. Usually the right way to handle this is to have a separate SignalTap instance for each clock domain, all in the same .stp file. Then you can select one at a time to trigger, or you can add cross triggering if you need it.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Note that it's not clear what you're doing with set_max_delay, and I'm reading posts thinking it's different. Let's say you had some logic that runs off an 8ns clock. You then added SignalTap to tap some of that logic and you properly used that same 8ns clock for SignalTap. The acq_data_in_regs will now be clocked by the same clock as your logic, and TimeQuest will automatically analyze it against the 8ns setup relationship, just like any other logic, and the clock skew should be small(sub300ps). Is that what you're seeing in TimeQuest?

    If not, the problem is that you're using the wrong clock for SignalTap. I see this all the time. Users either fix it by changing the clock, or they cut timing on it and accept that their SignalTaps are not 100% trustworthy. (Many issues can still be debugged like this)

    If the setup relationship is correct and it's low clock skew, a set_max_delay is unnecessary. Note that you could do it to overconstrain the path, such as taking it from 8ns to 6ns, which is not "wrong" but will make it more likely to fail timing(even if it's passing, such as if it has a 7ns delay). If you underconstrain it, such as taking it from 8ns to 10ns, then that certainly is wrong and even if it passes timing you can't 100% trust your captures.

    If everything is set up correctly, it is unlikely that it fails timing. I have recently worked on a design that did this though. Basically we were capturing a lot of signals(about 300) on six different instances of the same thing, and those six instances were spread out across the largest Arria 10 die. So we were tapping from locations all over the die and then putting them into M20Ks to offload, and these would fail timing. I fixed it by creating an instance in SignalTap for each of the six blocks we were tapping, and it then easily met timing.