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

[AEsqu]

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

I'm asking because Quartus is not able to apply it on my design, hence I want to skip it to save run time (stratix 10, Quartus 21.1).

Messages from Quartus:

Info(16607): Fitter routing operations ending: elapsed time is 00:40:14
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.
Info(18821): Fitter Hyper-Retimer operations ending: elapsed time is 00:35:37

Thanks,

Alex.

[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

[AEsqu]

Hi Nurina,

I'm running 2 Quartus jobs with the option ON and OFF for you to compare.

I can already see in the stratix10_fpga_a_mix.flow.rpt that the option is picked:

+----------------------------------------------------------------------
; Flow Non-Default Global Settings                                     
+---------------------------------------+------------+-----------------
; Assignment Name                       ; Value      ; Default Value   
+---------------------------------------+------------+-----------------
; ALLOW_REGISTER_RETIMING               ; Off        ; On              
; ASIC_PROTOTYPING_FEATURES             ; On         ; Off             
; ASIC_PROTOTYPING_LATCH_SUPPORT        ; On         ; Off             
; ASIC_PROTOTYPING_READBACK_WRITEBACK   ; On         ; Off             

I will send by email the reports and .qsf

[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

[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

[AEsqu]

Hopefully they can fix it in next Quartus release.

Have a nice day.

Aggressive Compile Time is not an option, too bad timings.

[Nurina]

Alex,

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

Regards,

Nurina

[AEsqu]

Hi Nurina,

Let's keep it open till a new version of Quartus fixes it,

Alex.

[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

[AEsqu]

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.

[Nurina]

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.

[Nurina]

Hello Alex,

Just to clarify, right now the info messages regarding the hyper-retimer I mentioned above are always generated, it doesn't matter whether or not timing has been met by retimer.

Therefore, please refer to the retimer reports for the correct details. It would mention if the retimer has optimized the timing based on the clock domains.

Regards,

Nurina

[AEsqu]

Let's close the discussion then as the retimer has to run everytime.

[Nurina]

Hello Alex,

Since I've addressed your question, 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.

Have a great day.

Best regards,

Nurina