Filtering the reported problems
Is it possible to remove "known good" messages from the window with reported problems? I would like to have an empty problem window such that any real problem can be found immediately.
In my case: I have a file with behavioral VHDL code and I get 11 warnings on sensitivity lists of which I know that the VHDL code is written on purpose without these signals in the sensitivity list.
- Forums:
How?
Hi Jan-Willem,
depending on what/how you see this, this is already possible or not.
In the problem view you can select problem (error/warning/info) markers and delete them. But since these markers will be recreated during a recompile, this is only useful in some situations.
Another option is to disable certain problem markers. But in your case this would also disable sensitivity list checking in RTL code too.
Ignoring specific "known good" markers is not possible yet. There are still too much unanswered question to specify this feature.
Do you want to add annotations in your VHDL code? What syntax (Java has a @SuppressWarnings predefined by the language specification itself)? Maybe just as project specific meta-data outside the VHDL code?
Do you want to mark files (Or design units) as "behavioral" with a different set of rules?
Curious for your ideas,
Hendrik.
What I had in mind:
Hendrik,
I see 2 options for cleaning up the error/warning/info window:
1) Postprocessing: some kind of filtering which can select messages based on ID, file, etc. with possibly regexp capability. This is more or less the "waive" window of the Spyglass tool. The problem window would then have a summary line "N1 errors, N2 warnings, N3 info, N4 waived"
2) Not generating the message by adding some kind of comment or pragma to the VHDL code. Something like "-- sigasi translate_off", "-- sigasi translate_on" .
I don't think it is a good idea to mark files as behavioral with different rule sets. It sounds like opening pandoras box. Which rules would apply/not apply for these behavioral files?
Jan-Willem
Filtering problems
Hi Jan-Willem,
thanks for your input.
At this point we have not decided yet how we will approach this feature. In the mean time we remain curious for more ideas how to deal with "known good" messages.
Hendrik.
Instantiation of technology specific component warning
Hello Hendrik,
This thread is probably a bit old, but I have a similar problem with warnings. Throughout the design process, I frequently optimize some of my code with Xilinx primitives which sometimes flags the warning:
"Instantiation of technology specific component 'xxxx'. Try to use inferred logic where possible."
(where xxxx is the name of the Xilinx primitive - in my case it is srl16e.)
I've noticed that some Xilinx primitives don't get flagged with warnings, while some others (like srl16e) do. Is there anything I can do to suppress these warnings manually? I currently have more than 50 warnings that I have to sort through in order to find the legitimate ones.
Thanks,
Brad
Technology specific component warnings
Hi Brad,
we have preference page for ignoring all markers of a certain problem class. But it seems like the technology specific component warnings option is missing. I logged this as ticket:1495
Hendrik.
ticket:1495
We decided to completely disable technology specific component warnings in the next release.
Hendrik.
Post new comment