Forum Discussion

loukik's avatar
loukik
Icon for New Contributor rankNew Contributor
9 months ago

Understanding the Last Two Bytes in a Quartus POF File

Hello,

I am analyzing .pof files generated for an Intel MAX 10 FPGA and noticed that the last two bytes change with every iteration. These bytes do not match the checksum from the .map file, nor do they follow a simple bitwise or arithmetic pattern.

I have tried:
1)Checking if they are a checksum → No direct match.
2)Bitwise operations (XOR, AND, OR, shifts) → No clear correlation.
3)Arithmetic patterns (modulus, addition, iteration-based shifts) → No match.

Could you please clarify:

  1. What does the last two bytes in the POF file represent?

  2. How are these bytes computed for each iteration?

  3. Is there a reference in Quartus documentation for this?

    Any insights would be greatly appreciated!
    Thanks.

Simulation

5 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    9 months ago

    I doubt you're going to get answers to these questions. What are you hoping to accomplish?

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    9 months ago

    There is no public information or support available on this.

    Are you facing any issues with the .pof file? May I know the reason for your inquiry?

    Regards,

    Richard Tan

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    9 months ago

    Hi,
    as stated, there's no publically available Altera/Intel documentation of POF format. The only doc that I ever saw was published by a third party programmer manufacturer.

    It states about tag=8 Terminator packet:

    This packet signals the end of packet list in the POF. This packet must be the Nth packet, where N is the packet count declared in the POF header. The CRC field is a 16-bit Cyclic Redundancy Check computed on all bytes in the file up to, but not including, the CRC values itself. If this CRC value is zero, the CRC check should be ignored.

    Sounds reasonable, however I didn't check if the decription is still valid for recent POF files, e.g. MAX10. I guess it is.

    Regards
    Frank

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    9 months ago

    Since the information is not available publicly/ not supported, I will transitioning this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out. 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.


    Thank you and have a great day!


    Best Regards,

    Richard Tan



  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    9 months ago

    FYI:

    The last two bytes stores the CRC16 value of the POF file.

    This value is different from the checksum of the .map file.

    The CRC16 value is computed by calculating the CRC16 of the POF file data minus the last two bytes.

    Furthermore, the CRC16 value is not flash into the FPGA.
    It's used by the Quartus Programmer to check the integrity of the file.
    The data content that actually flash into the FPGA is only partial of the POF file and is in proprietary format.
    The format doesn't support customer to insert the checksum.

    Regards,

    Richard Tan