cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
1,830 Views
Registered: ‎09-18-2018

Artix7: Use microcontroller to read FPGA Configuration CRC

Hello,

 

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.

 

Thanks.

Stephen 

0 Kudos
17 Replies
Highlighted
1,807 Views
Registered: ‎01-22-2015

Hi Stephen,

 

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.

 

Cheers,

Mark

 

Highlighted
Participant
Participant
1,784 Views
Registered: ‎09-18-2018

Thanks Mark.

 

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?

 

Thanks,
Stephen

0 Kudos
Highlighted
1,776 Views
Registered: ‎01-22-2015

@shall785

 

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. 

 

Mark

0 Kudos
Highlighted
Participant
Participant
1,764 Views
Registered: ‎09-18-2018

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.

 

 

0 Kudos
Highlighted
Participant
Participant
1,627 Views
Registered: ‎09-18-2018

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?

 

Stephen

 

 

Tags (1)
0 Kudos
Highlighted
1,587 Views
Registered: ‎01-22-2015

Tags (1)
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,576 Views
Registered: ‎08-10-2008

Hi Guys,

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.

Ivy

------------------------------------------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Participant
Participant
1,560 Views
Registered: ‎09-18-2018

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.

 

Thanks,

Stephen

0 Kudos
Highlighted
Participant
Participant
1,557 Views
Registered: ‎09-18-2018

Hello Ivy,

 

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.

 

Thanks,
Stephen

0 Kudos
Highlighted
Participant
Participant
1,542 Views
Registered: ‎09-18-2018

Hello Ivy,

 

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?

 

Stephen

0 Kudos
Highlighted
1,523 Views
Registered: ‎01-22-2015

@shall785

 

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.

 

Good Luck,

Mark

Highlighted
1,511 Views
Registered: ‎01-22-2015

@shall785

 

-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.

 

Mark

 

Highlighted
Xilinx Employee
Xilinx Employee
1,503 Views
Registered: ‎01-10-2012

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

https://www.xilinx.com/support/documentation/application_notes/xapp497_usr_access.pdf

 

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 ?

Tags (2)
0 Kudos
Highlighted
Participant
Participant
1,494 Views
Registered: ‎09-18-2018

Hello Gurupra,

 

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? 

 

Thanks,
Stephen

0 Kudos
Highlighted
1,481 Views
Registered: ‎01-22-2015

@shall785

 

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.

 

0 Kudos
Highlighted
Participant
Participant
1,472 Views
Registered: ‎09-18-2018

The microcontroller is not connected to the Configuration Flash memory. 

 

How do I read the CRC from the Configuration flash memory using Vivado?

0 Kudos
Highlighted
1,465 Views
Registered: ‎01-22-2015

@shall785

 

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.

0 Kudos