𝗔𝗛𝗕-𝗟𝗶𝘁𝗲 │ HREADY가 0인데 다음 주소를 저장하면 왜 꼬일까?

AHB-Lite slave가 연속 write A, B를 받습니다. 파형에서는 B의 HADDR가 이미 보이는데, A에 wait state가 들어간 뒤 B가 두 번 처리되거나 A의 데이터가 B 주소에 써집니다. 주소와 데이터가 한 cycle 어긋나는 AHB-Lite에서 흔한 디버깅 장면입니다.

AHB-Lite는 주소 단계와 데이터 단계를 겹쳐 보냅니다. 현재 bus에 보이는 HADDR는 다음 전송의 주소일 수 있고, HWDATA는 이전 전송의 데이터일 수 있습니다. slave는 주소와 제어 신호를 data phase에 사용할 수 있도록 보관해야 합니다.

같은 slave로 가는 단일 write A와 B를 보겠습니다. 둘 다 HTRANS=NONSEQ, HRESP=OKAY이고, E0~E3는 연속 rising edge입니다.

E0: HREADY=1. 주소 A를 수락합니다.
E1: HADDR=B, HWDATA=A의 데이터, HREADY=0. A의 data phase는 끝나지 않았고 B의 주소도 아직 수락되지 않았습니다.
E2: HADDR=B와 A의 HWDATA가 그대로 유지되고 HREADY=1. 이 edge에서 A가 완료되며, 동시에 B의 주소를 수락합니다.
E3: B의 HWDATA와 HREADY=1. B가 완료됩니다.

핵심은 E1입니다. HADDR=B가 보인다는 이유만으로 B를 저장하면 E2에서 다시 수락하거나, 더 나쁘게는 A의 HWDATA를 B 주소에 쓸 수 있습니다. Arm 사양은 slave가 HSELx·주소·제어를 HREADY=1일 때만 샘플하도록 규정합니다. write data는 wait state 동안 master가 안정적으로 유지합니다.

RTL에서는 address phase가 수락된 edge에 주소·HWRITE·HSIZE·유효 여부를 저장하고, 그 저장된 이전 전송의 정보로 data phase를 처리하세요. E2에서는 이전에 저장한 A로 write를 끝내면서, 같은 edge에 새 B를 다음 data phase용으로 저장할 수 있습니다. 현재 HADDR와 현재 HWDATA를 바로 묶지 않는 것이 포인트입니다.

리뷰할 때는 HREADY=0인 동안 B의 주소 수락이 반복되지 않는지, A의 write data가 completion edge까지 유지되는지, E2에서 A 완료와 B 주소 수락이 한 번씩 일어나는지 확인해 보세요. IDLE/BUSY와 ERROR 응답에는 주소·HTRANS 변경의 별도 허용 규칙이 있으므로, 이 예시의 “B 유지”를 모든 상황의 절대 규칙으로 일반화하면 안 됩니다.

근거: Arm, AMBA 3 AHB-Lite Protocol Specification, IHI 0033A, §§1.2, 3.1, 3.6, 4.1
https://documentation-service.arm.com/static/5f914801f86e16515cdc2a27