Is it required to use reset synchronizer with gated clock?

[Ashish Agrawal]

Hi All,
I have clk_in and rst_an as inputs to my design.
I am using 2 flop reset synchronizer to synchronize rst_an with clk_in. The output of synchronizer is sync_rst_n.
Internally in the design 2 control signals are generated as func_clk_en and func_reset_en.
I want to combine these signals with my input clock and reset for my functional block.
I am generating func_clk_gated by gating the clk_in with func_clk_en. And generating func_reset_gated by combining sync_rst_n with func_reset_en and then synchronizing it with clk_in.

Is it okay to synchronize the combined reset with clk_in instead of synchronizing with func_clk_gated ?


Thanks in advance.

 

[harpv]

This sounds good enough. Since both the clocks (clk_in and func_clk_gated) are synchronous, the deassertion of reset shouldn't cause any problems if synchronized using clk_in. Why do you think there could be a problem in not synchronizing using func_clk_gated?

 

[Ashish Agrawal]

Why do you think there could be a problem in not synchronizing using func_clk_gated?

I am a newbie at this. But if I am synchronizing with clk_in then reset to my functional block may be de-asserted even if there is no clock (func_clk_en = 0), while if it is synchronized using func_clk_gated then reset will be de-asseted only after the func_clk_gated is available. However in both the cases, it will not make any difference in the functionality. Correct me if my understanding is wrong.

I have one more question. Is it really required to put reset synchronizer after combining sync_rst_n with func_reset_en? As sync_rst_n is already synchronous to clk_in and func_reset_en is also generated using the same clock. So combination of these two signals should also be synchronous to clk_in/func_clk_gated ?

 

[harpv]

I am a newbie at this. But if I am synchronizing with clk_in then reset to my functional block may be de-asserted even if there is no clock (func_clk_en = 0), while if it is synchronized using func_clk_gated then reset will be de-asseted only after the func_clk_gated is available. However in both the cases, it will not make any difference in the functionality. Correct me if my understanding is wrong.

Yes, there shouldn't be a problem. As far as I can see, the reset synchronizer using func_clk_gated will lose couple of clock cycles, which perhaps you can save using clk_in. I hope you understand.

I have one more question. Is it really required to put reset synchronizer after combining sync_rst_n with func_reset_en? As sync_rst_n is already synchronous to clk_in and func_reset_en is also generated using the same clock. So combination of these two signals should also be synchronous to clk_in/func_clk_gated ?

As a matter of fact I haven't seen many designs with a reset enable for a hardware reset. Do you really require this signal?

To answer your question : Yes, if you are using the enable signal synchronous to the clk_in, then the second synchronizer might not be required.

 

[Ashish Agrawal]

As a matter of fact I haven't seen many designs with a reset enable for a hardware reset. Do you really require this signal?

Yes, this signal is required. This signal is nothing but software reset to reset the functional block only.

To answer your question : Yes, if you are using the enable signal synchronous to the clk_in, then the second synchronizer might not be required.

As you said might not be required, why didn't you say will not be required ?

 

[harpv]

Yes, this signal is required. This signal is nothing but software reset to reset the functional block only.

As you said might not be required, why didn't you say will not be required ?

Because I wasn't sure what your design requirement was.

Since hardware reset will be required in case software hangs, I don't know if having an enable is a good idea.

But you say it's for software reset. So it is not essentially an enable, but an OR of the resets? As in the reset is hardware_reset || soft_reset. Is that the case?

And another thing is if you have multiple functional blocks with a software reset for each of them, then I believe you'll need multiple reset synchs corresponding to each of your software reset.

 

[Ashish Agrawal]

Because I wasn't sure what your design requirement was.

Since hardware reset will be required in case software hangs, I don't know if having an enable is a good idea.

But you say it's for software reset. So it is not essentially an enable, but an OR of the resets? As in the reset is hardware_reset || soft_reset. Is that the case?

Yes it is the case. So do I need a reset synchronizer for this reset combination (sync_rst_n || soft_reset_n) as both of the signals are already coming from clk_in ?

And another thing is if you have multiple functional blocks with a software reset for each of them, then I believe you'll need multiple reset synchs corresponding to each of your software reset.

Yes I have multiple functional blocks with a software reset for each of them but all of these software resets are coming from clk_in then why do I need multiple synchs (or any synchs, as I am combining the synchronous hard reset with synchronous soft reset) ?

 

[harpv]

Yes I have multiple functional blocks with a software reset for each of them but all of these software resets are coming from clk_in then why do I need multiple synchs (or any synchs, as I am combining the synchronous hard reset with synchronous soft reset) ?

You'll need different reset synchronizers if the clocks going to these functional blocks aren't balanced. They may be coming from the same source clk_in but if these different clocks aren't balanced they'll have different skews after clock tree synthesis.

But if you say all the clocks are synchronous and you have the required constraints in place, then you will not need different reset synchronizers, just the one will be sufficient.

 

[Ashish Agrawal]

You'll need different reset synchronizers if the clocks going to these functional blocks aren't balanced. They may be coming from the same source clk_in but if these different clocks aren't balanced they'll have different skews after clock tree synthesis.

But if you say all the clocks are synchronous and you have the required constraints in place, then you will not need different reset synchronizers, just the one will be sufficient.

So as a front end designer, I should always put the synchronizers then even if there are different skews, it will be taken care.

 

[harpv]

So as a front end designer, I should always put the synchronizers then even if there are different skews, it will be taken care.

I don't think it should be your decision alone. Putting synchronizer is a safe bet, but at the same time it consumes some area also. So I believe its an architecture decision involving you and the synthesis engineer.