전선 앞의 어댑터가 네 바이트를 더하는 이유
프로토콜 계층에서 보낸 64바이트가 물리 링크에서는 68바이트가 될 수 있다. 그 네 바이트에는 전송의 해석과 오류 검사에 필요한 정보가 들어간다. UCIe adapter는 단순히 두 버스의 폭을 맞추는 블록으로만 보면 부족하다. 어떤 모드에서 무엇을 붙이고, 언제 전송을 시작하며, 실패한 전송을 누가 복구하는지 결정하는 경계다.
프로토콜과 전선 사이의 역할
상위 프로토콜은 요청과 응답의 의미를 정하고, 물리층은 전기 신호와 링크 훈련을 처리한다. 어댑터는 그 사이에서 링크 상태와 파라미터를 관리하며, 해당 모드에서는 CRC와 재전송을 맡는다. 여러 프로토콜을 공유하는 구성에는 중재와 선택도 들어간다. 공식 튜토리얼은 상위와의 FDI, 물리층과의 RDI를 나누어 이 기능을 배치한다. PDF 10쪽, 슬라이드 34
두 인터페이스가 모두 데이터 버스라고 해서 같은 상태를 노출하는 것은 아니다. 물리층이 훈련을 끝내도 상위와 사용할 형식의 합의가 남을 수 있다. 반대로 상위가 데이터를 보낼 준비가 되어도 링크 상태나 복구 과정 때문에 당장 전송할 수 없을 수 있다. 데이터 경로와 상태 경로를 함께 읽어야 이 기다림을 설명할 수 있다.
추가된 네 바이트를 정확히 센다
68B 형식의 예에서는 프로토콜 정보 64B에 어댑터가 헤더 2B와 CRC 2B를 더한다. CRC는 이 헤더와 64B 정보를 검사한다. 헤더에는 프로토콜·스택 식별이나 순서와 관련한 전송 정보가 들어간다. 상위의 명령 내용과 링크 전송의 메타데이터가 같은 역할을 하는 것은 아니다. 공식 튜토리얼 PDF 13쪽, 슬라이드 37
이 형식만의 비율을 계산하면 프로토콜 정보는 64/68≈94.12%다. 추가한 바이트는 전체의 약 5.88%다. 여기서 64B 전부가 애플리케이션의 유효 데이터라는 뜻은 아니다. 상위 프로토콜의 헤더가 그 안에 있을 수 있다. 또한 pause, idle, 재전송 등을 제외한 형식의 비율이므로 실제 측정 대역폭을 그대로 뜻하지도 않는다.
별도의 자체 바이트 포장기를 생각해 보자. 16B씩 내보내는 인터페이스로 68B 단위 여덟 개를 연속해서 운반하면 총 544B, 즉 34번의 전송이 필요하다. 단위마다 다섯 번씩 따로 반올림하면 40번이 되어 남는 자리를 매번 버리게 된다. 여러 단위의 바이트를 이어 담는 포장과 단위마다 정렬하는 포장을 구별해야 하는 이유다.
이 34회는 실제 UCIe 링크의 전체 framing을 재현한 수치가 아니다. 연속 바이트 포장만 분리한 가상 계산이다. 실제 형식의 중단 표시와 링크의 전송 규칙까지 넣어야 완전한 비용을 얻는다. 원문이 68B의 바이트 이동 처리를 별도로 설명하는 것도 데이터 폭으로 한 번 나누는 계산만으로는 부족하기 때문이다.
Raw를 고르면 복구의 담당자가 달라진다
Raw 형식에서는 어댑터 데이터 경로가 프로토콜 계층의 바이트를 수정하거나 추가하지 않고 전달하며, 어댑터의 CRC·retry 경로를 우회한다. 그러므로 어댑터가 어떤 모드에서도 같은 오류 복구를 제공한다고 생각하면 안 된다. 필요한 신뢰성을 상위나 다른 경로가 어떻게 확보하는지 통합 조건에 들어간다. 공식 튜토리얼 PDF 12쪽, 슬라이드 36
버전도 함께 확인한다. UCIe 1.0의 Streaming은 Raw 형식을 사용했지만, 1.1은 기존 Raw 지원을 유지하면서 Streaming이 어댑터의 CRC·retry·전력 관리 기능을 활용할 수 있도록 확장했다. ‘Streaming을 사용한다’는 문장만으로 그 기능이 켜졌다고 판단할 수 없다. UCIe 1.1 원 백서 2쪽
같은 자원을 쓸 때도 상태를 구별한다
여러 상위 스택이 어댑터를 공유하면 물리 링크의 용량도 공유한다. 각 스택이 개별 테스트에서 링크 전체 속도를 냈다고 동시에 그 속도를 낼 수 있는 것은 아니다. 스택 구분, 중재, 수신 가능량과 상태 전이의 독립성을 설정한 구성대로 확인한다. 링크의 전력 상태를 바꾸는 동안 남아 있는 전송을 어떻게 처리하는지도 중요하다.
UCIe adapter를 평가하는 방법은 기능 목록의 길이를 비교하는 데서 끝나지 않는다. 실제로 협상한 모드에 따라 바이트 형식, 전송 허용 상태, 오류 복구의 책임, 공유 용량을 따라간다. 이 경계를 명확히 하면 상위 프로토콜을 바꿨을 때 유지되는 공통 기능과 다시 검증할 통합 계약을 구별할 수 있다.