Forum Discussion
Contributor22.1 PRO: (*preserve_for_debug*) signals not preserved
Hello,
Alright thanks for the feedback. I've let them know that you expect this fix to apply to all data types.
In the meantime your only workaround is to have the signal connected to an i/o port.
With that, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.
Regards,
Nurina
P/S: If you like my comment, feel free to give Kudos. If my comment solved your problem, feel free to accept my comment as solution.
Regular ContributorHello, did the above comment help?
alexislmsHello@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) ); endmoduleThis 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,
