Forum Discussion
Thanks Frank. I noticed there are 2 checksums shown in the programmer, "checksum" and "usercode". When I converted my SOF file into RPD and MAP files, I was able to open the RPD file in a hex editor and locate the UFM section. It was all FFs. I had inserted some customized data into this section with the hex editor, and used the same tool to repack a new POF file, which now contains the customized UFM data and the original CFM and ICB data.
Comparing the original POF to the repacked POF, I don't directly see my customized data in there. (It may be encoded differently or compressed or something, and POF file format is not publicly specified, I understand.). When I load each POF file into the programmer, the "Checksum" is different, consistent with what you are describing. However, the "Usercode" checksum, is still the same, leading me to believe that it applies specifically for the CFM data and not the POF file as a whole. So this is the actual reason why I focused on the usercode checksum; it can remain the same despite different POF file when repacked differently.
So my goal is to understand how the "usercode" checksum works, should that be documented somewhere or if someone knows.
Hello,
There might be some confusion here:
Checksum : configuration data checksum, reflect the contents that actually downloaded/configured into CFM. Any changes to the bitstream will change checksum. Usage to detect corruption or mismatch in configuration data.
Usercode : it is NOT the checksum of the POF file. Quartus may default it to something static or left constant. Usercode remains identical is expected behavior. Usage to version tagging/design identification/JTAG bases system identification.
regards,
Farabi