Forum Discussion
New ContributorSignal tap hdl instantiation
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
New ContributorI 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.
Super ContributorI’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.
