Forum Discussion

SivaKona's avatar
SivaKona
Icon for Occasional Contributor rankOccasional Contributor
3 years ago
Solved

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

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's avatar
    ak6dn
    3 years ago

    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.

5 Replies

  • ak6dn's avatar
    ak6dn
    Icon for Regular Contributor rankRegular Contributor
    3 years ago

    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's avatar
      ak6dn
      Icon for Regular Contributor rankRegular Contributor
      3 years ago

      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's avatar
    SivaKona
    Icon for Occasional Contributor rankOccasional Contributor
    3 years ago

    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