Reproducing the bitwise identical .rpd files in Quartus

[Alpay]

Hello all, 

I have a verified FPGA design with the programming files of .sof, .pof, .jic and .rpd. I have to reproduce the bitwise identical .rpd file by compiling the design in a different PC. 

The original design files were generated by using Quartus Prime Version 18.1.1 Build 646 04/11/2019. Now, I compile the same design with the identical Quartus Version and Build number. Even though settings of fitter and analysis & synthesis are identical, newly generated .rpd file is different than the reference .rpd file. 

I attached the screenshots of the settings that I use in the Quartus.

1- How can I sure that there is no difference in terms of functionality and timing?
2- Is there a way to generate bitwise identical .rpd file?

Thank you in advance.

Regards,
Alpay 

[Kenny_Tan]

Hi Alpay,

You may get the result in https://www.intel.com/content/www/us/en/support/programmable/articles/000084189.html

Thanks,

Best regards,

Kenny Tan

[Kenny_Tan]

Hi Alpay,

You may get the answer here https://www.intel.com/content/www/us/en/support/programmable/articles/000084189.html

Let me know if it does not help?

Thanks,

Best regards,

Kenny Tan

[Alpay]

Hello Kenny,

Thank you very much for your response. I had a look at the link that you provided. Let me try to explain the situation a bit.

I have a verified and released FPGA design in our Version Control Repository which includes all directories created under the project folder. This release was done by my previous colleague using a different PC.

Now, I took reference this release and try to reproduce the identical .rpd file.   

I confirm that: 
1- All design source files including Synopsys Design Constraints (.sdc) files are identical.
2- All Quartus Prime project settings are identical as I shared in my original post.
3- Both compilations were done by using Quartus Prime Version 18.1.1 Build 646 04/11/2019. So,  the version of the Quartus Prime software including patches should be identical.
4- SignalTap™ II Logic Analyzer is not used.
5- Both PCs used in the compilation has Windows 11 OS and 64-bit version of Quartus. 

The only thing that I cannot be sure is the portion of the design that is preserved with the Rapid recompile option or with incremental compilation partitions.

I compiled the design twice in my PC. In one of my compilation, I kept db and incremental_db directories as it is in the repository version. For the second compilation, I deleted db and incremental_db directories before starting compilation. 

Under these conditions, how can I reproduce the identical .rpd file?

Thank you in advance.

Best Regards,
Alpay

[Kenny_Tan]

Below are the things you will need to understand:

db & incremental_db Directories Impact:

If incremental compilation or design preservation features were enabled in the original release, keeping db and incremental_db intact is crucial.

If these directories were not included in the original release, Quartus will regenerate them, potentially leading to different results.

Seed Differences:

If db and incremental_db directories were deleted, Quartus starts with a different initial placement seed, affecting routing and fitting.

File Timestamps & Order in Compilation:

Some versions of Quartus consider metadata such as timestamps, which may cause differences.

Project State in the Repository:

Ensure the repository exactly matches the release state and that no auto-generated files have changed.

Things to check:

Compare .map.rpt and .fit.rpt Reports:

Check if the total logic utilization, routing, and timing results differ between compilations.

If they differ, incremental compilation settings or environmental factors are likely influencing results.

Check for Unintended Changes in the Repository:

Use git diff or another version control tool to compare all files, including metadata.

If you still can't achieve bit-for-bit reproducibility, check if Quartus generates a different .pof file checksum but functionally equivalent results.

Quartus compilation is generally not guaranteed to be fully deterministic without preserved db files.

If an identical .rpd file is critical, consider saving and restoring db and incremental_db directories in future releases.

[Kenny_Tan]

Is there any update?

[Kenny_Tan]

is there any further question?

[Alpay]

Hello,

I am really sorry for the late response. 

Unfortunately, I am still not able to reproduce the bitwise identical files. I checked and observed that Quartus generates a different .pof file checksum but functionally equivalent results.

I also compared .map.rpt and .fit.rpt Reports and observed small differences in the Parallel Compilation. Here are the values that I observed.

As I said in my first entry, Quartus settings and design files are identical. The only thing that I cannot guarantee is db and incremental_db folders. The rest is unchanged. 

To eliminate the effect of db and incremental_db folders, I got the design from repository and compiled it under two different data paths independently, parallel compilation values for two fresh compilations are also different than each other. Do you think if it is related to project settings? In my first entry you can see the settings that I used. Is there any setting that causes undeterministic compilation?

Thank you very much in advance.

Regards,
Alpay

[Kenny_Tan]

Any reason that you cannot use the same db and incremental_db for compilation? Those are just files that you can copy and paste over. In the past, I added this as a criterion to the KDB, as we have had customers who also could not get the same result without retaining these two folders. So, it is natural that this is needed.

These folders store intermediate compilation data, such as placement, routing, and netlist optimizations, which influence the final bitstream. Without these directories, Quartus starts the placement and fitting process from scratch, which can introduce small variations due to non-deterministic task scheduling, fitter seed changes, or parallel compilation differences.

In any case, here are some additional things that you can try, but no guarantee since your db and incremental db is not preserved.

1. Parallel Compilation and Task Scheduling

You observed differences in the parallel compilation values in the .map.rpt and .fit.rpt reports. This suggests that task scheduling in parallel compilation could be causing the variation.

• Potential Root Cause:
• The Quartus compiler, when parallel compilation is enabled, assigns tasks to different processors dynamically, which can change the order of resource allocation and affect placement, routing, and final bitstream.
• Solution:
• Disable parallel compilation to eliminate task scheduling differences:
• In GUI:
  • Go to Assignments → Settings → Compiler Settings → Parallel Compilation and uncheck the box.
• In .qsf:
  • Add the following:  set_global_assignment -name NUM_PARALLEL_PROCESSORS 1
  • Recompile the project and check if the .pof and .rpd files match more closely.

2. File Timestamps and Environmental Differences

Some versions of Quartus may embed metadata (e.g., compile timestamps, hostname, file paths) into output files, causing bitstream differences even with functionally identical logic.

• Solution:
  • Inspect the differences in the .pof or .rpd files using a hex editor:

xxd file1.pof > file1_hex.txt

xxd file2.pof > file2_hex.txt

diff file1_hex.txt file2_hex.txt

If the differences are limited to header metadata (e.g., timestamps, path strings), you may ignore them if functional verification (timing, logic) passes.

[Kenny_Tan]

Any further queries on this?

[Kenny_Tan]

Is there any further queries on this? If no, we shall close this case.

[Kenny_Tan]

As we do not receive any response from you on the previous answer that we have provided. Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, 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.