22.1 PRO: (*preserve_for_debug*) signals not preserved

---

@sstrell wrote:

Yes, and then it says "by specifying assignments in the Assignment Editor or project .qsf file directly." There are multiple methods for using this.

I'm not saying you did anything wrong but again, what you are trying to preserve with this is not what this feature is for.

---

I quoted the documentation showing it is meant for my situation.

Use virtual pin assignments and you will be good to go.

virtual pins aren't mentioned in the doc, nowhere for debugging purpose.

I feel like this "technique" is just a work-around that people have been used and advised for years (and convinced themselves it's the way to go) just due to the lack of proper support for debugging.

After the Xilinx's mark_debug experience, this technique seems very inefficient and a huge step back to the past.

preserve_for_debug is for internal signals, not outputs.

---

there no such limitations written in the doc, quite the opposite

"sigtodebug" is an output of a module, not an output pin, therefore it is an internal signal

Indeed, not for debugging purpose. My signal is not an I/O pin.

If that's the way to go, I'll waste my time with manual work the tool should do.

Thanks for your help.

Hello@Nurina ,

Not really.

The scope of the verilog pragma is still unclear. I see in the documentation that my use case should work but @sstrell says otherwise.

There are lots of cases where the signals aren't preserved, either by setting the pragma in the code or using the contextual menu link in Platform Designer.

Could you confirm as an official answer that the sigtodebug in the code below should be preserved?

module top(
  ...
);

(*preserve_for_debug*)logic sigtodebug; //not used, just want to see it in Signaltap

mymod mymod_inst (
  .out_a (sigtodebug),
  .in_b ('0),
  .in_c ('0)
);

endmodule

This code example is a perfect example to see in SignalTap some status/debug signals left unconnected.

Basically, should any signals marked as preserve_to_debug be preserved?

Either it's a bug and I'd expect a fix, or it's normal and I'll just stop using it and move to another technique to debug signals.

As a comment to Quartus's development team, the difference of the debugging feature between the Xilinx's mark_debug and Intel's preserve_for_debug/SignalTap/virtual pins, is a real pain.

Best regards,

Hi @Nurina,

Please define "use". The signal exists, it's driven by something but doesn't have any fanouts. (it can be a link_up, some counters or anything meaningful only for debugging purpose)

Also, as @sstrell suggested, adding the signal as virtual pin doesn't change anything, the signal is still optimized out.

After Analysis&Synthesis:

This needs to be fixed.

Regards,

Thank you for the confirmation @Nurina.

I've been trying to use this attribute for few days now, it has never worked properly.

Some times I can see the signal under "Preserved for debugging" in the "Node Finder" but the signals are driven and have fanouts, nevertheless even without the attribute they wouldn't be optimized away and are present under "Pre-synthesis".

My question was about a very simple case to show the bug, my use case is mostly using typedef and struct (packed).

typedef struct {
  logic init;
  logic [3:0] b;
} t_data;
(*preserve_for_debug*)t_data tx;
(*preserve_for_debug*)t_data rx;
(*preserve_for_debug*)t_data tx_array[4];
(*preserve_for_debug*)t_data rx_array[4];

Please make sure this is also possible using any data types of Verilog/SystemVerilog.

Regards,