Forum Discussion

roeekalinsky's avatar
roeekalinsky
Icon for Contributor rankContributor
2 years ago

Quartus Pro bug report: erroneous generation of warning 21569

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.

14 Replies

  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    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



    • roeekalinsky's avatar
      roeekalinsky
      Icon for Contributor rankContributor
      2 years ago

      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

  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Roee,


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


    Regards,

    Nurina


  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    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


  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    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


    • roeekalinsky's avatar
      roeekalinsky
      Icon for Contributor rankContributor
      2 years ago

      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

  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

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

    Is there anything else you need from this case?


    Regards,

    Nurina


    • roeekalinsky's avatar
      roeekalinsky
      Icon for Contributor rankContributor
      2 years ago

      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

      • FvM's avatar
        FvM
        Icon for Super Contributor rankSuper Contributor
        2 years ago
        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
  • Nurina's avatar
    Nurina
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    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


  • AEsqu's avatar
    AEsqu
    Icon for Contributor rankContributor
    2 years ago

    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.