08-13-2019 01:15 PM - edited 08-13-2019 01:20 PM
I am unable to fully understand or access the ICAP configuration registers containing CRC data. These registers are accessed with the following addresses (IDCODE register provided for reference):
There is no mention of the CRC registers in UG470 but their existence appears to be proven by viewing the SIM_CONFIGE2.vhd file included with a Vivado installation.
I am able to use the ICAPE2 primitive correctly and access the IDCODE register. The word read out from this register matches the IDCODE of our device as we expect.
I am unable to use the ICAPE2 primitive to read any of the CRC registers. When I expect the data in the same fashion as IDCODE data is read, I receive all zeroes on the data output.
My question is, how do these CRC registers become populated? Are they actually accessible via the ICAPE2 primitive? What information is contained in them? Furthermore, are their contents affected by property and bitstream settings such as:
set_property bitstream.general.crc enable/disable [current_design]
set_property POST_CRC enable/disable [current_design]
set_property POST_CRC_SOURCE pre_computed/first_readback [current_design]?
Thank you for your help.
08-14-2019 07:45 AM
Please provide your FPGA device details.
How reading CRC can help your application/Project?
08-14-2019 07:53 AM
Thank you for responding @bpatil,
The FPGA we are targeting is a 7-series device. This specifically is a Spartan 7S50.
Capturing the device bitstream CRC will help to verify the correct version of our design is installed on target hardware.
Do you have any details on the function and use of these three CRC configuration registers?
08-14-2019 08:11 AM
The bitstream when created has a CRC to check it gets read in correctly (DONE will not go high if this CRC is wrong).
Once loaded, if enabled, the device calculates a golden CRC that is used to tell if an upset (fault, or attack) happens. This is used by the logic that pulls INIT_b low if flipped: RBCRC, and also by the SEM IP core.
So, if you wish to know if the bitstream loaded correctly, did DONE go high?
If you wish to know if at any time an upset occurs, set it for RBCRC scans and asserts INIT_b, or better, use the SEM IP to find, fix (and notify).
08-14-2019 08:29 AM
Thank you for your response, L.E.O.
I am handling SEUs separately from this operation. Additionally, my intent isn't to understand if the device golden CRC and calculated CRC match. If they don't match then the device is configured to not boot similar to your description.
My intent is to read the device bitstream CRC during runtime (i.e. after boot). Being in runtime necessarily precludes a CRC mismatch having happened. I identified these three CRC registers, accessible with the ICAP, as perhaps holding that bitstream CRC value.
I can see in a bitstream .bit file where a CRC value is placed, both early in the .bit file and late in the .bit file. I am trying to find a solution that doesn't involve fetching that value from our flash device during runtime.
My question remains; what are these three CRC registers? How are they populated? Are they accessible with the ICAP?
08-14-2019 09:01 AM
The three CRC will not match. They represent different things. The bitstream is a data file. It is static. The RBCRC is all the static CRAM bits (it ignores BRAM, SRL, LUTRAM, anything dynamic). Sure, you can figure it all out yourself, but why bother? Just use what is provided for free.
I strongly caution you from attempting your own SEU monitor -- the SEM IP is beam tested, extremely well characterized.To get to this point, the SEM IP has gone through > 10 years of releases, fixes. Why suffer discovering all the foibles of trying to do it yourself
08-14-2019 09:50 AM
I was thinking they likely would not match - in fact, I was thinking that RBCRC_HW was the hardware-generated golden CRC, RBCRC_SW was another form of a "golden" CRC, and that CRC_LIVE is a user-enabled generated CRC probably from the RBCRC mechanism.
Thank you for your caution - the SEM IP is absolutely under consideration for our SEU mitigation approach.
My original, still unanswered, question has no concern with the SEM IP or SEU mitigation. I want to read out the bitstream "golden" crc with the ICAP and I found these registers. As I said before, trying to read the registers only provides zeroes. I am trying to find out what the registers are for, what populates them, and if I can read their values with the ICAP post-configuration.
08-14-2019 10:33 AM
I believe it is internal to the configuration manager and is not observable. Xilinx prefers not to tell you what you do not really need to know. If you wish to get to that level of detail, you will have to convince them to spend the time (money). I know their answer will be what I advised you (that is why I invented the SEM IP 15 years ago while at Xilinx -- lessen the support costs by doing what was needed, and guaranteeing it).
08-14-2019 11:23 AM
The reason we need to know the CRC is that this project will be certified to a particular standard and there are requirements for design assurance, programming assurance, and identification. In a past certified project an Intel/Altera FPGA was used that allowed for a primitive to be instantiated that gave direct access to the device-calculated CRAM CRC. This CRC in conjunction with the reported digital version are used to verify a programming update was successful.
For this reason we would like to see the CRAM CRC. These registers seemed like candidates to get that computed CRC value.
Pretty neat that you are the SEM IP designer - cool!
08-14-2019 12:57 PM
So, I would ask that exactly to Xilinx (or your Xilinx authorized distributor). Given Altera/Intel does not allow readback (interface is proprietary), their only choice was to make their registers visible (and for you to believe them). As Xilinx is open for the bitstream, one can examine it at any time. Another approach is to use the encryption (AES) and authentication (SHA256). That, and the SEM IP guarantees what you put in is exactly what you are running.
You do not have to write any code, or use anything untested or unproven.
08-15-2019 08:25 AM
Thank you for your input. It is sounding like there is not a user-accessible register (at least one whos accessibility is publicly available info) containing the golden CRC similar to Intel parts; that is useful to know. We would need to do readback and CRC calculation ourselves for that.
Thank you as well for trying to answer my question as to what the three CRC registers I identified are for. Unless there is a Xilinx employee forum user who would like to enlighten more on their purpose, how they are populated, and their accessibility. I'm guessing the registers are reset to zero following successful configuration.
08-15-2019 01:46 PM
08-16-2019 10:13 AM - edited 08-16-2019 10:40 AM
Thank you for the link - the blog post is helpful in understanding the CRC constraints and properties more clearly.
Can you shed any light on the three CRC registers I asked about in the original post - RBCRC_HW, RBCRC_SW, and RBCRC_LIVE - that are apparently accessible via the ICAP interface? As in, how are they populated? What information do they actually represent? Are actually accessible with the ICAP?
08-16-2019 10:58 AM