Hi,
The AMBA5 spec for ACE5 shows some new signals versus ACE4 :
VAWQOSACCEPT
VARQOSACCEPT
AWAKEUP
ACWAKEUP
SYSCOREQ
SYSCOACK
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 ?
Thanks,
David
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.
Hi Christopher,
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
Alexander
Hi Alex,
You can connect PWAKEUP directly to PSEL in this case.
Hi Cristhopher,
Thank you for the answer.
Could you please clarify is there a way to pass sysco* and acwakeup signals through adb400_ace_lite_dvm?
Thanks
Alex
I'm afraid this is IP specific information that is best addressed by you opening a support with the Arm support team.