3.4.3 Runtime programming requirements

This section describes the requirements for programming during runtime.

Entry to and exit from snoop and DVM domains

The CCN-502 includes a means by which RNs can be removed from snoop and DVM domains, to ensure correct operation of both snoops and DVMs when an RN is taken out of reset, or is powered down and then later powered up.

Control of the device inclusion or exclusion in snoop and DVM domains is critical to the HN-F and MN, because the HN-F and MN must be aware of the RNs that are present and active in the snoop or DVM domain at the time a snoop request or DVM message is sent. Any mismatch in the HN-F or MN understanding of the domain participants and the ability of those participants to respond to a snoop or DVM request results in unpredictable behavior.

Entry to and exit from a snoop or DVM domain is achieved through a series of configuration writes and reads that ensure atomic entry to and exit from a snoop or DVM domain, as described in:

Note:

The following subsections mention the SDCR* and DDCR* registers. These registers are the Snoop Domain Control register and its variants, and the DVM Domain Control register and its variants, in the HN-F and MN configuration register spaces respectively. For more information, see:
Atomicity requirements for entry to or exit from a snoop or DVM domain

Entry to and exit from the snoop or DVM domain must be atomic for each domain, that is, only one such occurrence of either of these processes for each of the domains can be active in the CCN-502 at any given time. This atomicity requirement is not directly supported in hardware. Therefore it is the responsibility of the device or software thread that is performing the entry or exit process, to guarantee atomicity, either by convention, access through a critical section bounded by mutual exclusion synchronization primitives, or other method. The descriptions of the entry and exit processes in this section assume a critical section is used to ensure atomicity, but this is not a required implementation.

Entry to snoop domain

Entry of one or multiple RNs to a snoop domain is as follows:

Note:

The atomicity of SDCR updates is required across both sets and clears. Only one of either of these can be in flight at any given time.

Critical-section SnoopDomainCritSec{

Foreach (HN-F) {

  • An RN or its proxy performs a single write to HN-F SDCR_Set with a 1 in the position corresponding to the nodeID of the RN to be included in the snoop domain.

    Note:

    You can concurrently add multiple RNs to the snoop domain by simultaneously setting multiple bits in the SDCR_Set register.

    When issuing the write of SDCR_Set, the RN being added to the snoop domain must respond to snoop requests that are sent to it.

  • When receiving a write to SDCR_Set, the HN-F performs a series of actions, the result of which ensures the HN-F eventually begins sending snoop requests to the RN being added to the snoop domain. It also updates the SDCR to reflect the addition of RNs to the snoop domain.

}

Foreach (HN-F) {

  • An RN or its proxy performs a read of the SDCR, comparing the bit-positions previously set in SDCR_Set, repeating this step until the corresponding bit-positions have been set in the SDCR.

    At this point, the newly added RN is guaranteed to receive all subsequent relevant snoop requests from the corresponding HN-F.

    Note:

    It is not valid for the write to SDCR_Set to have a null effect on the SDCR. That is, the write before the polling read must have the effect of modifying the SDCR in at least one bit-position. If not, the subsequent read would immediately reflect completion because the new value equals the old value, and therefore the atomicity requirement described is not guaranteed.

}

When these steps are complete, the newly added RNs are included in the global snoop domain, and receive snoop requests from all HN-Fs as necessary for correct functionality.

}

Exit from snoop domain

Removal of one or multiple RNs from a snoop domain is as follows:

Note:

The atomicity of SDCR updates is required across both sets and clears. Only one of either of these can be in flight at any given time.

