Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Is it required to use reset synchronizer with gated clock?

Status
Not open for further replies.
A

Ashish Agrawal

Member level 3
Member level 3
Joined
Mar 24, 2015
Messages
60
Helped
8
Reputation
16
Reaction score
8
Trophy points
8
Activity points
502
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.
 

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?
 

harpv said:
Why do you think there could be a problem in not synchronizing using func_clk_gated?
Click to expand...
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 ?
 

Ashish Agrawal said:
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.
Click to expand...

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.


Ashish Agrawal said:
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 ?
Click to expand...

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.
 

harpv said:
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?
Click to expand...

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.
Click to expand...
As you said might not be required, why didn't you say will not be required ?
 

Ashish Agrawal said:
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 ?
Click to expand...

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.
 

harpv said:
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?
Click to expand...
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.
Click to expand...
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) ?
 

Ashish Agrawal said:
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) ?
Click to expand...

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.
 

harpv said:
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.
Click to expand...

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

Ashish Agrawal said:
So as a front end designer, I should always put the synchronizers then even if there are different skews, it will be taken care.
Click to expand...

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.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top