• State Accepted Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 94 subscribers
  • Views 29975 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Please explain some of the new ACE5 signals in relation to the MASTER and INTERCONNECT behavior

armchronos

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

Parents
  • 0 Arm Employee Badge in reply to armchronos

    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.

Reply
  • 0 Arm Employee Badge in reply to armchronos

    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.

Children