- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following was observed with Quartus Pro version 22.4. Quartus Standard Edition version 22.1 does not exhibit this issue. And I've not checked any other Quartus versions.
Quartus erroneously generates the following warning:
Warning (21569): VHDL warning at example.vhd(19): function 'example_func' may not always return a value File: example.vhd Line: 19
The attached VHDL file is a trivial example that demonstrates this.
The function example_func certainly does always return a value, and yet Quartus generates this warning.
This is seemingly due to a bad heuristic that Quartus uses to detect this. It seems to take an overly simplistic view of flow of control constructs, i.e. conditional branching, looping, etc. with no regard to the actual flow of control that they implement.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
You received this warning because of the if loop in your function, it doesn't check for other conditions.
When I tried below code, the warning is not generated:
function example_func (
constant dummy_arg : in integer)
return integer is
begin
if (true) then
return 0;
else
return 1;
end if;
end example_func;
Regards,
Nurina
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nurina,
Yes, exactly, Quartus is issuing the warning because of the if conditional... but I think you might have missed the point, that Quartus is wrong to use that as its criteria to conclude that the function may not always return a value.
The else branch that you added to appease Quartus is a dead conditional branch that can never be reached, and the 'return 1' that you put there will never execute. The 'if (true) then' branch with its 'return 0' will execute always. The else branch is superfluous. The function in its original form does return a value, the value 0, always.
The fact that Quartus complains in the absence of an else branch containing a return statement, despite the fact that this else branch would be functionally irrelevant and could never be reached anyhow, is exactly what I was trying to demonstrate with the trivial example I provided.
-Roee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Roee,
Let me try with different versions of Quartus and I'll get back with you on this.
Regards,
Nurina
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Roee,
I have tried with different versions of Quartus and even different versions of VHDL and have found the same results- warning only appears on Pro and doesn't appear on Std.
I have reported this problem to the engineering team and I'll let you know what they come back with.
Regards,
Nurina
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Roee, I'll pass on the feedback to engineering team.
Is there anything else you need from this case?
Regards,
Nurina
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, @Nurina .
If the engineering team does decide to make any improvements on this issue, I would love to know about it. Otherwise, I think we can close out this case.
Thanks again,
-Roee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
honestly, I'm unable to determine from VHDL standard lecture if the queried error message is a bug or a feature required by the language. The fact that the message doesn't occur in previous QPP versions can't answer the question.
I presume engineering team has an idea why they consider the error check necessary, would be helpful to know the reason.
Regards,
Frank
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I too would be interested to know their specific reasons.
As I understand their response, I don't think they're even claiming that their check is required by the VHDL language standard. Rather, it seems they're regarding this is a code quality check or linting check of sorts. And hence WARNING and not ERROR, presumably. Though I would say even as a linting check it is still overzealous, given the limitations of the simplistic analysis that they're doing that causes it to issue warnings on perfectly good code.
As it pertains to the VHDL language standard, the VHDL LRM specifies only that "It is an error if execution of a function completes by any means other than the execution of a return statement." In the code example I provided, execution of the function always completes by execution of a return statement. The code example fully satisfies the requirement specified in the LRM.
If there's another relevant requirement somewhere in the LRM that I missed, I'd love to see a reference to it. I'm all for strict compliance with the LRM on all sides. And good quality code beyond that.
-Roee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Roee and Frank,
Based on engineering team's feedback, the Quartus PRO has much better frontend and they're always looking to improve the compiler. So this check is not a feature, it is an improvement so that customers can fix their RTL.
Again, if you don't like this check, you can always suppress the warning message.
Since the engineering team won't fix this, I shall close this case. I now transition this thread to community support. If you have a new question, Feel free to open a new thread or login to ‘ https://supporttickets.intel.com ’, 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.
Regards,
Nurina
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Nurina,
in this case it is not about "like the check",
the check is incorrect as the function does not use the input to decide the return value,
it uses the TRUE, which means it will always be entered.
Maybe that Quartus should mentioned another Warning message (instead of may not always return a value),
something like:
Function always returns value 0, is that expected?
Alex.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page