자체 프로토콜을 운반할 때 실행 순서도 함께 옮겨야 한다

자체 프로토콜의 바이트를 UCIe로 보낼 수 있으면 원래 버스의 동작도 그대로 옮겨진 것일까. UCIe Streaming은 상위 메시지를 운반하는 선택지를 제공하지만, 그 메시지의 실행 순서와 완료 의미를 새로 만들어 주는 것은 아니다. 통합에서는 바이트 형식뿐 아니라 원래 요청이 의존했던 계약을 매핑해야 한다.

운반할 형식과 실행할 의미를 나눈다

UCIe 2.0은 Streaming에 Raw와 지원 capability에 따른 flit 형식을 설명하며, 상위 프로토콜의 interoperability는 vendor-defined로 남긴다. 68B 형식에서는 상위가 64B를 제시하고 어댑터가 헤더와 CRC를 붙이는 경로를 정의한다. 이 구조가 자체 요청의 주소나 응답 코드를 대신 정하는 것은 아니다. 원문 54–55쪽, 2.4절

버전과 모드도 함께 본다. UCIe 1.1은 Streaming이 어댑터의 복구와 전력 관리 기능을 활용하는 구성을 추가했다. 그 기능을 활용할 수 있다는 것과 실제로 협상·활성화했다는 것은 다르다. UCIe 1.1 원 백서 2쪽

메시지의 경계를 정할 때는 길이, 종류, 식별자, 바이트 순서와 부분 데이터의 의미를 정의한다. flit 하나에 메시지 하나가 정확히 들어간다는 조건이 없다면 여러 flit의 조립 완료와 빈 바이트 처리도 필요하다. 링크의 flit 경계를 곧바로 명령 실행 경계로 쓰면 긴 메시지의 앞부분만 보고 실행할 수 있다.

먼저 보낸 쓰기보다 읽기가 먼저 실행되는 예

자체 프로토콜에서 같은 주소 X의 쓰기 뒤 읽기는 쓰기의 결과를 보도록 정했다고 하자. 초기 X는 0이다. 송신기는 W라는 ‘X에 12 쓰기’ 메시지를 먼저, R이라는 ‘X 읽기’ 메시지를 다음에 보낸다. 수신기는 두 메시지를 순서대로 정확히 복원했다.

그런데 W를 느린 작업 대기열로 보내 시간 5에 반영하고, R은 별도의 빠른 경로에서 시간 2에 실행하면 R은 0을 돌려준다. 전송 바이트와 수신 순서가 모두 정상이어도 자체 상위 계약을 위반했다. 메시지의 도착 순서와 부작용의 완료 순서는 같은 것이 아니다.

해결 방법은 원래 계약에 맞춰 정한다. 같은 순서 domain에서 R이 W의 완료를 기다리도록 하거나, W의 결과가 보이는 완료 응답을 확인한 뒤 R을 보내는 정책을 사용할 수 있다. 위 모델에서 R을 W의 반영 이후인 시간 6에 실행하면 12를 읽는다. 이 시간은 실제 UCIe 지연이 아닌 실행 순서의 자체 반례다.

원래 프로토콜이 서로 다른 ID의 요청을 독립적으로 처리하도록 허용한다면 모든 요청을 하나의 전역 순서로 묶는 것도 불필요할 수 있다. 필요한 의존 관계만 보존해야 병렬성을 유지한다. 반대로 응답 순서가 바뀔 수 있는 구성이라면 식별자와 outstanding 표를 사용해 어느 요청의 결과인지 구별한다.

응답할 공간을 요청이 모두 차지하면 생기는 일

자체 양방향 장치 A와 B에 각각 수신 슬롯 하나만 있다고 하자. 각 슬롯에 상대의 요청이 들어 있고, 이 구현은 응답이 상대에게 받아들여질 때까지 그 요청 슬롯을 유지한다. 응답도 같은 수신 슬롯을 요구하면 A의 응답은 B의 요청 때문에, B의 응답은 A의 요청 때문에 못 들어간다. 바이트를 보낼 전선이 있어도 진행이 멈춘다.

응답을 받을 별도 슬롯을 예약하는 자체 정책을 적용하면 이 조합에서는 응답을 받아 요청 슬롯을 해제할 수 있다. 필요한 credit과 대기열을 나누는 이유는 전송 속도를 올리는 것만이 아니라, 응답이 있어야 풀리는 요청이 응답 공간을 막지 않게 하는 데 있다. 다른 자원 의존이 남으면 별도로 분석해야 하므로 이 작은 수정이 모든 시스템의 deadlock을 해결한다고 확대하지 않는다.

이 사례 역시 UCIe 표준이 이 슬롯 구조를 요구한다는 설명이 아니다. Streaming 위에 자체 요청·응답을 올렸을 때 통합 설계가 책임져야 하는 흐름 제어다. 도구가 bytes를 정상적으로 옮기는 시험만 해서는 이 순환을 발견하기 어렵다.

상위 계약을 관측 가능한 사건으로 만든다

시험에서는 메시지 접수, 실행 시작, 부작용 반영, 응답 생성과 소비를 구별한다. W를 지연시킨 상태에서 R을 보내 결과를 확인하고, 응답을 막은 상태에서 요청 공간이 어떻게 점유되는지 센다. 같은 ID의 재사용과 부분 메시지, reset 중의 outstanding 요청도 원래 계약대로 처리해야 한다.

UCIe Streaming의 장점은 자체 프로토콜을 정의된 die-to-die 전송 경로와 결합할 수 있다는 데 있다. 그 장점을 살리려면 원래 프로토콜의 의미를 bytes에 담는 것에서 멈추지 않고, 실행 순서·완료·응답 공간까지 보존한다. 전달된 데이터가 같은 기능을 만들었는지 확인해야 프로토콜 매핑이 끝난다.