Forum Discussion
Occasional ContributorDoes Checksum differ for two SOF files generated with same RTL and same seed
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.
Regular ContributorIn 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.
Regular ContributorOk, 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.
