Ways to provide resets

[fragnen]

There is a block in the SOC which has AHB reset and that block has a software reset also. The SOC has also a power on reset definitely. This block is one of the blocks of the SOC. How will the resets be provided to this block ? Will there be need to provide all the three resets, power on reset, AHB reset and software reset to be provided to this block? Which reset among these three resets should be de-asserted first and what should be the de-assertion sequence of these three resets to this block? Can we do AND or OR with these three resets together to generate a single reset for this block but in that case glitch may come. Please suggest.

 

[morris_mano]

Yes, if three reset input to the block , then provide all three. Three reset serves different purpose.

1. Power on reset should be driven my main reset which is released after power up.
2. software reset should be driven by software accessible register. This reset is toggled only when software write to it.
3. AHB reset can be driven by AHB bus reset if it already exist at SOC level. Usually, AHB reset only reset AHB registers and not the other logic in the block.

 

[fragnen]

Yes, if three reset input to the block , then provide all three. Three reset serves different purpose.

1. Power on reset should be driven my main reset which is released after power up.

What do you mean by my in your above statement?

In what sequence these three resets should be de-asserted?

Should Power on reset be used to reset other registers of the block other than the AHB register?

 

[FvM]

I'd expect software and AHB reset to be implemented as synchronous resets. If so, there's no deassertion timing issue involved.

 

[fragnen]

I'd expect software and AHB reset to be implemented as synchronous resets. If so, there's no deassertion timing issue involved.

But if both the AHB and software reset are wanted to be asynchrounous, the question asked in post number 1 still remains.

 

[FvM]

The question about a deassertion sequence is IMHO useless. Nothing changes if multiple resets are applied simultaneously. Asynchronous resets need to be deasserted clock-synchronous to avoid unpredictable logic states, no matter if you have one or multiple reset sources.

 

[fragnen]

The question about a deassertion sequence is IMHO useless. Nothing changes if multiple resets are applied simultaneously. Asynchronous resets need to be deasserted clock-synchronous to avoid unpredictable logic states, no matter if you have one or multiple reset sources.

What does IMHO means? What is the full form?

This is in awareness that the asynchronous resets have to be de-asserted synchronously.
In what sequence power on resets, system clock, AHB clock, AHB reset and software reset be applied initially when a digital or mixed signal systems start?

 

[morris_mano]

Power on resets -> system clock -> AHB clock -> AHB reset. AHB clock will be generated from system clock ( can be gated if no AHB traffic) and AHB reset will be generated from power on reset synchronously deasserted with AHB clock, so need AHB clock to release the reset. Software reset can be ORed (assuming active high reset) and will only be applied when software sets it.

 

[fragnen]

Power on resets -> system clock -> AHB clock -> AHB reset. AHB clock will be generated from system clock ( can be gated if no AHB traffic) and AHB reset will be generated from power on reset synchronously deasserted with AHB clock, so need AHB clock to release the reset. Software reset can be ORed (assuming active high reset) and will only be applied when software sets it.

Is this that AHB reset will have to be generated from system clock? Cannot the AHB reset be provided independently?

Is this that AHB reset will have to be generated from power on reset and it cannot be provided independently? Will the logic be a delay logic like chain of buffers to generate AHB reset from power on reset or it will be some other logic other than delay logic and which logic then?

Will not glitch can come in the reset tree if software reset is ORed with Power on reset and AHB reset?

 

[dpaul]

@fragnen ,
Are you not reading the AMBA AHB protocol spec provided by ARM?
That will give you the answers regarding the AHB reset.

Excerpt from the spec - The reset signal, HRESETn, is the only active LOW signal in the AHB protocol and is the primary reset for all bus elements. The reset can be asserted asynchronously, but is deasserted synchronously after the rising edge of HCLK.

You design your reset gen logic circuit such that the above remains valid, nothing more nothing less!