Contributor
Regular ContributorHello Roee,
I have received response from engineering team.
Below is their feedback:
Based on the VHDL code the warning is correct. Consider this an enhancement in PRO to identify a bad VHDL code segment. At the time of warning we do not perform full data path analysis just to suppress warning. If user wants, they are free to suppress the warning on their side.
You may suppress the warning by right clicking the Warning message>Supress
Regards,
Nurina
ContributorHi @Nurina ,
Thanks for passing along their response.
It sounds like confirmation of the simplistic code analysis they perform behind that warning, and it sounds like that is as they intended.
So please take the following as user feedback:
Checking for and flagging potential RTL problems in synthesis is indeed a welcomed enhancement in the tools, in general. However, to be of value, the code checks performed by the tools themselves need to be of high quality and rigor, and must first and foremost be analytically correct. Warnings, when rightly generated by the tools, are highly valuable to the user. Whereas nuisance warnings, those that are wrongly generated by the tools, have negative value to the user in that they effectively raise the noise level and can thereby mask rightfully generated warnings.
This particular code check that we're discussing here, produces warning messages that are often unjustified and flatly incorrect, resulting from the overly simplistic code analysis behind the warning. In other words, this code check has a specificity problem, being prone to producing a high proportion of false positives. So I would encourage the development team to enhance their enhancement, to build in the necessary intelligence in their code analysis to generate these warnings with better specificity. Then, if generated only when justified, these warnings would be of high positive value.
Thanks,
-Roee
