<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Pavel, You are correct. <style type="text/css">p { margin-bottom: 0.1in; line-height: 120%; }a:link { }</style> Performed a readback of the flashed EEPROM from both upload methods. The resulting .mcs files were converted to binaries to remove the Intel hex file formatting. The cryptech_upload method writes header information that the xilinx file ignores. Offsetting a compare for this shows the files match up to 0x4FFF26. The xilinx file has additional 0xFF padding from 0x4FFF26 – 0x4FFF9E. From 0x500001 on the files are once again identical. <div class="moz-cite-prefix">On 05/10/2018 05:02 AM, Pavel Shatov wrote: </div> <blockquote type="cite" cite="mid:ef8c25b0-e41b-496d-bae9-6916b8dd4462@yandex.ru">06.05.2018 3:37, Michael пишет: <blockquote type="cite"> So I updated ARM firmware. Now either method , Impact using .mcs PROM file or cryptech_upload using the .bit file load the bitstream memory with a file that operates the cores correctly. However I am still unable to prove that both methods create the exact same image. To double check against the checksum difference , I performed a readback with both loading methods and there are significant differences. Is the cryptech method performing some obfuscation method to prevent reverse engineering? I'm really stumped on how to prove the cryptech method for programming the PROM matches the original .bit file..... </blockquote> Hi, Michael, the bitstream itself (partially documented in table 5-19 on page 104 in [1]) has the following structure: 1. FFFFFFFF repeated 8 times 2. 000000BB 3. 11220044 4. FFFFFFFF repeated 2 times 5. AA995566 6. ... The .bit file has some additional information in the beginning (filename, timestamp, etc), I've a attached a screenshot. When iMPACT programs the configuration memory, it skips that garbage, the first thing it writes is those 32 0xFF bytes. If you generate an .mcs file out of a .bit file, you'll see that it starts with 0xFF bytes and that additional data is not included, I've attached a screenshot too. MCS format by the way is in fact Intel HEX, just named differently for some reason. Our script should do exactly what iMPACT does, i.e. strip that header from the .bit file and start writing when it sees 32 0xFF bytes. Maybe there's something like an off-by-one error in the script and it strips more or less bytes than necessary. This will not prevent the FPGA from successfully configuring itself, because when it starts reading the PROM, it discards all the bytes until it sees the bus width autodetect pattern (000000BB, 11220044). If that is actually the case, the checksum will be different when programming with our script and with iMPACT tool, but both methods should work. Another thing to check is how we deal with the last chunk of the bitstream. Configuration memory can only be programmed one page (256 bytes) at a time. It's unlikely that the bitstream length will be a multiple of 256 bytes, so some padding must be done. As far as I know, iMPACT pads the very last page with 0xFF bytes ("unprogrammed" memory contains all 1's), I don't remember exactly how our script does the padding, maybe it pads with 0x00. This will also lead to a different checksum, but successful configuration, because the bitstream has a special "desync" pattern in the end, that tells FPGA to stop reading, so those padding bytes are in fact ignored. I don't have my programmer at hand right now, so I can't reproduce the issue. Should be able to do this on Monday. One thing I can suggest is do a configuration memory readback from iMPACT, this lets you save the actual contents of the PROM into an .mcs file. Then you can compare that to an .mcs file you generated using iMPACT to find the difference. Note that the readback operation reads entire memory and produces a larger file with a lot of 0xFF bytes in the end from the unprogrammed pages, they should be ignored. I think it's good that you noticed the issue. I believe that's more of a cosmetic off-by-one or padding thing, but I mean if it's straightforward to fix, why not fix it? [1] <a class="moz-txt-link-freetext" href="https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf">https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf</a> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ Tech mailing list <a class="moz-txt-link-abbreviated" href="mailto:Tech@cryptech.is">Tech@cryptech.is</a> <a class="moz-txt-link-freetext" href="https://lists.cryptech.is/listinfo/tech">https://lists.cryptech.is/listinfo/tech</a> </pre> </blockquote> </body> </html>