FPGA development instantiation, how to get access

Partial reconfiguration involves downloading configuration data to a running system. Although some protection measures, such as device IDs, are built into the chip and bitstream to ensure that the correct part is identified, there are still some technologies that need to be understood and implemented as part of the user's design. Designers should follow these recommendations to ensure some of the reconfigurable safety and predictability.

• Some active programs within the reconfigurable partition (RP) need to be shut down before the reconfiguration operation. If the reconfigurable function does not perform a complete transfer or does not reply to the most recent request, the entire system may hang .

Solution: In your design, make sure that all activities in the RP partition are completed before reconfiguration. In the design, a request-notification handshake operation is implemented in each partition so that the system does not hang, and the information does not Will be lost.

• Isolate RP partitions so that any dynamic changes do not have any negative impact on static design. It is not yet possible to predict how the RP partition will behave in a dynamic configuration if some of the floating signals escape the RP partition. Going out, then some false events will have a negative impact on static design.

Solution: The best solution is to disconnect the partition from the static design until the reconfigurable operation is complete. The PR Controller IP can be used to isolate the RP partition by strobing any interface port, or a custom logic module (2 Select 1 multiplexer, register with reset or enable gating, etc. can all achieve this function.

• If part of the bitstream file must be passed to the remote system, it may be corrupted during the transmission. If the corrupted part of the bitstream is sent to the configuration engine, the static design part may be affected, and the standard at the end of the bitstream The CRC check is not complete, because all the configuration data has been sent before the check operation.

Solution: Each frame of some bitstream files can be detected using CRC, so bad frames can be detected before they can be loaded into configuration memory, and then we can take corrective or fallback operations. The CRC check is enabled at each route design checkpoint. The start command is as follows: set_property bitstream.general.perFrameCRC yes [current_design]

However, the most critical detail is to ensure absolutely that part of the bit stream sent to the FPGA or SoC can be compatible with the static design so that it can be configured into the device. Part of the reconfigurable design flow needs to lock the static implementation part and all can be reloaded. The configuration module must be implemented in this context. If the static design changes, then all the bit streams created using this static design will fail and need to be recompiled because many aspects of partial bitstream content have changed - Clocks, partition pins, static routes, etc. may all be different. This conservative method has certain flexibility and improves overall design performance, but it must follow a master-slave relationship.

The designer must implement a version check scheme to ensure that only the matching bit stream can be loaded into the static design system. There are many implementations, on-chip/off-chip, hardware/software, and so on. Either way, the version of the bitstream file will be checked against the version of the static design section before the partial bitstream file is sent to the configuration port.

A convenient way to perform this check in the FPGA fabric is to use the USR_ACCESS module, which holds a 32-bit register in a dedicated configuration space, but is accessible through the FPGA, just to make the USR_ACCESSE2 module available in your RTL design. Instantiate access to access this feature by connecting a 32-bit data bus.

The value of this constant register is set by the following command: set_property BITSTREAM.CONFIG.USR_ACCESS 0x<8-digit-hex>|TIMESTAMP [current_design]

Although we can use the TIMESTAMP option, it may be easier to create custom register values ​​by loading all bit file information. The value of TIMESTAMP is calculated on the fly, so when applying to some bit files you need to read the Vivado tool for static part of the calculation. The value of

Once the design is connected to this element, you can use a 32-bit value to match part of the bitstream file. This value is stored in the full bitstream file for the given attribute above, because it was written during device initialization configuration, however The bitstream file does not contain this value because it does not reprogram the USR_ACCESS register. You need to add custom header information to each partial bitstream. This header should contain this value for version checking of the static design part. The simplest comparison match is to set the error flag. This is necessary if a failure is detected. Once a mismatched system is detected, it needs to determine what to do next.

When creating a new version of a static design you need to update the value of USR_ACCESS. This includes not only the static design part but also a series of partial bitstream files that match this static design version. The USR_ACCESS module has two characteristics that make it ideal for this use. select:

1. Because it is a dedicated module for configuration applications, it does not use any standard CLB or BRAM resources, leaving more resources available for your design.

2. Since this value is set by attributes, it can be inserted after all placement and routing are completed, and it is no longer necessary to re-synthesize or implement when re-inserting new values.

It is only necessary to apply the new BITSTREAM.CONFIG.USR_ACCESS to the full design version check before writing the complete bitstream data. Any older bitstream files will be rejected during the version check to ensure that they match the hardware.

For more information on USR_ACCESS, see the XAPP1231 documentation.

Summary The use of version identification checks and other security mechanisms in some reconfigurable designs ensures a safe and reliable work environment.

We hope to hear from you! Participate in some of the reconfigurable surveys (please click "read the original" online participation) to provide feedback on this solution to help us improve.

David Dye is a senior product marketing manager for the hierarchical design process. His responsibilities include product planning, partial reconfigurable marketing, serial configuration and related design processes, such as module analysis and team design. He has more than 20 years of industry experience at Xilinx and during his tenure supported the development of various ISE and Vivado design tools, from synthesis to implementation to debugging. David holds a degree in electrical engineering from Carnegie Mellon University.