06-07-2017 07:24 AM
My design has asynchronous reset requirement (which is synchronously de-asserted inside the FPGA). The design also uses DSP48 and BRAM blocks which don't like the asynchronous reset and vivado issues DRC warnings suggesting to use synchronous reset for these blocks. I can either not reset the input and output registers connected to these block or synchronously reset these registers (the same async reset used across the other modules). Could someone suggest the best way to handle the reset and the impact of these options?
06-07-2017 07:53 AM
The question you may want to ask yourself is "do my modules really need a reset?".
Xilinx devices have a dedicated global set/reset signal (GSR). This signal sets the initial value of all sequential cells in hardware at the end of device configuration. Usually it is enough to remove a lot of resets signals.
I would recommend you to go through the "Control Signals and Control Sets" of the UG949 - UltraFast Design Methodology Guide for the Vivado Design Suite.
06-07-2017 08:07 AM
Florent, Yes, the reset is very much needed in our design per the safety standards set by the company and the code might be targeted to different FPGA/ASIC at later point. So, I don't want to deviate from that.
06-07-2017 08:22 AM
Then you can have a look to the Processor System Reset Module IP to generate a synchronous reset from an asynchronous.
06-07-2017 09:07 AM - edited 08-15-2019 08:14 PM
Before getting to your specific question, it is worth pointing out that this is not the best mechanism for reset management in the FPGA. As @florentw mentioned, no resets (where possible) is the best solution, but if you do use a global reset methodology, synchronous resets are preferred over asynchronous ones.
I presume you are using an "asynchronously asserted, synchronously deasserted" reset mechanism (generated from a properly constructed and constrained reset bridge) using the asynchronous preset/clear of the Xilinx flip-flops... While the system will work properly using this net as the driver to any synchronous set/reset, you will (technically) be violating the synchronous setup/hold on the assertion of the reset. However, the deassertion (which is the important edge) will be correctly timed and will work.
Presumably you already have a set_false_path on the input to the reset bridge (this is needed, even for the asynchronous preset/clear pins). This should be sufficient for the synchronous set/reset as well.
So, you can use the same net for the synchronous resets of the DSP and block RAM - just be aware that on the first clock after the assertion of reset, your design can go metastable/unknown. However, the second or third (or maybe 4th depending on the length of your synchronizer chain in the reset bridge) clock after the assertion of reset is guaranteed to properly enter the reset state.
06-07-2017 01:36 PM
Thanks Avrum, Yes, I am using an "asynchronously asserted, synchronously de-asserted" reset mechanism. Also, the set_false_path on the input to the reset bridge is set.