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,

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, NurinaP/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.

22.1 PRO: (*preserve_for_debug*) signals not preserved

30 Replies

sstrell
Super Contributor
3 years ago
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.
- alexislms
  Contributor
  3 years ago
  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.
Nurina
Regular Contributor
3 years ago
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
- alexislms
  Contributor
  3 years ago
  @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,
Nurina
Regular Contributor
3 years ago
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
- alexislms
  Contributor
  3 years ago
  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.
Nurina
Regular Contributor
3 years ago
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.
Nurina
Regular Contributor
3 years ago
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
sstrell
Super Contributor
3 years ago
It would also be helpful to see the code for TESTPRESERVE. What is it connected to?
alexislms
Contributor
3 years ago
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,
sstrell
Super Contributor
3 years ago
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.
- alexislms
  Contributor
  3 years ago
  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,
sstrell
Super Contributor
3 years ago
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.
- alexislms
  Contributor
  3 years ago
  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
sstrell
Super Contributor
3 years ago
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.
- alexislms
  Contributor
  3 years ago
  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.
  - sstrell
    Super Contributor
    3 years ago
    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.