Soc reset reset/rst problem

This section does not discuss synchronous reset, asynchronous reset and reset_release of asynchronous reset. Please refer to:

The road to advanced chip design – in-depth understanding of Reset – cy413026

This article mainly answers a few questions.

0. Why asynchronous reset is often low level

In fact, using a low level for asynchronous reset is a historical issue. When it is not in the reset state, it is a high level. When TTL circuits were used in the early days, keeping the high level saved power consumption compared to the low level. Nowadays, CMOS circuits no longer have this difference.

However, with the improvement of technology and the reduction of operating voltage, considering the impact of noise, everyone prefers low-level reset.

1. How can the off-chip reset signal, especially the button reset, prevent the impact of false jitter?

Common processing methods include two types:

  • Use a Schmitt trigger for IO input. The Schmitt trigger has a certain anti-jitter function.
  • Use de-bounce circuits

The principle of the de-bounce circuit is to detect the inversion of the IO input signal and then detect the signal value to be stable at a certain interval multiple times before outputting this change.

2. Why do common SOC designs put reset_release in the subsystem?

It should be considered from two aspects, one is the logical design and software usage; the other aspect is the physical implementation of the reset network.

For logic design and software, there are several aspects:

  • There are too many clocks for release. At the system level, release needs to pull all the clks. Some clks are even clocks within the subsystem.
  • During reset synchronization, software reset is usually added. It is inconvenient to add so many soft resets at the system level, and it is also difficult for software to control. The software needs to know the software reset timing of all subsystems and even sub-IPs.

For physical implementation:

  • Putting all the system clk in one module will cause problems. The clocks will interfere with each other and there will be problems with timing.
  • For a system as large as a SOC, it is problematic to put the reset in one place and route it to each reset register [but I cannot explain the detailed impact on physical implementation]

3. What is the relationship between whether a clock is required for asynchronous reset and whether the clock is stable?

Asynchronous reset itself has nothing to do with the clock, and when there is no clock, there is no recovery/remove timing problem with direct reset, so why do we need to do synchronous release?

First of all, when there is no clock, directly asynchronously reset. There is indeed no recovery/remove problem, but there is no guarantee that there will be no clock when resetting. Therefore, the issue of recovery/remove still needs to be considered.

Why in many cases the reset process is like this [such as power-on reset]:

  1. Request to reset first
  2. then open the clock
  3. Wait until the clock output is stable before deresetting

There are several considerations here:

  • First of all, even if the reset is released first, the actual reset is not released due to the synchronous release. Without a clock, the output of the reset synchronous circuit will not change.
  • Unlock the reset first, then turn on the clock. Turning on the clock, whether it is the gated clock or the PLL clock, requires a certain stabilization time. When it is unstable, it cannot be confirmed whether there will be a problem with the reset synchronization output, and when the clock is unstable, some digital and analog There will also be errors in logic
  • There are still many non-reset registers in the system. When the clock is turned on during reset, these non-reset registers will stabilize to a certain state after a few beats.
  • Considering EDA simulation, if clk is turned on after deresetting, the x state of the register may be directly reported and propagated, causing subsequent simulations to run away.

Some registers without reset can be flipped when clk is present. When the reset is valid, the reset value of the register with reset reaches stability after a few captures. A non-reset register that has clk but is limited by the control signal. Although it cannot capture data after having clk, it will stay in a stable state after a period of time.

One problem is that when the system is powered on and reset, the PLL has not started up or the lock will take some time. How to turn on the clock at this time? Some methods are to output the PLL clk mux to the crystal oscillator output during this period.

Is it necessary to turn on the clock during asynchronous reset?

In fact, according to the above description, if not turning on the clock has no impact on the function, you can not turn on the clock.

Some opinions from the forum below.

Power-on reset synchronous release problem – SOC discussion area – EETOP Chuangxin.com Forum (original name: Electronic Top Development Network) –

4. Asynchronous bridge, how to reset asynchronous fifo

Asynchronous FIFO design and use

This resource details the reset of asynchronous fifo. There are similar requirements for reset or flush/clear. It is relatively simple to reset afifo and its related peripheral logic. At this time, no matter whether afifo is in an empty state or the pointer is 0, it is no problem for everyone to reset it together.

The key is that sometimes it is only required to reset afifo itself. Some implementations of flush/clear/reset of asynchronous FIFO are given below. These methods are universal, but under normal circumstances reset does not do logic alone, so it is all done by flush/clear signals.

4.1 afifo flush/clear

Consider providing a single flush signal or independent flush signals (push_flush, pop_flush) for the FIFO. The flush signal is usually implemented by setting the value of the FIFO read-write pointer so that the FIFO is in the EMPTY state. Due to the particularity of the flush operation, we usually consider the implementation of flush based on the actual situation of the application. For example, we can specify some actions before and after the flush operation. In fact, in actual applications, when a flush operation needs to occur, certain conditions can often be met. For example, there must be no push or pop operations for several cycles before the flush operation, and the flush operation must be maintained for several cycles.

4.1.1 An operation of flushing the read clock domain first

The implementation of AFIFO’s rflush simply assigns rgnext to the value of rwptr2, so that the empty signal can be effectively output in the next cycle. Then, the read pointer will reach the write clock domain after passing through two levels of registers, and output the correct write clock domain signal. It should be noted that during the flush process, it should be ensured that there is no push operation in the write clock domain, and the flush operation needs to be maintained for three slow clock cycles to ensure that the signal is correctly delivered to the write clock domain. code show as below:

