Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
FPGAs have a reset signal that is spread across through the global routing. If the user logic needs to carry out a system reset for whatever reason, how should this be done?
Can the user logic actually drive the reset signal from itself which is ANDed with the reset coming from outside the FPGA? If so, what will happen with the routing resource usage?
Is there another way e.g induce the FPGA to reconfigure itself somehow like it does just after power-up?
For Xilinx devices at least, the answers to your questions are all in Xilinx UG470 and UG953.
https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug953-vivado-7series-libraries.pdf
FPGAs have a reset signal that is spread across through the global routing.
That's correct.
If the user logic needs to carry out a system reset for whatever reason, how should this be done?
It depends on what FPGA architecture you are using. For Xilinx parts pulsing the PROGRAM_B signal causes the part to reconfigure.
You could physically put an AND gate on the board and tie one input to an external reset, and tie the other input to a GPIO pin. The GPIO pin needs a pullup resistor on it.
You can use the IPROG command on the ICAPE2 primitive as documented in UG470 Table 5-19.
Can the user logic actually drive the reset signal from itself which is ANDed with the reset coming from outside the FPGA?
Yes, using the IPROG command. Or alternatively if you just want to reset the flip-flops without reloading the bitstream you can use the GSR pin on the STARTUPE2 primitive.
If so, what will happen with the routing resource usage?
Nothing. There is a dedicated global reset line in the FPGA, so additional routes are not needed.
Is there another way e.g induce the FPGA to reconfigure itself somehow like it does just after power-up?
Pulsing PROGRAM_B (by whatever method) causes a complete reconfiguration of the device.
This no longer true on many modern FPGAs. Reset signals can be routed with large fanout signals like clocks, but many FPGAs don't have a dedicated reset circuit for this.
When I'm working with FPGAs I am very careful to only use reset signals when strictly necessary. If you're working with a state machine for example, you might just reset the state. Once it is in the correct state, the normal state machine operation will set all the outputs, so they don't necessarily need to be reset. It might take a few clock ticks to get to a totally known state, but that is alright.
Do you want to reset the design, or the entire device?
Resetting the design is usually what you want to do. However, there are certainly applications for triggering a reset of the entire device. If you reset the design, in general there are things that cannot be reset (RAM contents, etc.), and you can reduce resource utilization by selectively resetting only the components that actually need to be reset, such as data bus valid signals (1 or 2 bits) and not the data bus itself (8, 32, 64, etc. bits). You can trigger a reset however you like, such as from an FPGA IO pin, the locked output of internal PLLs, etc. The tools in some cases will use a global clock net for routing high-fanout reset signals.
Resetting the whole device will trigger the device to reload the configuration. This only works if there is a flash device that the FPGA can read the configuration from, otherwise it after it is reset the device will sit idle waiting for a configuration to be loaded. Resetting the whole device will reload RAM contents and what not from the configuration bitstream. Triggering a whole-device reset is highly device dependent. One method is to externally connect an FPGA IO pin to the dedicated FPGA reset pin. Alternatively, there are usually ways to trigger a device reset without any external connections. For Xilinx devices, this generally means using an ICAP primitive to talk to the FPGA configuration logic and provide an IPROG command to trigger a device reset and reconfiguration. Note that it also can take a significant amount of time to read the configuration data from flash, so triggering a whole-device reset means the device will be out of commission of many milliseconds.
