Extremely inefficient Quartus Standard elaboration of VHDL function call tree conditional branches

[roeekalinsky]

Elaboration in Quartus Standard Edition is extremely inefficient in its processing of VHDL function call trees, taking an extremely long time with VHDL function call trees that have many conditional branches.

Experimenting with VHDL function call trees and measuring elaboration run times strongly suggests that Quartus Standard Edition elaboration evaluates *every* conditional branch through every level of the call tree, rather than just following the active conditional branch through every level.

Note that this pertains only to Quartus Standard Edition. Quartus Pro Edition doesn't exhibit this characteristic.

I'm providing a simple example that exhibits this behavior. It's a VHDL module (attached) that just sets a constant using a calling tree several functions deep (D), and where each function has several conditional branches (C) via a case statement that each call the next function below.

So if elaboration follows only the active conditional branch at every level, what would be the efficient thing to do, it takes a computational effort proportional to D. Whereas following every conditional branch, not just the active one, takes a computational effort proportional to C^D + C^(D-1) + C^(D-2) + ... + C, i.e. massive exponential growth.

Empirical run time measurements as a function of C and D suggest that Quartus Standard Edition does the latter, whereas Quartus Pro Edition does the former (as do Vivado, ISE, Modelsim, GHDL, and every other tool I have access to that performs elaboration on VHDL).

To run the example provided, place files example.vhd and example.tcl in a directory. In that directory, execute:

quartus_sh -t example.tcl

This issue is not merely academic. I currently have a real world design that takes several days to elaborate in Quartus Standard Edition because of this issue, whereas it takes less than a minute to elaborate in Quartus Pro and every other tool I've tried. So with extremely long run times in Quartus Standard Edition as a result of this inefficiency, targeting legacy Altera devices that aren't supported by Quartus Pro Edition becomes impractical. Which is a shame, because otherwise they would still be perfectly viable, and are still a large market on many existing hardware platforms.

I'd really like to see this fixed in Quartus Standard Edition if the device families not supported by Pro are to remain viable.

[SyafieqS]

Hi Roee,

Noted. Ill try to replicate the issue first and will keep you posted.

Thanks,

Regards

[roeekalinsky]

Thank you, @SyafieqS .  I'll look forward to hearing from you.

-Roee

[Engenre]

Please provide an update on this issue.  A small change to an existing project has now ballooned my run time to beyond 1 week and counting!  This is a real problem that I need resolved ASAP.

Thanks!

[roeekalinsky]

On 2021-04-07 I received the following email from Intel Customer Support. I'm not sure if the individual behind the email was @SyafieqS or someone else:

> Hi Roe,
>
> Apologize for the long silence on this. I can replicate the issue and had file
> an enhancement for this. Note that engineering is working on more priority
> case and this can take sometime for improvement. Let me know if there is any
> other concern on this and will feedback this to developer.
>
> Thanks,
> Regards

To which I replied:

> Hi, and thanks for the update. I'm sorry to hear that this kind of issue is
> not deemed to be a high priority. Can you please provide a time frame for
> when this issue will be addressed by engineering given the current
> prioritization? This will affect strategic decisions with an important client
> as to whether or not we continue to include Quartus Standard and legacy Altera
> devices as supported targets for our IP portfolio. Please let me know.
>
> Thanks,
> -Roee

To date I have not received a response.

[Engenre]

Thanks for posting this issue and the detailed analysis.

I'm having the same issue on one of my projects and it is a real impediment for the project as upgrading to Quartus Prime Pro is not practical in this case.  I sure hope that Intel addresses this issue quickly!

[roeekalinsky]

@SyafieqS , can you provide an update please?

Thanks,

-Roee

[SyafieqS]

Hi Roee,

Yes it is me who sent the email. I just sent an update via the email. Please check it.

[roeekalinsky]

HI @SyafieqS ,

I received your email. Thank you for the update. I'm replying here since this is also of interest to other forum members, including @Engenre .

> Regarding the timeframe for the fix, again due to different priority on hand in engineering, the fix will take some time.

What is "some time"? Does that mean the next release? Or the release after that? Or unknown? Or never? Please be more specific, so we can plan accordingly.

Thanks,
-Roee

[SyafieqS]

Hi Roee,

I am double confirming this with developer and still sending reply the feature request for STD edition status. Will keep you posted. Thanks for your consideration.

[SyafieqS]

Hi Roee,

Update from developer: Unfortunately, the would be no resource for Quartus Standard improvement.

[roeekalinsky]

Ok.  That's disappointing, but thanks for letting me know.

I must say, if Intel is treating Quartus Standard as being at its end of life, as it seems to be, it would be nice if Intel would simply make an end-of-life announcement and not leave its customers hanging in limbo.

-Roee