Forum Discussion

drbarryh's avatar
drbarryh
Icon for Occasional Contributor rankOccasional Contributor
1 month ago

The best way to implement SignalTapII

Hello Altera SigalTap Experts,

I have been trying to use Signal Tap in my MAX10 FPGA with Quartus STD 25.1 project. I was trying to use the Signal Tap GUI at first.

The problem seems to be that for the signals i want to add to my Signal Tap probes, even after i add a constraint such as:

(* keep = "true" *) logic  vio_init_source;

for example in System Verilog on ALL the signals i want to see in Signal Tap, they keep getting synthesised away. So i don't see a lot of the signals i need post synthesis / post fitting. If i do a node search for them they either don't appear after the search OR if they appear and i try to add them to my Signal Tap probes list they appear in RED {meaning Signal Tap can't use them i guess}.

Then you seem to be forced into doing a 'Rapid Recompilation' which in my experience always means that i need to do a full FPGA compilation. This seems a bit crazy when i already did a full FPGA compile to get to this stage in the first place and i did it with all my 'keep' constraints applied to all the signals i wanted to use with Signal Tap.

I have also tried using the Signal Tap Instantiation in my RTL, but that method also has the same sort of problems.

My Question is: what is the best method(s) to use to guarantee that Signal Tap can find my signals after doing a Synthesis and Fitting run ?

The other question is that it seems (unlike with AMD/Xilinx VivadoScope) that every time i make a change to my trigger equation, signa tap needs to do a full recompile. This is surely wrong and a bit crazy too ! Signal Tap already knows all the signals i am using for my trigger logic so why does it need to do a full FPGA compile { or 'Rapid Recompilation' in Signal Tap speak } when i just change the trigger function ? Is there a better way to use Signal Tap to prevent this sort of behaviour ?

Thanks for your help,

Dr Barry H

 

Compilation
general
Hdl
Platform

16 Replies

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    1 month ago

    Hi Barry,
    starting with your last question, yes a design recompilation is required when you change the list of acquired signals or signal options (trigger- , data-, storage enable, storage qualifier). Also when changing sample depth, type of trigger logic or any power-up trigger parameter. Changing the trigger doesn't require recompilation if all involved signals have already trigger enable set. Chosing acquired signals and signal options thoughfully avoids frequent recompilation.

    I use regularly only pre-synthesis signals for Signal Tap. Finding signals respectively making it visible for Signal Tap can be tricky though. You referred to "keep" synthesis attribute, but it's only applicable for combinational nodes. Registers need "preserve" or "noprune" in case of fanout-free registers (e.g. pure debug registers). Output signals of a sub module can be tapped at the source.

    Regards
    Frank 


    • drbarryh's avatar
      drbarryh
      Icon for Occasional Contributor rankOccasional Contributor
      1 month ago

      HI Frank,

      Thanks very much for your answers ! Right OK so only use pre-synthesis signals in Signal Tap. I get that and will do that from now on. Ok so again thanks for the tip about using preserve on registers and only using keep on combinatorial signals, i didn't know about that. For example then  for a register called timer_tic_running we can have the following options to preserve that register:

      NOT  (* keep = "true" *) logic timer_tic_running;

      YES (* preserve = "true" *) logic timer_tic_running;

      YES(* noprune = "true" *) logic timer_tic_running;

      Is this also OK:
      MAYBE (* preserve = "true, noprune = "true" *) logic timer_tic_running;

      However when you say 'changing the trigger conditions' doesn't require a rapid recompile, sometimes in my case it does do. For example if i have trig1 = 1 and trig2 = 0 and change that to trig1 = 1 and trig2 = 1 Siganl Tap GUI asks me to do a quick recomplie, which always ends up doing a full FPGA compileation. This is the behaviour i think is odd. But your saying this should not occur ? Strange because for me it does !

      Thanks for your Help,

      Dr Barry H

      • sstrell's avatar
        sstrell
        Icon for Super Contributor rankSuper Contributor
        1 month ago

        Where are you changing the trigger conditions?

        In the Node List, for a trigger condition column, if it's a Boolean AND trigger, you can right-click any of the cells in that column (individual signal or [bus] group) and change the value without having to recompile.  You just have to start the logic analyzer running again to look for the new trigger condition.

        So what exactly are you changing that it is forcing you to recompile?  Screenshot would help.

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    1 month ago

    When you add signals to the Node List in Signal Tap, are they appearing as black (pre-synthesis nodes) or blue (post-fit nodes)?  If they're blue, there's no guarantee they'll exist after a subsequent recompile.  The easiest thing to do is stick with pre-synthesis nodes.  Set the filter in the Node Finder when you're adding signals to the Node List to Signal Tap: Pre-Synthesis.  That way, the original signal from your RTL code gets tapped and preserved through compilation.

    Rapid Recompilation only comes into play if you make a change to the Signal Tap setup after a full compilation, so once you tap the signals correctly as pre-synthesis nodes, you shouldn't have to recompile unless you need to make changes to the Signal Tap setup (adding additional nodes or making changes to the settings).

    Also for your last question, it depends on the type of change you are making.  For example, you can change the signal levels for a Boolean AND trigger right in the Node List without having to recompile the design.  

    • drbarryh's avatar
      drbarryh
      Icon for Occasional Contributor rankOccasional Contributor
      1 month ago

      Hi sstrell,

      Thanks for your answers ! Yes i noticed that too....signals can appear as Black, Blue, or in some cases Red in Signal Tap i have been trying all options so far, but now i shall stick to only using pre-synthesis signals. Frank also pointed that out in his reply. 
      On the 'rapid recompile' though i sometimes get that even if i just change my trigger conditions, so using exisiting signals in an already compiled project can still (for me anyway!) Signal Tap to request a ' rapid recompile' which always means doing a full FPGSA compile. But i was confused by that and think it should not happen. You don't need to recompile the FPGA by only changing the trigger conditions. That is a bit crazy. I wonder why in my case i seem to need to do that ? Something dodgy about my Signal Tap build or my trigger signals to begin with possibly ?

      Thanks for your help,

      Dr Barry H

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    1 month ago

    Thank you, sstrell and FvM, for answering the question thoroughly. 
    I couldn’t have explained it better myself.

    Regards,
    Richard Tan

    • drbarryh's avatar
      drbarryh
      Icon for Occasional Contributor rankOccasional Contributor
      1 month ago

      Hi Richard, Indeed both sets of replies were brilliant ! 

      Thanks everybody,

      Dr Barry H