01-22-2018 12:57 AM
Hello all. A quick question: I keep getting this critical warning when running design validation:
[BD 41-1348] Reset pin /adc_interface/adc_framealign_wrapper_0/reset (associated clock /adc_interface/adc_framealign_wrapper_0/clk) is connected to asynchronous reset source /adc_interface/reset_adcinterface_0/fsm_reset. This may prevent design from meeting timing. Please add Processor System Reset module to create a reset that is synchronous to the associated clock source /adc_interface/if_LTC2271_2lane_0/clk_div.
The reset in question is the fsm_reset signal is shown in blue below. It is sourced from FDREs that has the same clock as the FDREs it is being used to reset. Can it still be asynchronous?
It is generated in the following code block:
module reset_adcinterface( input clk, // Clk (should be clkdiv from serial interface) input reset_pb, // Reset from pushbutton input reset_ps, // Reset from Zynq PS (or fabric) input rdy_delay, // Ready signal from IDELAYCTRL circuit in serial interface output serdes_reset, output fsm_reset ); reg [3:0] counter = 4'd0; // Increment counter when delays are ready and reset is released always @(posedge clk) begin if (reset_pb || reset_ps) counter <= 4'd0; else if ( rdy_delay && (~&counter[3:0]) ) // If rdy_delay is true and counter is less than 1111 counter <= counter + 4'd1; end // Assign outputs assign serdes_reset = (counter < 3); // SERDES Reset should be synchronous to CLKDIV and min 2 cycles wide assign fsm_reset = (counter < 6); endmodule
I tried registering the output with something like:
... output reg fsm_reset = 1 ... always @(posedge clk) begin ... fsm_reset <= (counter > 6) ? 1'b0 : 1'b1; .. end
This still gave the same warning. Also, I generate another reset signal in the exact same way (serdes_reset) used for ISERDESE2s, and I don't get any error for that one...
Any ideas? The design works, I just don't like having "Critical Warnings", or at least not ones I know can be safely ignored.
01-24-2018 11:00 AM
You definitely need to register the reset so that was the right step.
You can not provide a default value to an output port so remove the "=1" in
output reg fsm_reset = 1
Can you show how your state reg is being reset?
Also the reset_pb and reset_ps are probably async to 'clk'. So I would add them to the sensitivity list for the counter reg always block. Better yet would be to create a sync reset from 'reset_pb || reset_ps'. Use the Xilinx xpm_cdc_sync_rst to create it easily. Then you can use this sync_rst to reset the counter and the fsm_reset.
LMK what works!
01-30-2018 12:57 AM
Hi @amol_aeva, and thank you very much for the reply.
I haven't tried your suggestion yet but I will when I have a spare minute. I have a few questions though:
1. The warning message calls for a Processor System Reset module, is the xpm_cdc_sync_rst macro equivalent? Better? Cheaper?
2. I was under the impression that the output already is registered because it is the output of logic gates driven by a register. Would I really need to clock this through a register again? I tried this and still got the same result.
3. Could you point me to a source about not using initial values for an output reg? I have always been using them and not had any problem.
4. Finally, wouldn't adding anything but clk (especially signals that might be async) to the sensitivity list only make things worse?
I don't mean any disrespect, but I'm here to learn and it would be great with some details :)
By "state reg", are you referring to the FSM_sequential_state_reg in the figure? If so, it is being reset by the fsm_reset signal, which is the one at the core of this question. As I mentioned, I don't get a similar warning for the serdes_reset signal. Weird, no?
01-31-2018 01:11 PM
1. Processor System Reset, as far as I know, is useful in IP Integrator designs with a processor. This may be a standard message from Xilinx which are not always helpful. I would use the xpm macro.
2. I was only mentioning that registering the reset signal is good design practice and you already did do that - no need to register again.
3. I missed that that the reg was being declared in the port list so giving it an initial value is fine like with any register declaration anywhere.
4. With resets, I like to follow the suggestions by Cummings http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf. He basically recommends that you want asynchronous reset assertion and synchronous reset removal. I think the xpm_cdc_async_rst macro does it that way. I should have recommended that before and not the xpm_cdc_sync_rst. Check the libraries guide on how the xpm_cdc_* blocks work.
Also another post I stumbled on about resets has a decent discussion by avrumw here: