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

What's the purpose for WACK and RACK for ACE and what's the relationship with WVALID and RVALID ?

Hi,

From hardware perspective, what's the purpose of WACK and RACK and how does it affect the ACE protocol ?

I can see that the specification says the master issues these two signals to indicate to the interconnect that Write and Read transactions completed

successfully at the master.

What happens on the ACE interface/protocol if NO WACK and RACK occur ?

Please provide some detailed explanations of proper operation of WACK and RACK and improper operation (what if no WACK / RACK occur).

Also, do these two signals (WACK,RACK) occur when WVALID , RVALID , respectively, are still high ? 

Are WACK and RACK totally independent of WVALID, RVALID ?

The ACE spec doesn't show any waveform relationship for WVALID, RVALID with respect to WACK and RACK.

Thanks,

David

Parents
  • The purpose of RACK and WACK is to indicate to the interconnect that the transaction has completed at the master. 

    The protocol requires that transactions to the same cache line are sequenced by the interconnect such that there is no ambiguity about the order that transactions are occurring in (C6.2 in the Spec). 

    If the protocol did not have RACK/WACK, then it would be possible to have a race condition between a transaction completing, and an incoming snoop to that line, where a snoop sequenced after the transaction could overtake the response.  For example, if R data had more latency than the incoming AC channel.

    Let's consider an example where two masters (M0, M1) wish to obtain a Unique copy of the same line, but there is no RACK in the protocol. 

    - M0s ReadUnique is ordered first, invalidates the other masters, and the R response is sent back to M0.

    - M1s ReadUnique is then allowed to progress by the interconnect, and generates invalidating snoops to all the masters, including M0.

    - The invalidating snoop from M1 overtakes the read response going to M0.

    - M0 doesn't yet have the line, and so passes back a Miss, and nothing is invalidated.

    - M0 then receives the response from the ReadUnique, and places the line a Unique state.

    - M1s ReadUnique then completes, and M1 also places the same line in a Unique state.  This is a problem, as the line cannot be Unique in two caches at the same time.

    If we had a RACK signal, then it wouldn't be possible for M1s ReadUnique to make progress until after the ReadUnique from M0 had completed in its entirety.  The ReadUnique from M1 would invalidate the line in M0, meaning the line would only be Unique in one master.

    The rules for RACK/WACK are given in C3.3 and C3.5 in the ACE Spec.  They are asserted for a single cycle, and the earliest they can occur for transaction is after the final response handshake - so after RLAST/RVALID/RREADY or BVALID/BREADY. 

    So WVALID, RVALID could be high at the same time, but for a different/later transaction. An example of RACK/WACK can be seen in C6.2.

    A RACK/WACK is required for every transactions for an ACE master.  If the master does not produce the RACK/WACK, then its likely that the interconnect will deadlock.  Any address hazards will not be resolved as the transaction will appear not to have completed.

Reply
  • The purpose of RACK and WACK is to indicate to the interconnect that the transaction has completed at the master. 

    The protocol requires that transactions to the same cache line are sequenced by the interconnect such that there is no ambiguity about the order that transactions are occurring in (C6.2 in the Spec). 

    If the protocol did not have RACK/WACK, then it would be possible to have a race condition between a transaction completing, and an incoming snoop to that line, where a snoop sequenced after the transaction could overtake the response.  For example, if R data had more latency than the incoming AC channel.

    Let's consider an example where two masters (M0, M1) wish to obtain a Unique copy of the same line, but there is no RACK in the protocol. 

    - M0s ReadUnique is ordered first, invalidates the other masters, and the R response is sent back to M0.

    - M1s ReadUnique is then allowed to progress by the interconnect, and generates invalidating snoops to all the masters, including M0.

    - The invalidating snoop from M1 overtakes the read response going to M0.

    - M0 doesn't yet have the line, and so passes back a Miss, and nothing is invalidated.

    - M0 then receives the response from the ReadUnique, and places the line a Unique state.

    - M1s ReadUnique then completes, and M1 also places the same line in a Unique state.  This is a problem, as the line cannot be Unique in two caches at the same time.

    If we had a RACK signal, then it wouldn't be possible for M1s ReadUnique to make progress until after the ReadUnique from M0 had completed in its entirety.  The ReadUnique from M1 would invalidate the line in M0, meaning the line would only be Unique in one master.

    The rules for RACK/WACK are given in C3.3 and C3.5 in the ACE Spec.  They are asserted for a single cycle, and the earliest they can occur for transaction is after the final response handshake - so after RLAST/RVALID/RREADY or BVALID/BREADY. 

    So WVALID, RVALID could be high at the same time, but for a different/later transaction. An example of RACK/WACK can be seen in C6.2.

    A RACK/WACK is required for every transactions for an ACE master.  If the master does not produce the RACK/WACK, then its likely that the interconnect will deadlock.  Any address hazards will not be resolved as the transaction will appear not to have completed.

Children