Does Checksum differ for two SOF files generated with same RTL and same seed

[SivaKona]

Hi,

Does Checksum differ for two SOF files generated with same RTL and same seed?

If it differs, what is the reason for this difference?

What stages of Quartus compilation does a seed control?

Thanks & Regards

Siva Kona

[ak6dn]

In my .qsf file, I set the SEED for my design compilation to a fixed number (42 in my case, chosen at random).

I can delete all the generated files in the design directory, and rerun the full Quartus design map/fit/assemble over and over.

It always generates the EXACT same .sof file, bit for bit.

The Quartus manual says the 'seed' value affects the 'fitter' stage.

Makes sense, if the RTL is fixed, the 'mapping' should not change.

If the 'fitter' result is the same, the 'assemble' result should not change.

[ak6dn · Accepted solution]

Ok, so have to modify my answer a bit.

I am using Quartus Web 13.0sp1 on a Win10 platform.

So if I delete all the generated design files, and rerun the the compilation from scratch, a SOF with a different CRC32 is built each time.

If I just 'remake' the design by recompiling without deleting the existing design database files, a SOF with the same CRC32 is built each time.

But, in all instances, the final POF/JIC files I use, that are built from the SOF, ALWAYS have the same CRC32 value after each recompile.

And of course if I do a verify of an existing programmed part using the JIC file vs EEPROM contents, it matches 100%.

So it looks like there may be some data within a SOF that may vary from compile to compile, but it is not included when the JIC is built.

Just my observation, I have no inside knowledge other than being a user.

So comparing POF or JIC file CRC32s seems ok, but the CRC32 of the SOF is not.

[SivaKona]

Hi, 

Thanks for your inputs.

I have run two SOF build runs consecutively one  after the other with same seed ( set_global_assignment -name SEED 16)  and with no changes in RTL.

I could NOT compare the .sof files. Instead, I have compared the checksums of .sof files and the checksum values are different.

CTH-ip-gyann> md5sum e1_gyann_fpga_top_s10/quartus/par_results/gyann_fpga_top_demo1.sof
c3405c1e3ab219c1edd5bd168cb45c70 e1_gyann_fpga_top_s10/quartus/par_results/gyann_fpga_top_demo1.sof
CTH-ip-gyann> md5sum e2_gyann_fpga_top_s10/quartus/par_results/gyann_fpga_top_demo1.sof
df42a66fbcd44459e55aa9fe4466bfe0 e2_gyann_fpga_top_s10/quartus/par_results/gyann_fpga_top_demo1.sof

Except Time stamp, elapsed time and System Process Id,  everything else matches in all fit and asm reports. But we see the checksums mismatch between sof files .

Could you please share your thoughts on this ?

Regards

Siva Kona

[SivaKona]

Thanks for the inputs.

Following link also confirms that Checksum is not same on the sof file as it contain timestamp information.

https://www.intel.com/content/www/us/en/support/programmable/articles/000080266.html

Resolution To ensure the designs are identical, perform an MD5 checksum or diff on the Programmer Object File (.pof) or the Raw Binary File (.rbf) which does not contain timestamp info.

Regards

Siva Kona

[Ash_R_Intel]

Hi,

This is a known behavior of Quartus. Please check below KDB article:

Why does the Intel® Quartus® Prime Standard Edition...

Regards