Hyper-Retiming, How to disable it in the .qsf?

Hello,

Please note that internal team is currently investigating your problem. I'll let you know of any updates.

Regards,

Nurina

Hello,

May I know what is the frequency the design is running at?

Regards,

Nurina

Hi Alex,

Can you share me the design where the retime stage uses up long compilation time? I suspect that this is a bug.

You can share it through e-mail. I'm dropping you an email right now.

Regards,

Nurina

Hello Alex,

Without your design, it will be difficult for me to help you. Is it possible to share through e-mail?

I have checked with the internal team, they have confirmed that your target OPN 1SX280HU2F50E1VG should work with the ASIC_PROTOTYPING_FEATURES qsf.

Can you share the compilation time of before and after adding the set_global_assignment -name ASIC_PROTOTYPING_FEATURES ON qsf setting?

Also, does the compilation report show any reports for retime stage?

Regards,

Nurina

Hi Alex,

Thank you for the qsf files and reports. Let me try an example ASIC Prototyping design from my end and I'll let you know of my findings.

Regards,

Nurina

Hi Alex,

I've tried an example ASIC Prototyping project targeting Stratix 10 GX 10M and found the same observations as you. I have reported this issue to our engineering team. Below are my findings when using ASIC_PROTOTYPING_FEATURES:

1. After running fitter, I can see that there is a drop in runtime spent at retimer, however it's not completely skipped (I think this is an expected behaviour, need engineering team to confirm)
2. Received below info messages indicating the tool is trying to retime the project. But when I check the retiming limit details report, it says that meeting requirements for all clock domains are met and therefore does not require any optimization. This is obviously a bug, engineering team is currently investigating the problem.

Info(17966): Starting Hyper-Retimer operations.

Info(18914): The Hyper-Retimer was unable to optimize the design due to retiming restrictions. Run Fast Forward Timing Closure Recommendations to see step-by-step suggestions for design changes and show the estimated performance improvement from making these changes.

Info(17968): Completed Hyper-Retimer operations.

I'll let you know what the engineering team comes back with.

In the meantime, to reduce compile time you may try using "Aggressive Compile Time" Optimization Mode. To set this, go to Assignments>Settings>Compiler Settings>Optimization Mode. This would reduce the general compilation time hence reduce performance. Based on our findings the retime stage will not be skipped entirely but this optimization mode should reduce the whole compilation.

More info here: https://www.intel.com/content/www/us/en/docs/programmable/683236/21-3/optimization-modes.html

Regards,

Nurina

Alex,

May I know if you're fine to close this case while engineering investigates this problem?

Regards,

Nurina

Hi Alex,

Below are the updates from engineering team:

The retimer is working as expected when you enable the ASIC_PROTOTYPING_FEATURES setting. This setting only affects the retime stage runtime by disabling register retiming and it doesn't skip the whole retime stage.

(1) The info messages are a bug and they plan to change the messages in a future version of Quartus (I legally cannot disclose which version as that is confidential information). For now, you may ignore the messages, the retimer is working just fine when you enable the ASIC_PROTOTYPING_FEATURES setting.

(2) With regards to the retime stage runtime- when using ASIC_PROTOTYPING_FEATURES setting, it only marks all registers as non-retimeable but doesn't actually skip retime stage, so seeing some time spent here is expected. The flow is that the retimer will get loaded then exit with a no-op, so it will take a small amount of runtime.

If you are seeing significant amount of runtime at retime stage, we require you to send your design. Because we do not see this problem from our end and there are many factors that can contribute to this- machine environment, qsf settings, etc.

Regards,

Nurina

Thanks for the reply.

As you can see in my shared quartus_prime_pro_22_4_0_run_time_hyper_retimer.zip,

the runtime is the same with ASIC_PROTOTYPING_FEATURES being OFF or ON.

Is that really not possible to add an option to totally skip the hyper retime stage?

I cannot share my design.

Have a nice day,

Alex.

Hi Alex,

We do not have an option to totally skip the hyper retime stage, at most we have options to disable things done at retime stage i.e. register retiming, DSP retiming, etc. This is due to the flow of the Quartus Compilation, it would need to load the retimer for the netlist and timing results optimization.

Based on the *fit.retime.rpt in the shared quartus_prime_pro_22_4_0_run_time_hyper_retimer.zip, you have quite a few critical chains that require to be fixed. When it cannot be optimized by the retimer, this means that the retimer has been exhausted from further retiming- timing violation is very large and you have to optimize them yourself based on the recommendations, usually I would change the RTL code. Once you have fixed the critical chains and reduced the timing violations, the retime stage runtime (and the whole compilation in general) would be able to reduce.

Regards,

Nurina

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.