Clock and Reset

The APB Interconnect core has only 1 clock source (clk) and 1 reset signal (rst_n), and operates in a single clock domain. Efinix recommends the same clock domain for both the APB Interconnect core and the slave.

The reset signal, rst_n is an asynchronous reset. However, the de-assertion of the reset signal is synchronous. An internal reset synchronizer is available to synchronize the de-assertion of rst_n to clk domain. The reset synchronizer has 1 to 2 clock cycles latency.

The rst_n is an active low signal that needs to be initialized to 0 before the start of any operation.

Upon assertion of the reset signal, i.e., rst_n = 0, the entire APB Interconnect core resets. In the Round-Robin mode, the grant access resets to Master 0. In Fixed-Priority mode, the grant access remains unchanged, i.e., it is based on the masters' priority and the assertion of s_apb_psel_i.

Upon de-assertion of the reset signal, i.e., rst_n = 1, the APB Interconnect core becomes operational after 1 to 2 clock cycles of reset synchronization. The apb_eval signal becomes high, indicating that the APB Interconnect core is in an EVALUATION state, where the evaluation of all the masters' requests takes place to decide which master is to be granted access.

Figure 1. Single Reset Domain on All Modules (Slave, APB Interconnect Core, and Masters)
Warning: Efinix recommends that the APB Interconnect core shares the same reset domain as the slave. For cases where the reset is different between the slave and the APB Interconnect core, there may be a situation of potential deadlock where the operational APB Interconnect core is actively waiting for the assertion of apb_pready_i from the slave, which may not occur if the slave is in a reset.

The APB Interconnect core has a built-in latch mechanism to cater for a situation where the granted master does not comply with the APB protocol of maintaining the state of signals: s_apb_sel_i, s_apb_penable_i, s_apb_pwrite_i, s_apb_paddr_i, s_apb_pwdata_i, s_apb_pwdata_par_i, s_apb_pstrb_i, and s_apb_pstrb_par_i until the return of s_apb_pready_o.

This non-compliance situation may be caused by the following:
  • Different reset domains between the granted master and the APB Interconnect core, where the granted master may encounter reset in the midst of an APB transfer.
  • Signal corruption in the granted master during the APB transfer.

Figure 2 illustrates a situation where the Master0 is requesting an APB write transfer, but an independent reset event distorts Master_0's s_apb_psel_i, s_apb_penable_i, s_apb_pwrite_i, s_apb_paddr_i, s_apb_pwdata_i before the return of s_apb_pready_o. As indicated by grant_o, the APB Interconnect core has successfully granted Master_0's request and propagates the granted request to the slave. When the slave responses with the assertion of apb_pready_i, the Master_0's s_apb_pready_o asserts too, marking the completion of the write transfer, despite the distorted s_apb_sel_i in the granted Master_0.

Using this same illustration, if the signal grant_o does not update to 3'b001, it indicates that the APB Interconnect core is not successful in capturing the Master_0's request. Here, there is no grant request for Master_0.

Figure 2. Reset Master on Different Domains with APB Interconnect. Only master modules are reset.