09-18-2018 02:27 PM
I am using an XC7A35T FPGA connected to a TMS320F28335 DSP.
Is there any way to store the bit stream CRC in the FPGA and then read it using the DSP?
I would like to generate a new firmware version number for each build, store the version number in the FPGA and then read it using the microcontroller. How would I do that.
09-18-2018 05:36 PM
Welcome to the Xilinx Forum!
Is there any way to store the bit stream CRC in the FPGA and then read it using the DSP?
The Xilinx IP called the Soft Error Mitigation (SEM) Controller described by document, PG036, remembers the bitstream CRC. While the FPGA is running, the SEM IP works in the background and uses the bitstream CRC to continuously check whether the loaded FPGA configuration has been corrupted by ionizing radiation ( hate it when that happens 😊 ). Your DSP can talk with the SEM using one of the serial interfaces described in PG036 – and perhaps(?) there is a command to request the bitstream CRC.
I would like to generate a new firmware version number for each build, store the version number in the FPGA and then read it using the microcontroller.
We do this by storing the firmware ID as a hard-coded constant in our VHDL. Our VHDL also implements a serial interface that allows us to exchange simple commands with the FPGA. One of these simple commands instructs the FPGA to reply with the hard-coded firmware ID. Again, your DSP could talk to the FPGA via such a serial interface.
09-19-2018 02:30 PM
Where on the device that I am using (XC7A35T-1FGG484I) is the shim mon output located? Is that the interface I can use to access the CRC?
Also, can I access the CRC using vivado and the JTAG interface?
09-19-2018 05:06 PM
The post <here> indicates that attempting to find/read the bitstream CRC is considered “bitstream hacking” and is not something we should be doing.
Why do you want to read the bitstream CRC? Are planning to use it as a firmware ID number? If so, then I think it is much better to create your own firmware ID number and embed it into your HDL code.
09-20-2018 06:54 AM
I am not trying to hack any bitstream. I just want to get the firmware CRC.
The CRC uniquely identifies the firmware, and I trust a CRC more than a firmware ID/Version #.
The user of our application is able to view the Microcontroller CRC on a display. I would like to have the display also show the FPGA firmware CRC.
How do I get the CRC that was generated from the build process? My aim is to embed the CRC in the FPGA firmware by using a tcl script to auto-generate FPGA code.
10-26-2018 06:34 AM - edited 10-26-2018 06:48 AM
My original post was kind of confusing. Also, I am a confused about all the terminology.
My purpose is to determine with absolute certainty the version of firmware stored in the Configuration flash memory? I believe the CRC is the only way to do this. The firmware version number is not a good way to determine the exact firmware stored in Configuration flash memory since it can be easily changed independently of the rest of the firmware.
My application has a display that communicates to another board containing a micro-controller and an FPGA. The hardware for our application is already completed, so I can't easily change any connections between the microcontroller and the FPGA.
I would like to show the FPGA firmware CRC on the display. If that is not possible, I would like to read the CRC from the configuration memory using the Vivado IDE or some other simpler application that works independently of Vivado.
What is the best way to do this?
10-28-2018 05:08 AM
This is not the answer you want but you might take a look at :
10-28-2018 07:58 PM - edited 10-28-2018 08:00 PM
First of all, to read out a CRC value you instantiate SEM IP in the design， that makes no sense.
You can use almost all the Config interface to read out the value stored in CRC register, check the Configuration user guide, read the chapter talking about Config Packets and Config regs, you can then use commands to get the reg value out.
Finally, if you plan to get out the CRC value right after bitstream is generated, search the bitstream for command '3000 0001', the 32-bit number after this command is the CRC value. You will find two of them as Xilinx checks CRC twice. Use either one depends on your needs.
10-29-2018 05:59 AM
Ok, that is interesting. I don't currently fully understand how it all works, but it looks like it can be used for versioning.. I'll get back with you in the future with more questions if necessary.
10-29-2018 06:10 AM
What is a Config interface?
How would I do one of the following (In order of preference):
1. Read the CRC using the microcontroller that is attached to FPGA.
2. Read the CRC from the FPGA using small application created by me.
2. Read the CRC from FPGA using the Vivado IDE.
The purpose of reading the CRC is to verify the correct version of FPGA code is store in configuration flash. That is the only way to truly be sure which version of FPGA code is stored in configuration flash.
10-30-2018 11:59 AM - edited 10-30-2018 01:31 PM
I haven't written any commands to the FPGA JTAG config interface. What document describes what commands are available and how to write the commands using the vivado IDE?
Also, I searched the mcs file for the 30000001 and a quite few of them showed up in the search. How can I determine the correct one to use?
10-31-2018 10:22 AM - edited 10-31-2018 10:23 AM
Since a Xilinx employee (Ivy) has joined our conversion, I guess it's OK to talk about bitstream details (ie. we are not considered bitstream hackers).
Ivy is the expert and you can learn things from reading her old posts to the Forum (especially <this> one and <this> one). However, I thought I’d offer a few comments since you still seem to be looking for answers.
From reading UG470 (v20Aug18), it seems that the Artix-7 FPGA uses the CRC in the following way. On page 90 it says, “As the configuration data frames are loaded, the device calculates a Cyclic Redundancy Check (CRC) value from the configuration data packets. After the configuration data frames are loaded, the configuration bitstream can issue a Check CRC instruction to the device, followed by an expected CRC value. If the CRC value calculated by the device does not match the expected CRC value in the bitstream, the device pulls INIT_B Low and aborts configuration.” More specifically (from Table 5-19), the bitstream seems to send a value to the FPGA’s CRC register whereupon the CRC check is done.
BTW – there appears to be an error in Table 5-19 which says that the Packet Header, hex(3002 6001), causes “Write CRC Register”. However, as Ivy and Table 5-20 indicate, the “Write CRC Register” Packet Header is hex(3000 0001).
Also, as you found and Ivy says, the CRC check is done multiple times during bitstream loading. So, the CRC register is written multiple times. I’m not sure why this is done. However, it seems that a full-bitstream CRC check must come towards the end of bitstream loading since that is when the FPGA has completed its own calculation of the full-bitstream CRC value. However, I’m not sure we can assume that this full-bitstream CRC check is the very last check done. Likewise, I’m not sure we can assume that the final value found in the FPGA CRC register is the full-bistream CRC value.
I cannot find that the full-bitstream CRC value is stored anywhere else in the FPGA except in the CRC register. Nor can I find whether the CRC register contents are preserved after bitstream loading is complete. However, the SEM feature that I mentioned earlier must be saving the CRC value because it continually uses it to check for corruption of the FPGA configuration. That is why I guessed that SEM may allow you to readback the CRC value. However, you saw Ivy’s comment that this “makes no sense”.
My point is this. Even if you found a way to read the FPGA CRC register then I’m not sure it will contain the value that you want – since we can’t be sure that the last value written to this register is the one you want.
Probably, your best bet is to intercept the bitstream (somehow) with your DSP and search it for all instances of the Packet Header, hex(3000 0001), and pick the one you want (as Ivy says). The one you want (ie. the full-bitstream CRC value) is probably located near the end of the bitstream and can probably be identified by doing some testing. That is, generate a bunch of bitstreams for the FPGA, each time changing the RTL code a little. Then study the CRC values stored in the bitstream. Maybe some are changing and some are not – and this might help you pick the one you want.
10-31-2018 04:36 PM
-or, forget about the Xilinx computed CRC value for the bitstream. Instead, intercept the bitstream with your DSP, compute a CRC value any way you want, and use that as ID for the FPGA firmware.
10-31-2018 10:15 PM
Agree with Mark.
If the sole purpose of CRC reading was for tracking revision of the bit file, i would suggest to use a more simpler solution.
Xapp497 could be the simplest solution
Assume you have an I2C connectivity b/w FPGA & Microcontroller, you can forward the USR_ACCESS register value via the I2C link to FPGA, doesn't this approach work for you ?
11-01-2018 08:56 AM - edited 11-01-2018 09:06 AM
I want the CRC to be statically stored in the FPGA. A user should be able to verify the FPGA contains the correct firmware by reading the CRC.
Will the USERCODE register keep its value during a power cycle?
What FPGA pins are used to set I2C connectivity between the micro and FPGA?
11-01-2018 05:57 PM
I don’t think that any Xilinx FPGAs is able to store the bitstream or any part of the bitstream in onboard nonvolatile memory. That is, the bitstream is stored in external nonvolatile memory – usually flash memory – and then loaded into the FPGA at power-up. So, if you are going to do something with the bitstream, then read it from the nonvolatile memory where it is stored rather than waiting until it has been loaded into the FPGA to read it from the FPGA.
11-02-2018 05:48 AM
The microcontroller is not connected to the Configuration Flash memory.
How do I read the CRC from the Configuration flash memory using Vivado?
11-02-2018 09:03 AM
Chapter 6 of UG908 describes how to readback the bitstream from Configuration Memory using Vivado and the readback_hw_cfgmem command via the JTAG port.
Chapter 6 of UG908 (see readback_hw_device) and Chapter 6 of UG470 show you had to readback the FPGA configuration memory via the JTAG port. I suspect that the Xilinx-computed CRC will not be found in this readback data. However, if you are going to compute your own CRC value, then this kind of readback may be an option for you.