Node finder in SignalTap II

[Altera_Forum]

I found sometimes it's difficult to find exactly the signals in my VHDL file. After complilation,some signals may have been optimized(removed) by Quartus II and can't find them anymore.  

Especially for some signals in lower level of my design. Does somebody have any idea how to keep these signals visible in NodeFinder of SignalTap II?  Is there any "signal preservation " technics?

[Altera_Forum]

There are tricks for preserving them, but you usually don't want to do that. (A case where you might is if you create a register that captures some signal based on logic and that register doesn't go anywhere, i.e. it should get removed, but you want to keep it so you can signalTap it. In this case, it makes sense for it to be removed. Open your HDL file in Quartus and go to Edit -> Insert Template and find the Verilog or VHDL synthesis attributes and look for noprune, which keeps a fanout free register. THere are others listed for wires and other scenarios). 

Most likely though, you don't expect this logic to get synthesized away, and you need to find out why Quartus is removing it. Note that the many times I've done this, it turns out Quartus is doing the right reduction and there's something wrong in the code. Two good places to look are in the Synthesis report(look at .map.rpt since you'll need to search) and there's a report on registers removed, as well as a second report on Registers Removed that Triggers Further Optimizations. This second one is meant to help look for the "first domino" that gets removed and causes a lot of other stuff to get removed. So if one of your registers is in the right side of the report, find the register on the left and the reason it gets removed, then try to fix that. This is usually not easy though. One other trick is to either compile lower levels of the hierarchy. As you go down, the problem may disappear, in which case you know the optimization is due to something above this level. (Another way to do this is to put hierarchies above the problem area into partitions, which preserve their boundaries. For example, if your hierarchy is A|B|C|D|E and stuff in E is getting removed, then if you put E into a partition and those registers come back, you know the problem isn't in E. THen if you remove that partition and add one to D and recompile, and the registers don't get removed, the problem isn't in D. If you remove that partition and add one to C, and the registers get removed, then you know there's a reduction in C that trickles down to E.) I believe there's a Connectivity Report in the synthesis report that tells you if you have ports tied off or unconnected, which may also help find it. Still, with all this, it's often not easy to do, so good luck. (And just looking through the messages, even though there may be a lot, can be useful. For example, I was doing some Verilog and mistyped the name of a signal, e.g.: assign some_signal_name <= ohter_signal_name; In this case, I mispelled other. If you don't declare a wire in Verilog, you get a warning that it's not declared, but Verilog assumes you meant to and creates a wire called "ohter_signal_name". Now, since it's a typo, nothing drives this wire and everything downstream gets synthesized out. I prefer Verilog, but this is my biggest complaint...)

[Altera_Forum]

--- Quote Start ---  I found sometimes it's difficult to find exactly the signals in my VHDL file. After complilation,some signals may have been optimized(removed) by Quartus II and can't find them anymore.  Especially for some signals in lower level of my design. Does somebody have any idea how to keep these signals visible in NodeFinder of SignalTap II?  Is there any "signal preservation " technics?  --- Quote End ---    The node finder defaults to "post-fitting" as the filter for finding signals. I always use the "pre-synthesis" filter instead, for the exact reason you complained about above. I like to see my logic as I coded it rather than how the tools morphed it. There may be some side effects to doing it this way, but it works for me. Having to deal with the post-fitting view of things just slows me down.

[Altera_Forum]

Good point rsefton. I forgot about that, and if the signals are missing just because they're not post-fit(but they do exist in the design), then my previous message can be ignored. 

Post-Fitting is most useful if you set your Top partition to post-fit. You can now keep the design locked down and do quick SignalTap compiles(as SignalTap is another partition that is therefore synthesized independently, and with Top locked down, placed independently). So it's a nice way to do quick SignalTap compiles and to debug anything that might change compile to compile. But you're also stuck looking at post-fit nodes. If you go to pre-synthesis, you have a lot more options and they make sense, but you must run a complete compile from scratch to get it to work. Often users don't care, but those are the trade-offs.

[Altera_Forum]

On my current Arria II GX design compile times are 75+ minutes on the fastest machine I have available. So making SignalTap pre-synthesis changes means almost 90 minutes of lost debug time. I have never played with the post-fitting option, so thanks for the tip! I will definitely have to check that out. Being able to add signals quickly would be a godsend at times.

[Altera_Forum]

It won't be a 5 minute compile, but it should be much faster. Just remember to turn your Top partition back to Source when you want to compile everything. 

Also, Rapid Recompile has been improved a lot to work with SignalTap, although I'm not sure if it works for Arria II. Eventually it should be even faster, as it has the capabilities to do very targeted changes. For that flow, you'd just change your SignalTap and run Rapid Recompile. I think long-term that will be the recommended flow.

[Altera_Forum]

Thank you all for such detailed explanation and useful tricks!