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

A72 ACP deadlock

1. GDMA writes to the ACP port and is backpressed, resulting in GDMA reads being backpressed. The memory channel on the GDMA read chip and the memory channel on the A72 read chip are the same channel, so the memory operation on the A72 read chip is also blocked, and the A72 read is blocked, causing ACP writes to be unable to be released, forming a deadlock

2. The A72 Core has been sending prefetch read operations (0xae0, 0x2b2) to noncpu, resulting in ACP writes being unable to obtain arbitration. The PC pointer has been stuck at 0x51c7dc

add x0,x0,#0xae4    -> PC hanging  at 0x51c7dc
ldr w0,[x0]
add x1,x1,#0xae0
ldr w1,[x1]                -> speculative read 0xae0
udiv w2,w0,w1
mul w1,w2,w1
sub w0,w0,w1
and w0,w0,#0x1FFFF
and w1,w0,#0xFFFF
ldrh w0,[sp,#34]       -> speculative read 0x2b2

3. On chip memory is a device attribute

After analyzing RTL, there are two solutions:

1) Configure the on-chip memory MMU attribute to write back write allocate read allocate. This will generate a pass signal, mask prefetch reads, and unblock the ACP port write path

2) Configure L2 Auxiliary Control Register bit [1] to enable the replay threshold timeout attribute. After waiting for a certain amount of time, ACP port writes will obtain arbitration rights, and the ACP port write path will be unblocked

My question is, are the above two solutions the real solutions?

If so, I would like to know the design intention: why must the instruction area be set to cacheable in order to avoid ACP port deadlock? If there is cache miss or other device access, is there also a possibility of hanging? Is there any other side effect of configuring L2 Auxiliary Control Register bit [1]?

If not, are there any other solutions?