𝗔𝗫𝗜 │ Exclusive write의 OKAY가 위험한 이유
AXI exclusive write BRESP=OKAY: suppressed write at a supporting target versus updated memory at an unsupported target
원자적 갱신을 검증하는데 exclusive write의 BRESP=OKAY가 나왔습니다. “경합 때문에 write가 취소됐겠지”라고 보고 넘어가면 위험합니다. 같은 OKAY여도 대상이 exclusive monitor를 지원하는지에 따라 메모리 값이 달라질 수 있습니다.
Exclusive access는 먼저 read로 주소를 예약하고, 나중에 write할 때 그 사이 다른 writer가 값을 바꾸지 않았는지 확인하는 방식입니다. 예약이 성립한 read의 RRESP는 EXOKAY입니다. 이후 write가 성공하면 BRESP=EXOKAY와 함께 값이 갱신됩니다.
32-bit 한 beat를 주소 0x1000에 쓰는 예를 보겠습니다. M0가 ID 3으로 exclusive read를 마쳤고 RRESP=EXOKAY를 받았습니다. 그 뒤 M1이 같은 주소를 0x22로 썼습니다. M0가 같은 ID·주소·전송 속성으로 0x33을 exclusive write하면, monitor가 경합을 감지합니다. 지원되는 대상은 BRESP=OKAY를 돌려주고 M0의 0x33은 저장하지 않습니다. 메모리에는 0x22가 남습니다.
이번에는 대상이 exclusive access를 지원하지 않는다고 해보겠습니다. M0의 exclusive read는 유효한 데이터를 돌려주지만 RRESP=OKAY입니다. 예약은 만들어지지 않았습니다. 그런데 M0가 이를 무시하고 exclusive write로 0x33을 보내면, 규격상 그 대상은 BRESP=OKAY를 돌려주면서도 주소를 갱신합니다. 앞 사례와 BRESP는 같지만 메모리에는 0x33이 남을 수 있습니다.
따라서 manager는 exclusive read가 EXOKAY였는지 확인한 뒤 write를 진행해야 합니다. Arm 규격도 read가 OKAY라면 write 부분을 진행하지 않을 것을 권고합니다. BRESP=OKAY 하나만으로 “write가 취소됐다”고 판정하는 scoreboard는 두 상황을 구별하지 못합니다.
검증에서는 세 경로를 따로 보겠습니다. ① 예약 성공 후 경합 없음: EXOKAY, 새 값 저장. ② 예약 성공 후 경쟁 write: OKAY, exclusive write 억제. ③ 예약 미지원: read부터 OKAY, write를 보내지 않는 manager 동작 확인. 대상 IP의 exclusive 지원 여부와 interconnect가 monitor까지 요청을 전달하는지도 함께 확인해야 합니다.
근거: Arm AMBA AXI Protocol Specification, IHI 0022 Issue L (2025), §A6.3 Exclusive accesses.
https://documentation-service.arm.com/static/68b03beb01ae952d9559f9eb