Signal tap hdl instantiation

[Brickman]

Hi

I'm trying to use hdl instantiation flow for signal tap.

I've successfully compiled the design, and created a matching stp file from the create\update menu.

 The issues I have regard the functionality of the stp file vs the GUI generated one:

I have 2 busses, one for data and one for trigger, I want to see only only unified bus, so I can alias ports in one place, is that possible?

In GUI mode, the unified trigger\data bus can also serve as qualifier input, but in the generated IP, I can only assign a qualifier input, that is hardly useful.

Any known solutions for these issues?

Thanks in advance

[sstrell]

You can connect signals to both input busses of the IP but there will still be two busses since signals can selectively be used for data and/or triggering.  This is done with the checkboxes in the Node List in the .stp file flow.

Another reason to not use the instantiation flow.  Why can't you use the standard .stp file flow?

[Brickman]

I understand I need to use 2 busses, but that seems a limitation in the IP generation GUI, or in the stp create tool, the question is, can I hack the outputs of these to tools, so I can work similar to the standard flow?

Reasons why I don't like to work with the standard flow:
QSF gets messy, hard to track with version control tools.

Signals selection is more robust, signals don't change names, optimized away etc.

Backwards compatibility, if I change 1 signal I don't need to program again the FPGA (if it runs an old version), I can ignore that specific signal and use the others.

I've used the HDL instantiation with Vivado's Chipscope, and it worked flawlessly, I'm disappointed with Quartus support for this.

[sstrell]

As far as signal names, you can either tap the pre-synthesis versions of your signals or if you’re using Pro, use the preserve for debug feature to preserve node names through to post-fit.
I’m not sure what you mean about the .qsf file getting messy. For Signal Tap with a .stp file, there’s only one setting that enables the feature and points to the file.
And I also don’t understand what you mean about backwards compatibility. You can set a signal during run time to don’t care so it no longer is needed to cause the logic analyzer to trigger.

[Brickman]

My pre-synthesis names are not identical to my HDL names. 

I have hundreds of lines in my qsf, with assignments such as:

set_instance_assignment -name CONNECT_TO_NODE_ENTITY_PORT acq_storage_trigger_in [*] -to <node name>

set_instance_assignment -name CONNECT_TO_NODE_ENTITY_PORT acq_storage_data_in [*] -to <node name>
set_instance_assignment -name CONNECT_TO_NODE_ENTITY_PORT acq_storage_qualiefier_in [*] -to <node name>

And other settings for the signal tap

Back compatibility means that I can use a current stp file, with an FPGA that is programmed to an old version, without the need to reprogram the FPGA because a single wire changed.

It might be a matter of personal taste, but I prefer to work this way.

Altera claims to support it, but in fact the flow is unusable, and that's a shame, especially since it seems (to me as a user) a low hanging fruit.

[sstrell]

Pre-synthesis nodes by definition are directly from your HDL code.  I'm not sure how you are seeing something different if you are using the appropriate filter in the Node Finder when adding nodes to the Node List in the .stp file.

You have all those assignments in your .qsf because you're using the HDL flow.  None of those are needed for the .stp file flow.

For your backwards compatibility concern, it depends on the type of changes you are making.  You can attach .sof files to the .stp file so the file can check compatibility between the current .stp settings and the .sof.  You can also use the Data Log to store node lists and trigger settings so you can jump back to a prior setup to match a particular .sof.  There's also the ECO compilation feature in Pro that lets you change post-fit signals (add or remove) and other settings with a quick ECO recompile instead of a full recompile.  You don't mention if you're using Standard or Pro.

I've met very few folks who use the instantiation flow.  It's certainly not meant to be as flexible as the .stp file flow simply because you lock connections to the IP in your HDL instead of being able to change those connections separately without touching code.

[Brickman]

I removed the lines from my qsf, used the standard method for signal tap.

The lines reappeared.

For pre synthesis names, if a signals changes names when it traverses hierarchies, it will be an issue.

I don't want direct instantiation to be flexible, I prefer robustness, but it is unusable. 

[RichardTanSY_Altera]

Thank you sstrell for answering. 

Unfortunately, with HDL instantiation of Signal Tap, you cannot directly create a unified trigger/data bus that also serves as a storage qualifier in the same flexible way as the GUI-generated .stp file. The HDL-instantiated IP requires explicit port assignments for data, trigger, and qualifier, and does not support bus aliasing or unified port mapping in the .stp file as the GUI does.

The HDL flow is less flexible for bus aliasing and unified port mapping compared to the GUI.

If you want a unified bus, you must create it in your RTL (e.g., concatenate data and trigger signals into one bus and connect that to both the data and trigger ports, or use the same signal for multiple ports). For the storage qualifier, you must explicitly connect the qualifier port to the desired signal in your RTL; you cannot assign it to a bus in the .stp file after generation.

Consider using the GUI flow if you need advanced aliasing or unified bus mapping.

Regards,

Richard

[Brickman]

Thank you Richard

I have used the same bus in my RTL for data and trigger, but than I still have to alias them separately in the stp, even worse, I will need to change my RTL for every qualifier change. 

At this point I reverted to the GUI flow.

Is there a plan to make the instantiation flow usable in future versions? as a user (who is not involved in the development) This looks like a simple GUI improving task, since the functionality is already in the GUI flow.

Ron

[RichardTanSY_Altera · Accepted solution]

I can submit a feature request to the tool specialists to see if this functionality can be implemented for the HDL flow. However, whether the request is accepted will depend on the business justification.

By the way, which Quartus edition are you using—Pro or Standard?

If you're using the Standard Edition, the chances of this feature being supported are quite low, as most enhancements are prioritized for the Pro Edition.

Regards,

Richard Tan

[Brickman]

Thank you, please submit the feature request.

Sadly, I am using the standard edition.

Ron

[RichardTanSY_Altera]

I’ve submitted a feature request to the team for consideration.
By the way, could you share a bit more about why you prefer using the HDL instantiation flow over the GUI flow? For example, is it mainly for improved robustness, version control, or other reasons?
Understanding your perspective will help us better address your needs.

Regards,
Richard Tan

[Brickman]

Thank you Richard

As I wrote to sstrell, the reasons I prefer direct instantiation are:

• Robustness, I know exactly which signal at which hierarchy I've connected. In addition,  I can add to my code debug signals, that will get optimized away if I don't connect to the signal tap, but are always there if I choose to use them.
• Backward compatibility, I can debug even if there is a mismatch between the stp file and the design programmed to the FPGA, the mutual signals are still functioning.
• Version control, the GUI flow creates a lot of clutter in the qsf file, which is hard to read, I prefer to see the changes in my HDL code.
• Resource usage predictability, I know exactly how much resources are used by signal tap, it doesn't change each time I change the connected signals    

I hope this will help to convince the team that there is a need for this flow.

Ron

[RichardTanSY_Altera]

Thank you for the detailed information. This should be sufficient to help convince the team about the feature request, but please note that there is no guarantee it will be planned or approved.

Regards,
Richard Tan

[RichardTanSY_Altera]

Since I have submitted the feature request to the tool specialist and no further action is required from my end, I will be transitioning this thread to community support.

If you have any further questions or concerns, please don't hesitate to reach out. Please login to https://supporttickets.intel.com/s/?language=en_US , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support.

The community users will be able to help you on your follow-up questions.

Thank you and have a great day!

Best Regards,

Richard Tan