---
title: "양쪽이 지원해도 함께 켤 수 없는 링크 기능"
author: "브레이브브라우저쓰자"
published_at: "2026-10-30T04:51:04.046Z"
updated_at: "2026-10-06T03:18:57.549Z"
tags: ["ucie parameter negotiation"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%EC%96%91%EC%AA%BD%EC%9D%B4-%EC%A7%80%EC%9B%90%ED%95%B4%EB%8F%84-%ED%95%A8%EA%BB%98-%EC%BC%A4-%EC%88%98-%EC%97%86%EB%8A%94-%EB%A7%81%ED%81%AC-%EA%B8%B0%EB%8A%A5"
ai_assisted: true
---

# 양쪽이 지원해도 함께 켤 수 없는 링크 기능

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/%EC%96%91%EC%AA%BD%EC%9D%B4-%EC%A7%80%EC%9B%90%ED%95%B4%EB%8F%84-%ED%95%A8%EA%BB%98-%EC%BC%A4-%EC%88%98-%EC%97%86%EB%8A%94-%EB%A7%81%ED%81%AC-%EA%B8%B0%EB%8A%A5)

두 die가 각각 좋은 기능을 많이 지원해도 함께 켤 수 있는 기능은 더 적을 수 있다. UCIe parameter negotiation은 양쪽의 목록을 단순히 이어 붙이는 과정이 아니다. 같은 프로토콜을 같은 전송 형식으로 사용할 수 있는지 확인하고, 필요한 기능이 빠졌을 때 진행을 멈출 수 있어야 하는 합의다.

## 물리층 훈련이 끝난 뒤에도 합의가 남는다

UCIe 2.0 원문은 링크 초기화에서 물리층 훈련 이후 어댑터가 로컬 capability를 정하고 상대와 파라미터를 교환한 뒤 FDI를 Active로 만드는 순서를 설명한다. 링크 속도와 구성이 주어졌을 때 retry가 필요한지도 이 과정에서 확인한다. 물리층의 RDI Active를 상위 프로토콜의 FDI Active와 같은 표시로 읽으면 단계가 생략된다. [원문 60–61쪽, 3.2.1절](https://tmng-al.uspto.gov/resting2/api/casedoc/cms/case/99231699/tmdocument/20250612064611159321SPE0012.pdf)

광고할 수 있는 capability도 하드웨어에 블록이 있다는 사실만으로 정해지지 않는다. 연결된 프로토콜 계층과 실제로 활성화한 구성까지 해당 조건을 만족해야 한다. 지원하지만 현재 쓰지 않는 기능, 사용할 수 없는 스택, 다른 기능과 함께 켤 수 없는 조합을 구별한다.

## 공통 형식 하나가 있어도 충분하지 않은 예

설명용으로 두 Streaming 구현의 활성 구성을 비교하자. A는 68B 형식과 Standard 256B Start Header 형식을, B는 68B 형식만 지원한다고 정한다. 형식의 공통 후보는 68B다. A가 자신의 더 큰 형식을 일방적으로 선택하면 B가 읽을 수 없다.

이번에는 A는 retry를 지원하고 B는 지원하지 않는다고 하자. Raw가 아닌 이 구성에서 링크의 조건상 어댑터 retry가 필요하다고 정하면, 공통 68B 후보만으로 운영을 시작할 수 없다. 원문도 Raw 예외를 제외하고 retry가 필요한데 광고·협상되지 않으면 링크가 operational일 수 없다고 규정한다. 형식의 교집합과 필수 기능의 충족은 별도의 조건이다.

검토용 조건을 `공통 프로토콜 있음 ∧ 공통 합법 형식 있음 ∧ 필요한 retry 확보`처럼 적을 수 있다. 첫 두 항이 참이어도 마지막 항이 거짓이면 전체는 거짓이다. 이것은 필드의 실제 인코딩이나 표준 전체의 선택 알고리즘을 대신하는 구현 코드가 아니라, 기능 목록의 겹침만 보는 판단을 막는 논리 예다.

## 값을 정하는 주체와 절차도 프로토콜별로 다르다

PCIe나 CXL의 교환에서는 DP가 광고하고 UP가 이를 검토해 자기 capability를 광고한 뒤 DP가 최종 구성 메시지를 보낸다. 해당 조건에서는 CXL 관련 세부 교환도 이어진다. 공식 튜토리얼 그림은 이 왕복 순서를 보여 준다. [PDF 22쪽, 슬라이드 46](https://hc2023.hotchips.org/assets/program/tutorials/ucie/UCIe%20Protocol.pdf)

그 절차를 Streaming에 그대로 적용하면 안 된다. UCIe 2.0 원문에서는 Streaming의 파라미터 교환에 DP·UP 구분이 없고 양쪽이 각각 광고하며, 그 스택에는 FinCap 메시지를 보내지 않는다. 최종 형식은 광고된 조건과 정해진 resolution 규칙으로 결정한다. 필요한 vendor-specific 합의도 따로 정할 수 있다. [원문 63–65쪽, 3.2.1.2절](https://tmng-al.uspto.gov/resting2/api/casedoc/cms/case/99231699/tmdocument/20250612064611159321SPE0012.pdf)

따라서 ‘A가 선택값을 B에게 통보하면 끝’이라는 자체 흐름을 표준의 모든 경우로 확대할 수 없다. 어느 쪽이 어떤 메시지를 먼저 보낼 수 있는지, 어느 메시지가 조건부인지, 합의 결과를 상위에 언제 반영하는지 구성을 기준으로 읽는다.

## 호환 모드로 내려가는 데도 조건이 있다

지원 기능이 다르다고 무조건 가장 단순한 모드로 바꾸는 것도 위험하다. 양쪽이 그 모드를 지원하고 활성화할 수 있어야 하며, 상위가 필요로 하는 오류 처리와 프로토콜 의미도 만족해야 한다. Raw로 바꾸면 어댑터 retry를 사용하지 않는다는 책임의 변화가 생긴다. 실패를 숨기려고 한쪽만 형식을 바꾸면 다음 바이트부터 해석이 갈라진다.

합의가 진행되지 않을 때는 무한히 기다리기보다 정해진 timeout과 오류 처리를 따른다. UCIe 2.0에는 유효한 프로토콜이나 flit 형식을 결정하지 못했을 때의 Invalid Parameter Exchange 상태도 정의되어 있다. 문제를 ‘링크가 느리다’로 남기는 것보다 어느 필수 조건에서 합의하지 못했는지 기록하는 편이 원인을 좁힌다.

UCIe parameter negotiation의 결과는 양쪽이 가진 최고의 기능이 아니라, 양쪽과 현재 사용 조건이 함께 허용하는 운영 구성이다. 프로토콜·형식의 공통 후보를 찾고, 필수 기능과 조합 제약을 확인한 뒤, 해당 절차로 상위의 전송을 시작한다. 이렇게 읽으면 호환 가능한 연결과 기대한 기능을 모두 제공하는 연결의 차이가 명확해진다.