ARM Technical Support Knowledge Articles

ARM946E-S use of HLOCK / Problems with the ARM946E-S in my AHB system when a SWP is executed

Applies to: ARM946E-S


ARM946E Use of HLOCK

The ARM946E will only assert HLOCK when executing a SWP instruction. The SWP instruction is designed for semaphores and allows the ARM core to perform a read followed by a write over the AHB and be guaranteed that no other master has gained access to the bus during this period.

When the ARM946E starts to execute a SWP instruction, it will first request the bus asserting HLOCK, and then continue to hold HLOCK all the way through until after the write has been accepted.

If another access is started by the ARM946E immediately after the SWP instruction has completed, the first beat of the address phase will be marked as locked by HLOCK.

The timing of the HLOCK signal is such that the burst immediately following the SWP write is locked, since HLOCK was asserted immediately prior to the burst starting at the red cursor line. However, the ARM946E has not held the HLOCK signal for the remainder of the burst.

This behavior can cause problems if an arbiter or other component of the AHB expects the HLOCK signal to be held throughout the entire transfer initiated when the signal was asserted.
The ARM946E behaves as shown in the waveform above when all of the following are true:

Under these conditions, the ARM946E will follow the SWP write access with an instruction cache line fill with no IDLE cycle in between.


Hardware Workaround

The following piece of logic can be implemented outside the ARM946E to change the HLOCK output at the end of the LOCked access:

  if (HLOCK && HWRITE && (HTRANS == 2'b10)) then
    HLOCKout = 1'b0;
    HLOCKout = HLOCK;

HREADY has not been factored in to this logic on the assumption that all of the slaves in your AHB system will output HREADY=high when HTRANS=IDLE. If there is a chance that HREADY could be low when the write portion of the SWP transfers is started then you will need to factor HREADY into the above logic.

The RETRY and SPLIT responses are also not factored in to this logic.

Software Workaround

Any one of these solutions will work – they are listed in order of preference:

If none of the above are possible, then some work has to be done to detect where SWP instructions fall on an address which coincides with an I-Cache line read (i.e. where a SWP instruction falls on an address ending 5’b14). You may be able to do this just by disassembling the compiled binary. From this point you could:



Rate this article

Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential