𝗔𝗫𝗜 𝗥𝗘𝗔𝗗 𝗜𝗗 │ 먼저 끝난 응답이 왜 기다릴까?
AXI4 read transaction IDs: same-ID response order, different-ID overtaking, and implementation-specific performance
DMA가 read A와 B를 차례로 요청했습니다. A는 응답이 늦고 B의 데이터는 먼저 준비됐는데, master 쪽에서는 B가 보이지 않습니다. 이럴 때는 메모리 지연만 볼 게 아니라 두 요청의 ARID부터 확인해야 합니다.
예를 들어 둘 다 한 beat를 읽는다고 해보죠. A와 B에 같은 ARID를 붙였다면, AXI는 먼저 요청한 A의 read response가 B보다 먼저 돌아오도록 보장합니다. B가 내부에서 빨리 처리돼도 master에게 A보다 앞서 전달할 수는 없습니다.
B에 다른 ARID를 주면 순서 제약이 달라집니다. B의 response가 A보다 먼저 도착해도 AXI 규칙에 맞습니다. 다만 ‘먼저 올 수 있다’는 뜻이지, interconnect나 memory가 반드시 순서를 바꿔준다는 뜻은 아닙니다. Master는 요청 순서에 기대지 말고 RID로 어느 요청의 데이터인지 찾아야 합니다.
여러 beat를 읽을 때는 한 단계 더 봐야 합니다. ID가 다른 두 read의 데이터 beat는 R channel에서 섞여 올 수도 있습니다. 따라서 outstanding 요청을 ID별로 추적하고, 각 beat의 RID를 확인하며, RLAST가 수락된 시점에 해당 요청을 끝내야 합니다.
그렇다면 ID를 늘리면 성능도 반드시 좋아질까요? 아닙니다. 실제 이득은 interconnect의 reorder buffer와 outstanding 처리 능력, 대상 memory의 동작에 달려 있습니다. AMD Versal NoC 문서는 read마다 내부적으로 고유 ID와 reorder buffer를 사용하기 때문에, master가 single ID를 쓰는지 multiple ID를 쓰는지가 read 성능에 영향을 주지 않는다고 명시합니다. 이 결과를 다른 fabric에 일반화해서도 안 됩니다.
설계 리뷰에서는 세 가지를 확인해 보세요. 같은 ID의 응답 순서가 지켜지는가? 다른 ID의 응답이 먼저 오거나 beat가 섞여도 RID/RLAST로 정확히 조립되는가? 그리고 ID 수를 늘렸을 때 실제 경로의 처리량이 측정상 좋아지는가? 프로토콜이 허용하는 자유도와 구현이 제공하는 성능은 구분해서 봐야 합니다.
근거: Arm AMBA AXI and ACE Protocol Specification, IHI 0022H, §A5.1·§A6.5.3
https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/IHI0022H_amba_axi_protocol_spec.pdf
Arm Introduction to AMBA AXI4, §7.4
https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/102202_0100_01_Introduction_to_AMBA_AXI.pdf
AMD Versal NoC Product Guide PG313, Single ID Versus Multiple ID for AXI Transactions
https://docs.amd.com/r/en-US/pg313-network-on-chip/Single-ID-Versus-Multiple-ID-for-AXI-Transactions