Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16644 Discussions

Quartus Pro bug report: erroneous generation of warning 21569

roeekalinsky
Valued Contributor I
1,427 Views

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.

 

0 Kudos
14 Replies
Nurina
Employee
1,407 Views

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



0 Kudos
roeekalinsky
Valued Contributor I
1,400 Views

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

0 Kudos
Nurina
Employee
1,375 Views

Hi Roee,


Let me try with different versions of Quartus and I'll get back with you on this.


Regards,

Nurina


0 Kudos
roeekalinsky
Valued Contributor I
1,340 Views

Ok, I'll look forward to hearing from you.

Thanks,

-Roee

 

0 Kudos
Nurina
Employee
1,301 Views

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


0 Kudos
roeekalinsky
Valued Contributor I
1,285 Views

Thank you, @Nurina .  I'll look forward to hearing what they come back with.

-Roee

 

0 Kudos
Nurina
Employee
1,252 Views

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


0 Kudos
roeekalinsky
Valued Contributor I
1,234 Views

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

 

0 Kudos
Nurina
Employee
1,220 Views

Thank you Roee, I'll pass on the feedback to engineering team.

Is there anything else you need from this case?


Regards,

Nurina


0 Kudos
roeekalinsky
Valued Contributor I
1,212 Views

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

0 Kudos
FvM
Valued Contributor III
1,203 Views
Hello,
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
0 Kudos
roeekalinsky
Valued Contributor I
1,187 Views

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

 

0 Kudos
Nurina
Employee
1,130 Views

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


0 Kudos
AEsqu
Novice
1,097 Views

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.

 

0 Kudos
Reply