Critical-section SnoopDomainCritSec{

Foreach (HN-F) {

  • An RN or its proxy performs a single write to HN-F SDCR_Clear with a 1 in the position corresponding to the nodeID of the RN to be removed from the snoop domain.

    Note:

    You can concurrently remove multiple RNs from the snoop domain by simultaneously setting multiple bits in the SDCR_Clear register.

  • When receiving a write to SDCR_Clear, the HN-F performs a series of actions, the result of which ensures the HN-F eventually stops sending snoop requests to the RN being removed from the snoop domain. It also updates the SDCR to reflect the removal of RNs from the snoop domain.

}

Foreach (HN-F) {

  • An RN or its proxy performs a read of the SDCR, comparing the bit-positions previously set in SDCR_Clear, repeating this step until the corresponding bit-positions have been cleared in the SDCR.

    When this step is complete, the RN is guaranteed to no longer receive any subsequent snoop requests from the corresponding HN-F.

    Note:

    It is not valid for the write to SDCR_Clear described in this section to have NULL effect on the SDCR. That is, the write before the polling read must have the effect of modifying the SDCR in at least one bit-position. If not, the subsequent read would immediately reflect completion because the new value equals the old value, and therefore the atomicity requirement described is not guaranteed.

}

Before completion of these steps for all HN-Fs, the RN being removed from the snoop domain must respond to snoop requests sent to it. When these steps are complete for all HN-Fs, the RNs are excluded from the global snoop domain and are guaranteed not to receive any subsequent snoop requests.

}

Entry to DVM domain

Entry of one or multiple RNs to a DVM domain is as follows:

Note:

The atomicity of DDCR updates is required across both sets and clears. Only one of either of these can be in flight at any given time.

Critical-section DvmDomainCritSec{

  • An RN or its proxy performs a single write to MN DDCR_Set with a 1 in the position corresponding to the nodeID of the RN to be included in the DVM domain.

    Note:

    You can concurrently add multiple RNs to the DVM domain by simultaneously setting multiple bits in the DDCR_Set register.

    When issuing the write of DDCR_Set, the RN being added to the DVM domain must respond to DVM messages sent to it.

  • When receiving a write to DDCR_Set, the MN performs a series of actions, the result of which ensures the MN eventually begins sending DVM messages to the RN being added to the DVM domain. It also updates the DDCR to reflect the addition of RNs to the DVM domain.

  • An RN or its proxy performs a read of the DDCR, comparing the bit-positions previously set in DDCR_Set, repeating this step until the corresponding bit-positions have been set in the DDCR.

    Note:

    It is not valid for the write to DDCR_Set to have NULL effect on the DDCR. That is, the write before the polling read must have the effect of modifying the DDCR in at least one bit-position. If not, the subsequent read would immediately reflect completion because the new value equals the old value, and therefore the atomicity requirement described is not guaranteed.

When these steps are complete, the newly added RNs are included in the global DVM domain, and receive all DVM messages as necessary for correct functionality.

}

Exit from DVM domain

Removal of one or multiple RNs from a DVM domain is as follows:

Note:

The atomicity of DDCR updates is required across both sets and clears. Only one of either of these can be in flight at any given time.

Critical-section DvmDomainCritSec{

  • An RN or its proxy performs a single write to MN DDCR_Clear with a 1 in the position corresponding to the nodeID of the RN to be removed from the DVM domain.

    Note:

    You can concurrently remove multiple RNs from the DVM domain by simultaneously setting multiple bits in the DDCR_Clear register.

  • When receiving a write to DDCR_Clear, the MN performs a series of actions, the result of which ensures the MN eventually stops sending DVM messages to the RN being removed from the DVM domain. It also updates the DDCR to reflect the removal of RNs from the DVM domain.

  • An RN or its proxy performs a read of the DDCR, comparing the bit-positions previously set in DDCR_Clear, repeating this step until the corresponding bit-positions have been cleared in the DDCR.

    Note:

    It is not valid for the write to DDCR_Clear to have NULL effect on the DDCR. That is, the write before the polling read must have the effect of modifying the DDCR in at least one bit-position. If not, the subsequent read would immediately reflect completion because the new value equals the old value, and therefore the atomicity requirement described is not guaranteed.

Before completion of these steps, the RN being removed from the DVM domain must respond to DVM messages sent to it. When these steps are complete, the RNs are excluded from the global DVM domain and are guaranteed not to receive any subsequent DVM messages.

}

Non-ConfidentialPDF file icon PDF versionARM 100052_0001_00_en
Copyright © 2014, 2015, 2017 ARM Limited or its affiliates. All rights reserved.