Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
15397 Discussions

22.1 PRO: (*preserve_for_debug*) signals not preserved

alexislms
New Contributor III
576 Views

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

 

alexislms_0-1653546029690.png

alexislms_1-1653546204613.png

 

alexislms_2-1653546325859.png

 

What do I do wrong?

 

Quartus Pro 22.1

 

Regards,

 

0 Kudos
1 Solution
Nurina
Employee
106 Views

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.


View solution in original post

29 Replies
Nurina
Employee
407 Views

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
Honored Contributor III
395 Views

It would also be helpful to see the code for TESTPRESERVE.  What is it connected to?

alexislms
New Contributor III
384 Views

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
Honored Contributor III
377 Views

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
New Contributor III
369 Views

Thank you for the precision, I understand for a no-driver net, nevertheless for a no-fanout net, in the ug 683236:

alexislms_0-1654039018529.png

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
Honored Contributor III
365 Views

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
New Contributor III
358 Views

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
Honored Contributor III
353 Views

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
New Contributor III
346 Views

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
Honored Contributor III
331 Views

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.

alexislms
New Contributor III
293 Views

@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,

sstrell
Honored Contributor III
295 Views

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

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
New Contributor III
293 Views

Thank you but this is exactly the document I used (cf. the above screenshot).

Your statements differ from what is in the documentation.

alexislms_0-1654524564766.png

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.

sstrell
Honored Contributor III
276 Views

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.

alexislms
New Contributor III
228 Views

@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

 

sstrell
Honored Contributor III
242 Views

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

alexislms
New Contributor III
218 Views

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.

Nurina
Employee
191 Views

Hello, did the above comment help?


alexislms
New Contributor III
186 Views

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,

Nurina
Employee
174 Views

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


Reply