Node finder in SignalTap II

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...)