if (rflush) rgnext = rwptr2;
else rgnext = (rbnext>>1) ^ rbnext;
4.2 afifo reset

Consider implementing a single reset signal or independent reset signals. If a single reset signal is implemented, the reset signal is an asynchronous reset signal for all registers inside the FIFO controller and resets the registers of both clock domains at the same time. Since the reset signal is a completely asynchronous signal (not synchronized with any clock) or synchronous with one of the clocks, no matter what the situation, when the reset signal is valid/invalid, at least one register in the clock domain may generate a recovery/removal timing violation ( That is, the reset signal changes near the rising edge of the clock), which may cause an unstable state during reset. Therefore, a more reasonable approach is to provide independent reset signals for two different clock domains, or to internally synchronize the reset signal of one clock domain to another clock domain before using it.

4.2.1 Write clock domain clr first

A safer approach is to use only one clr signal input, and then output a clr_done in another clk domain to indicate clr completion. During this period of time, it is ensured that the peripheral logic does not read or write afifo.

  1. Enter the wr_clr signal of wrclk
  2. Use the wr_clr signal clr for this clock domain logic, and at the same time generate the wr2rd_clr signal and synchronize it to rd_clk
  3. The rd_clk domain detects the synchronized clr signal and starts clr
  4. wrclk detects rd_ptr==0 synchronized from rdclk, indicating that rdclk has completed clr, and clears wr2rd_clr at this time
  5. When rdclk detects that the synchronization signal of wr2rd_clr has been cleared and wr_ptr==0, it considers that afifo has completed all clr and outputs the clr_done signal.

The biggest problem in the above process is step 4, because it is possible that the rd_prt synchronized before clr is 0. In this case, wr2rd_clr will be cleared directly. At this time, wr2rd_clr may not have been synchronized to rdclk, so problems will occur.

The following process is a more reliable one:

  • wrclk generates wr_clr_pos and maintains the clr state, at this time full=1
  • Use wr_clr_pos to generate rd_clr_req and synchronize it to rdclk
  • Use the synchronized rd_clr_req to generate the rd_clr and rd_clr_hold signals
  • Synchronize rd_clr_hold to wrclk, rd_clr_hold is 1, indicating that rdclk has completed clr and is no longer being read. At this time, you can actually clr wclk and pull down rd_clr_req at the same time.
  • When rdclk detects that rd_clr_req is pulled low, it means that wrclk has completed clr, and knowing that rdclk has also completed clr, it can pull rd_clr_hold status low.
  • wrclk detects that rd_clr_hold is pulled low, indicating that rdclk has completed and released clr. At this time, wrclk can also release wr_cr_hold.
  • wrclk is generating wr_clr_pos and maintains the clr state. At this time, full=1
  • Use wr_clr_pos to generate rd_clr_req and synchronize it to rdclk
  • Use the synchronized rd_clr_req to generate the rd_clr and rd_clr_hold signals
  • Synchronize rd_clr_hold to wrclk, rd_clr_hold is 1, indicating that rdclk has completed clr and is no longer being read. At this time, you can actually clr wclk and pull down rd_clr_req at the same time.
  • rdclk checks that rd_clr_req is pulled low, indicating that wrclk has completed clr, and knowing that rdclk has also completed clr, it can pull rd_clr_hold status low, which is readable but empty.
  • wrclk detects that rd_clr_hold is pulled low, indicating that rdclk has completed and released clr. At this time, wrclk can also release wr_clr_hold.

To sum up, it is necessary to ensure that it cannot be written first, and then the opposite end cannot read and then read clr at the same time, and then write wrclk clr at high speed [clr writing must be under the condition that neither writing nor reading can be done]. After the clr writing is completed, clr rd, clr rd are released. wr_clr_hold is released after release.

For specific code implementation, please refer to another article of mine.

In fact, judging from the above description, whether the clr signal is input from wrclk or rdclk, the clr operation can be completed. This description clearly requires that afifo cannot be operated during clr.

5. Will partial logic reset affect peripheral logic

This is actually a typical RDC problem. It is common that the bus module resets the logic of some masters and cannot affect the paths of other masters.

Generally, there will be a reset protection circuit in this case to clamp the boundary signal to a level that does not affect other channel values. In fact, regardless of whether this boundary is asynchronously processed or not, clamping is required, because the reset of this part of the circuit will have two effects:

  • glitch
  • Signal inversion that does not satisfy the setup/hold of the peripheral logic

6.What to do with RDC reset domain cross

What is reset domain cross?

When the signal reset by reset_0_n is captured by the register of reset_1_n in other reset fields, there will be a risk of metastability.

These two reset domains may still be synchronous circuits, but we want to reset one part and not reset the other part. A common example is noc. We need to reset the NIU of a certain master of noc. This part needs to be reset together with the master subsystem. This NIU works on nocclk and masterclk at the same time.

Common ways to handle this situation are as follows:

  • reset assert order—that is, many problems can be solved by controlling the order of reset.
  • reset-clamp—-Reset clamp, clamp the cross path output to the required value before reset, that is, isolation has the same effect as isolation at different power domain boundaries.
  • clk isolation—-is to turn off the clk of the register in the reset domain that will be affected

For details, please refer to another article:

RDC (reset domian cross) reset cross domain-CSDN Blog

7. What is the structure of the asynchronous reset tree

The asynchronous reset tree is composed of level-by-level reset synchronization logic, that is, an asynchronous reset synchronizer is added to each level. As shown below: