준비된 상대만 기다리는 AXI 송신기가 멈추는 이유

송신기가 ready를 확인한 뒤 valid를 올리도록 만들면 예의 바른 회로처럼 보인다. 상대가 준비되지 않았는데 데이터를 밀어 넣지 않겠다는 생각이다. AXI에서는 이 판단 때문에 양쪽이 영원히 서로를 기다릴 수 있다. valid는 상대의 수락 신호를 보고 내는 허락 요청이 아니라, 송신할 정보가 준비되어 있다는 약속이기 때문이다.

AXI valid 의존성의 기본 규칙은 방향이 비대칭이다. 송신자는 ready가 올라올 때까지 valid를 기다리면 안 된다. 수신자는 valid를 본 뒤 ready를 올릴 수 있다. 두 규칙을 함께 적용하면 아직 수신자가 준비 신호를 내지 않았어도 송신자가 먼저 요청을 보이고, 수신자가 이를 확인해 전송을 시작할 수 있다. Arm IHI0022H, A3.2.1·A3.3.1

두 상태기계로 재현해 보자. 송신기에는 보낼 값 0x35가 이미 있다. 하지만 잘못된 송신기는 ready=1을 관찰해야 valid를 1로 바꾼다. 수신기는 valid=1을 관찰해야 ready를 1로 바꾼다. 리셋 뒤 둘 다 0이라고 하자. 첫 경계에서 송신기는 ready=0이므로 아무것도 하지 않는다. 수신기도 valid=0이므로 아무것도 하지 않는다. 다음 경계의 상태가 처음과 같아서 이 패턴이 계속 반복된다.

ready를 기본 1로 두는 수신기와 시험하면 같은 송신기가 동작할 수 있다. 그렇다고 송신기가 규칙을 지킨 것은 아니다. 연결 상대가 valid를 기다리는 합법적인 구현으로 바뀌면 교착이 드러난다. 정상 입력의 데이터 계산을 몇 번 통과했는지만으로 인터페이스의 조합 가능성을 보장할 수 없는 이유다.

규칙을 지키는 가상 송신기는 내부 큐가 비어 있지 않으면 valid를 올린다. ready가 0이면 맨 앞 값을 그대로 제시하고, valid와 ready가 함께 1인 상승 경계에서만 큐의 맨 앞 값을 꺼낸다. 이미 값이 준비되었는지는 내부 상태로 판단하며, 꺼내도 되는지는 handshake로 판단한다.

이 표에서 경계 2와 3은 같은 요청을 기다리는 시간이다. 값 두 개를 보낸 것이 아니다. 경계 4 뒤에는 첫 요청이 끝났으므로 다음 값을 제시할 수 있다. 연속한 두 경계에서 전송하려고 valid를 반드시 중간에 0으로 내릴 필요도 없다. 다만 valid가 계속 1이라면 매 handshake가 별도의 수락 사건이라는 점을 정확히 세어야 한다.

반대로 경계 3에서 아직 ready=0인데 payload를 0x46으로 바꾸면 첫 값 0x35가 수락되기 전에 사라진다. AXI는 valid를 올린 정보를 handshake까지 안정적으로 유지하도록 요구한다. valid가 유지되어도 주소·데이터·제어 중 하나가 바뀌면 같은 약속을 지킨 것이 아니다. 이 조건을 점검할 때는 데이터 비트뿐 아니라 해당 채널의 길이·크기·ID·마지막 표시 등 함께 전송하는 정보도 포함해야 한다. Arm IHI0022H, A3.2의 Handshake process

쓰기 채널 사이에도 비슷한 함정이 있다. 송신자가 AWREADY가 올 때까지 WVALID를 내지 않고, 수신자가 WVALID를 본 뒤 AWREADY를 올리면 같은 순환이 생긴다. 주소와 데이터가 모두 준비되어 있는 경우에도 첫 전송을 시작하지 못한다. Arm의 규격은 이 경우를 교착 예로 직접 든다. AWVALID와 WVALID의 생성은 AWREADY·WREADY를 기다리는 방식으로 묶으면 안 된다.

다만 “valid는 기다리지 않는다”를 모든 원인에 대한 무조건적인 규칙으로 확대하면 다른 오류가 된다. 실제 주소가 준비되지 않았으면 AWVALID를 올릴 수 없고, 읽기 응답은 읽기 요청을 수락한 뒤에야 만들 수 있다. AXI4의 쓰기 BVALID 역시 주소와 마지막 데이터의 수락이라는 선행 조건을 갖는다. 금지된 것은 수신자의 ready를 valid 발생의 조건으로 삼는 의존성이지, 아직 존재하지 않는 정보를 만들어 전송하는 것이 아니다. Arm IHI0022H, A3.3의 AXI4 write transaction dependencies

ready가 계속 0인 환경에서 모든 거래가 언젠가 끝난다는 보장은 별도 문제다. 상대가 결국 수락한다는 가정이 없으면 올바른 송신기라도 정상적으로 기다릴 수밖에 없다. 따라서 요청 보존 조건과 진행 조건을 구분해서 확인해야 한다. 전자는 기다리는 동안 데이터가 사라지지 않는지, 후자는 수락 기회가 실제로 제공되는지를 묻는다.

AXI 송신기를 검토할 때 준비된 정보가 있는데 valid를 못 내는 이유를 따라가 보자. 그 끝이 ready라면 상대의 선택에 따라 막힐 수 있는 의존성이 들어간 것이다. 내부 준비 상태로 valid를 만들고, handshake로 소비를 결정하며, 대기 중 정보를 보존한다는 세 가지를 분리하면 송신기와 수신기가 서로 다른 정책을 써도 연결할 수 있다.