In AXI, low-power mode uses CSYSREQ, CSYSACK and CACTIVE three signal to realize the function, but I think only CSYSREQ and CACTIVE can realize the fuctionk, CSYSACK seems to be unnecessary?

In the AXI LPI protocol, CACTIVE is used to indicate component activity, whilst the CSYSREQ and CSYSACK signal pair provides a four-phase handshake used to guarantee the availability of any resources which may be removed on entering the low power mode.

It is expected that the component and the controller, whether for clock or power, will be asynchronous and therefore the four phase behaviour us required.

So taking clock control as an example use-case, this is intended to be used for high-level clock gating for one or more components where the skew between the component and the clock gate makes them essentially asynchronous. This is intended to be used in combination with mid and low level clock gating within a component.

The component uses CACTIVE as a requirement indicator. When LOW it indicates the clock is not currently required, when HIGH it indicates the clock is required. Note that in this context the CACTIVE can typically be set HIGH even when the clock is not available through some combinatorial path within the component, this provides clock wake functionality.

CSYSREQ and CSYSACK are used as a guarantee that the clock is available. In the clock control example when a clock controller sees CACTIVE LOW it can request the clock to be stopped. It does this by setting the CSYSREQ LOW, however the clock will not be stopped until the CSYSACK from the component is set LOW in response. This ensures the component is ready for the clock to be stopped.

Another note is that the AXI LPI specification allows the use of CACTIVE as a denial mechanism; however ARM CoreLink IP which uses the AXI LPI does not support this. It uses CACTIVE only as a component activity indicator.

On newer IP the AXI LPI is being replaced with the Q-Channel LPI protocol, which is similar but has increased functionality, including a specific denial mechanism. Documentation for this protocol can be found at: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0068b/index.html

In the AXI LPI protocol, CACTIVE is used to indicate component activity, whilst the CSYSREQ and CSYSACK signal pair provides a four-phase handshake used to guarantee the availability of any resources which may be removed on entering the low power mode.

It is expected that the component and the controller, whether for clock or power, will be asynchronous and therefore the four phase behaviour us required.

So taking clock control as an example use-case, this is intended to be used for high-level clock gating for one or more components where the skew between the component and the clock gate makes them essentially asynchronous. This is intended to be used in combination with mid and low level clock gating within a component.

The component uses CACTIVE as a requirement indicator. When LOW it indicates the clock is not currently required, when HIGH it indicates the clock is required. Note that in this context the CACTIVE can typically be set HIGH even when the clock is not available through some combinatorial path within the component, this provides clock wake functionality.

CSYSREQ and CSYSACK are used as a guarantee that the clock is available. In the clock control example when a clock controller sees CACTIVE LOW it can request the clock to be stopped. It does this by setting the CSYSREQ LOW, however the clock will not be stopped until the CSYSACK from the component is set LOW in response. This ensures the component is ready for the clock to be stopped.

Another note is that the AXI LPI specification allows the use of CACTIVE as a denial mechanism; however ARM CoreLink IP which uses the AXI LPI does not support this. It uses CACTIVE only as a component activity indicator.

On newer IP the AXI LPI is being replaced with the Q-Channel LPI protocol, which is similar but has increased functionality, including a specific denial mechanism. Documentation for this protocol can be found at: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0068b/index.html

Thanks very much, your answer is very useful.

nice answer！