22.1 PRO: (*preserve_for_debug*) signals not preserved - 22.1 PRO: (*preserve_for_debug*) signals not preserved 1. I follow the steps " 2.4.1. Preserving Signals for Monitoring and Debugging " in 683819 2. I watched and followed this Intel-FPGA video: https://www.youtube.com/watch?v=sEKc2ut42gU What do I do wrong? Quartus Pro 22.1 Regards, Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Quartus pro 23.1, we still have issues with preserve_for_debug... This will never ends... IPS case opened, I just comment here for tracking purpose. Replies: Re: 22.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. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Thank you. I can't attach my design, the basic use cases don't work. They can find some examples in my previous messages above. (+enum +mixed packed/unpacked arrays +...) Looking forward to being able to use this feature. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Hi, The fix is for a future version, so it will take a few months. For now, a workaround would be to connect the signal to a top-level output port. Could you attach your design? The engineering team might be able to do something to help with your situation. Regards, Nurina Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved @Nurina , Thank you, will it be in a future version (few months) or a patch (few days)? What's the time frame we can expect it to be working? Regards, Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Hi, This problem has been previously reported to the engineering team and they are currently working on a fix for a future version of Quartus. I'm checking with them if there is a workaround you can use while waiting for the permanent fix. Regards, Nurina Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved 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, Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Hi, By use, I meant that it's driven by something with fanouts. Although with this attribute we should expect it to be preserved no matter what. This looks like a bug, I'm reporting this issue to our engineering team. I will let you know of any updates. Regards, Nurina Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved I've also tried via the Assignment Editor : set_instance_assignment -name PRESERVE_FOR_DEBUG ON -to *sigtodebug* without success. The signal isn't kept. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved 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, Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Hi, I've tried to reproduce your problem on my machine. It would only be preserved if you use the sigtodebug in your design. Maybe this is happening because it's been synthesised away. I'll bring this up to our internal team and ask if this is intentional. Regards, Nurina Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved 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, Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Hello, did the above comment help? Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved 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. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved I don't want to argue. I'm just explaining how I use the features. Virtual pins have been around in the software forever to prevent unconnected I/O from being optimized away. Preserve for debug was only recently introduced because it was frustrating if you wanted to tap a deeply buried signal that was post-fit (as opposed to pre-synthesis directly from your RTL). A happy side effect of doing this is it can reduce or eliminate recompiles since tapping post-fit signals uses incremental routing (aka available post-fit routing wires). Replies: Re: 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 Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved 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. Use virtual pin assignments and you will be good to go. preserve_for_debug is for internal signals, not outputs. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Thank you but this is exactly the document I used (cf. the above screenshot). Your statements differ from what is in the documentation. I don't do anything wrong, I even do what is recommended . Once more, the pragma preserve_for_debug is broken, it doesn't preserve the signals. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved The assignments to use are documented here: https://www.intel.com/content/www/us/en/docs/programmable/683819/22-1/marking-signals-for-debug.html and discussed in this training: https://learning.intel.com/developer/learn/course/external/view/elearning/205/signal-tap-logic-analyzer-state-based-triggering-compilation-programming You mark nodes or entities in the Assignment Editor instead of editing your HDL code. The Assignment Editor is just a graphical tool to ease editing of the .qsf file. You can edit the .qsf file directly if you want. After they're marked, you enable the feature, as you have done, do a full recompile, and then add the preserved nodes in Signal Tap using the dedicated Node Finder filter. These things are all discussed in the doc and training I linked to. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved @sstrell noprune : Prevents Intel Quartus Prime from removing or optimizing a fanout free register a fanout free register is exactly an unconnected signal. Could you explain your workflow to add signals in signaltap without the need to modify the code with any verilog attributes? With eventually a simple example. I'm new to Intel and compared to Xilinx's mark_debug and ILA, it seems very time consuming then I'd be glad to know your method. Thank you, Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved You asked " what do you call I/O?" , and I call a top-level device package pin an I/O. Again, the feature is not for I/O or unconnected signals. It's for buried signals that may get optimized away or have their name changed through the course of compilation and optimization. With the preserve for debug feature, there is no need to even create an unconnected signal like what you are doing since you can preserve whatever that stub is connected to and then tap it in Signal Tap. You don't have to alter your design just to accommodate debugging. And when you're done with Signal Tap, you simply disable it and recompile to remove the Signal Tap logic implementation. So in your example, tap whatever is driving out_a in the instantiated entity. You can use preserve for debug on it if you want and that will guarantee it's preserved and make it easy to find by being in its own filter in the Node Finder when adding signals to Signal Tap. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved I never talked about a pin nor an I/O pin. Sorry, if I understand well, your solution is to not use the feature supposed to be made for that exact purpose? I can flag any signals I want using Xilinx Vivado's mark_debug and it will automatically detect all the flagged signals, net, register, with or w/o fanout and allows me to add them without other manual intervention, it also detects which clock the signal is driven by. I hoped preserve_for_debug had a similar behavior without having to manually create virtual pins on specific signals. I also don't want to care whether the signal has fanout or not. Moreover, the goal is to flag a structure whose some members are connected and some left unconnected. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved An I/O is a top-level pin. You don't show your top-level ports, but you can't connect an I/O (top-level port) directly to Signal Tap anyway because there is no routing from the I/O element back into the device to connect to Signal Tap. You have to tap the signal that feeds into the I/O, which you can find in tools like the Node Finder in Signal Tap or the Technology Map Viewer. As for sigtodebug specifically, if you have a virtual pin, you don't need preserve_for_debug. The signal would be preserved and you could tap it directly. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Sorry for the misunderstanding, what do you call I/O? Actual I/O of the fpga (ports of the top connected to pins) or any instance ports? Here is the code showing the signal I'd like to debug and that isn't kept by Quartus: 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 Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Again, preserve for debug is not for I/O. It's for internal nodes. You can use noprune or virtual pins. I like virtual pins because I don't need to make any changes to the HDL code, just create an assignment, just like using preserve for debug as an assignment instead of an attribute. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Thank you for the precision, I understand for a no-driver net, nevertheless for a no-fanout net, in the ug 683236: noprune : Prevents Intel Quartus Prime from removing or optimizing a fanout free register If it isn't the case, this is something Intel should add in Quartus, adding virtual pins must be done automatically by Quartus or the preserve_for_debug attribute is meaningless. Moving from Xilinx to Quartus, this debug workflow seems inefficient. Regards, Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved If it's not going to get connected to anything, that's not what preserve for debug is for. Instead, add a virtual pin assignment to the node. Preserve for debug is to preserve internal nodes through the compilation and optimization process, maintaining their names so they can be easily added to post-fit debugging tools like Signal Tap. Virtual pins are logic stubs created to prevent I/O from getting optimized away. Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved 1. TESTPRESERVE has no load, I want to keep it for future use without having to change the stp file. If that's not possible, then it's okay if it isn't present. 2. For the other case, it looks like either preserve_for_debug or Quartus is unable to keep my signals, it's unusable. I see the equivalent net and its driver in the post-synthesis netlist (inside an instance, connected to one of its ports), somehow Quartus doesn't keep the net with the name I specified in my code. (Xilinx's Vivado adds LUT in between to keep both equivalent nets, how about Quartus?) 3. There is no warning containing 13228. I tried noprune, keep, preserve, but in reality I don't really care about register or wire, the goal is to add an attribute to a structure with (SV's) logic members. What is the 100%-always-working solution for Quartus 22.1? Regards, Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved It would also be helpful to see the code for TESTPRESERVE. What is it connected to? Replies: Re: 22.1 PRO: (*preserve_for_debug*) signals not preserved Hello, May I know if you receive this warning: Warning (13228): Verilog HDL or VHDL warning at <file>: defparam under generate scope cannot change parameter values outside of its hierarchy File: <file> If yes then please follow the guidelines in this KDB: https://www.intel.com/content/www/us/en/support/programmable/articles/000090673.html Best regards, Nurina - 2022-05-25