Multiple resets synchronized into one reset

[er.akhilkumar]

My design has two asynchronous resets and one software reset coming from a register bit. The design has multiple clock domains. I need to generate one synchronized de-assert reset for each clock domain.

To do this, I am first generating an asynchronous reset from the above resets using combinational logic. I am using this asynchronous reset as the reset in reset synchronizer D-FFs and generating a synchronous de-assert reset which asserts on the assertion of the asynchronous reset and de-asserts on the 2nd posedge of the target clock domain.

But, I am getting Lint errors from Jasper Gold tool on the usage of asynchronous reset generated from the combinational logic being used as a reset for reset synchronizer D-FFs. The error is RST_IS_DCMB (Net '%h' generated from combinational logic is driving reset of one or more flipflops. One such flip-flop is '%h'.)

Is there anything wrong in my approach? Please suggest.

 

[kaz1]

Can you post a diagram of your reset design so we see why the lint tool is so unhappy.

 

[ThisIsNotSam]

My design has two asynchronous resets and one software reset coming from a register bit. The design has multiple clock domains. I need to generate one synchronized de-assert reset for each clock domain.

To do this, I am first generating an asynchronous reset from the above resets using combinational logic. I am using this asynchronous reset as the reset in reset synchronizer D-FFs and generating a synchronous de-assert reset which asserts on the assertion of the asynchronous reset and de-asserts on the 2nd posedge of the target clock domain.

But, I am getting Lint errors from Jasper Gold tool on the usage of asynchronous reset generated from the combinational logic being used as a reset for reset synchronizer D-FFs. The error is RST_IS_DCMB (Net '%h' generated from combinational logic is driving reset of one or more flipflops. One such flip-flop is '%h'.)

Is there anything wrong in my approach? Please suggest.

The thing with lint is that there are so many things it reports that you can ignore. It is hard to tell whether your case is one of such cases. I suspect it is.

 

[KlausST]

Hi,

So you need clock synchronous deassertion.
But the RESETs don´t need to be deasserted synchronously with respect to each other.

In any case you need to ensure the minimum RESET time.

A simple D-FF generates synchronous deassertion (and additionally a clock synchronous assertion):
RESET_In --> D

You may use a D-FF with asynchronous_SET
RESET_IN --> async_SET
0 --> D

Klaus

 

[er.akhilkumar]

Can you post a diagram of your reset design so we see why the lint tool is so unhappy.

I couldn't insert the diagram here due to a technical issue, but here is the code. Lint is generating error on "assign async_ip_rst_n = rst_a_n & rst_b_n;". I know that many errors/warnings generated by Lint needs to be ignored on the basis of design but I just want to be assured, if my approach here to generate one reset from multiple asynchronous resets is correct and it is not prone to glitches. I searched many online resources and books but couldn't find anything on this. Please suggest. Thanks!
The other way I could think of is to synchronize the resets individually and feed them to a combinational logic to generate a reset. There also, Lint will report errors on the comb. logic.

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
wire async_ip_rst_n;
reg [1:0] sync_ip_rst_n;
 
assign async_ip_rst_n = rst_a_n & rst_b_n;
 
  always @ (posedge clk or negedge async_ip_rst_n)
  begin
    if (!async_ip_rst_n)
      sync_ip_rst_n <= 2'b00;
    else
      sync_ip_rst_n <= {sync_ip_rst_n[0], 1'b1};
  end
 
  assign sync_ip_rst_n = sync_ip_rst_n[1];

---

 

[kaz1]

I see you are applying reset synchroniser as below:
That is ok. I am just not sure about your last assignment of "sync_ip_rst_n = sync_ip_rst_n[1];" is that legal in verilog?
In vhdl it is seen as multiple drivers and compiler will reject it.

 

[er.akhilkumar]

I see you are applying reset synchroniser as below:
That is ok. I am just not sure about your last assignment of "sync_ip_rst_n = sync_ip_rst_n[1];" is that legal in verilog?
In vhdl it is seen as multiple drivers and compiler will reject it.

View attachment 184603

This assignment is correct in verilog.
Can you please confirm that my approach of generating an asynchronous reset from combinational logic and feeding it to the Reset Synchronizer is correct? Because, in my case, there are two asynchronous resets and I need to generate one synchronous reset (async. assertion sync. de-assertion).
Isn't there a standard procedure to generate one reset from multiple async. resets?
Thanks!

 

[kaz1]

This assignment is correct in verilog.
Can you please confirm that my approach of generating an asynchronous reset from combinational logic and feeding it to the Reset Synchronizer is correct? Because, in my case, there are two asynchronous resets and I need to generate one synchronous reset (async. assertion sync. de-assertion).
Isn't there a standard procedure to generate one reset from multiple async. resets?
Thanks!

reset at source can be generated from any logic. What matters here is that it has to be synchronised to clock domain. There is no visibility about its source anyway.

You may also try a basic double synchroniser instead of above reset bridge to see if the message goes away.