The AMBA5 spec for ACE5 shows some new signals versus ACE4 :
How are these used in an SOC system ?
For example, I think but I'm not usre if VAWQOSACCEPT, VARQOSACCEPT is output by each slave and becomes input to INTERCONNECT
or an input to the CPU ? It's not clear how these signals are related to the other QOS signals in the ACE5 spec.
For AWAKEUP, this is output from a MASTER (CPU ??) to the INTERCONNECT ? Only used by AXI5, ACE5, ACE5-Lite to wakeup the
interconnect state machine. Must occur one cycle before ARVALID, AWVALID, WVALID. It stays high for all transactions.
Becomes low only when the MASTER wants to signal to the INTERCONNECT to go to a semi-low power state.
Wish there were some waveforms to illustrate all the spec description on page 360 (E2.9.1). It would be much easier to understand.
For ACWAKEUP (ACE5) , this is output from the INTERCONNECT and used by the MASTER (CPU ??) to wake up the logic
in the MASTER (CPU??) from a semi-low power state. ACWAKEUP must occur at least one cycle high before ACVALID/ACREADY
are active. Again, wish there were some waveforms to illustrate the spec description on pg 361 (E2.9.2)
For SYSCOREQ (ACE5), this is output from the MASTER (CPU ??) to connect to a coherency device (INTERCONNECT).
Seems like the MASTER outputs this signal and then the INTERCONNECT device (helping to manage coherency) outputs an acknowledge
to the MASTER for INTERCONNECT to be in correct state machine mode.
Need further explanation with waveforms on four-phase Coherency Connection signaling mentioned on page 362 (E2.10).
When SYSCOREQ goes low what's the behavior of the INTERCONNECT ?
The VAxQOSACCEPT signals are driven by the destination (Table C1-7) to an upstream device. Their purpose is to indicate what QoS value the slave is able to accept before the upstream device attempts to issue it.
The expected use case is that a memory controller will indicate to an interconnect that it has run out space to process lower QoS value transactions. The interconnect can then select transactions that have a QoS value which exceed the VAxQOSACCEPT value. Without this information, the interconnect may present a low priority transaction which would block the interface as the memory controller would not be able to process it.
AWAKEUP is driven by the transaction source to a downstream device (Table C1-8). It's purpose is to indicate to the downstream device that a transaction is waiting to be processed, or will soon need to be processed. If AWAKEUP is asserted earlier than the transaction appears, then this allow some of the latency of leaving a low power state to be hidden. Otherwise, AWAKEUP can be used to drive logic in the downsteam device that indicates it should become active.
Some minor corrections: AWAKEUP is not required 1 cycle before AxVALID or WVALID, its just recommended that its asserted at least 1 cycle before. It also doesn't stay high for all transactions - it should only be high until the Ax handshake has completed. After this point, the device should be aware that it has an active transaction, and so should not attempt to sleep until that has completed. AWAKEUP should only be reasserted if another transaction is about to become pending.
If your device didn't have AWAKEUP, it could generate it from the incoming ARVALID, AWVALID, WVALID.
One general clarification, a master interface does not mean the interface of a master such as a CPU. All AXI connections are considered as master to slave - so an interconnect has both master and slave interfaces. So AWAKEUP is a master interface signal, but could be driven by a CPU master to the interconnect, or the interconnect master interface connected to a slave device.
You're correct about ACWAKEUP, it is specifically from an interconnect interface to an upstream device. It's used similarly to AWAKEUP - it indicates that a transaction is pending, or will soon become pending. Typically, the upstream device will be some kind of ACE master like a CPU, although it could also be used to indicate to an I/O master with DVM support that there is an incoming DVM transaction. Again, its only recommended that it occurs before ACVALID, not must.
The SYSO* signals used to remove the master from the coherent domain. The actual effect of this is stop the interconnect from sending snoop transactions to this master. SYSCOREQ is driven by a master to an interconnect, and informs the interconnect that the master either wishes to enter or leave the coherent domain. The SYSCOACK is an acknowledge that shows the operation of entering or the leaving the domain has completed.
When SYSCOREQ goes low, the interconnect needs to ensure that it stops sending snoops to this master, and that it completes any outstanding snoops. Once this has been performed, it can respond with SYSCOACK low.
Thanks for the detailed reply !!
It's quite helpful to understand the usage purposes of these signals.
But need clarification about the generation of AWAKEUP and ACWAKEUP.
Sounds like you can logically OR the AWVALID/ARVALID/WVALID and add a register pipeline to delay the normal AXI signals
to generate AWAKEUP.
For ACWAKEUP which comes from the interconnect, one may similarly directly connect ACWAKEUP from ACVALID and register pipeline the ACE5 signals to ensure ACWAKEUP comes at least one cycle before ACVALID.
From the AMBA spec, it seems like AWAKEUP, ACWAKEUP, VAxQOSACCEPT, SYSO* are REQUIRED signals. Please confirm.
Also, these new signals are not tied to other signals as a handshake. So they are independent of regular AXI/ACE signals
but the user needs to ensure the proper state of these signals in relation to AXI/ACE signals at the SYSTEM or SOC level.
Only the VAxQOSACCEPT behave like static register signals but need to still be synchronized to the AXI/ACE clock.
You're correct that you could generate the AWAKEUP by logically ORing the incoming *VALID signals.
You do not need to delay the normal AXI signals. The Specification only recommends that AWAKEUP leads the incoming transaction in order to hide the wakeup latency from the transaction. In other words, if the AWAKEUP was only generated at the same time or after the incoming transaction, then these transactions would need to wait for the AWAKEUP to wake up the system.
If you register the AXI signals in order to delay the incoming transaction, then you're just adding your own latency, and there's no benefit to AWAKEUP being a cycle earlier.
armchronos said:For ACWAKEUP which comes from the interconnect, one may similarly directly connect ACWAKEUP from ACVALID and register pipeline the ACE5 signals to ensure ACWAKEUP comes at least one cycle before ACVALID.
Correct, you can use ACVALID to generate ACWAKEUP. Again you could register incoming signals, but there wouldn't be any benefit to this.
armchronos said:From the AMBA spec, it seems like AWAKEUP, ACWAKEUP, VAxQOSACCEPT, SYSO* are REQUIRED signals. Please confirm.
No, all new features are optional - see page E2-335. A component should declare whether these features are supported by using the properties described at the beginning of each section. For example:
"The Wakeup_Signals property is used to indicate whether a component supports wake-up signaling:
TRUE Wake-up signals are supported.
FALSE Wake-up signals are not supported. If Wakeup_Signals is not declared, it is considered FALSE."
Correct, these signals aren't tied to the normal READY/VALID timing. Whether and how they should be synchronised depends on the specific component.
Christopher Tory said:You're correct that you could generate the AWAKEUP by logically ORing the incoming *VALID signals.
Thank you for the useful answers.
Could you please clarify one more thing.
In the SMMU600 TRM documentation the TCU programming interface has a ACE5 pwakeup_prog input.
How to correctly connect it to the APB master which doesn't have wakeup signal?
Tahank you again and Best Regards
You can connect PWAKEUP directly to PSEL in this case.
Thank you for the answer.
Could you please clarify is there a way to pass sysco* and acwakeup signals through adb400_ace_lite_dvm?
I'm afraid this is IP specific information that is best addressed by you opening a support with the Arm support team.
View all questions in SoC Design forum