3. PIPE, PCS, PMA와 controller의 책임을 나눈다

CHAPTER 03

3. PIPE, PCS, PMA와 controller의 책임을 나눈다

PIPE는 MAC/Controller와 PHY 사이의 논리 인터페이스입니다. board의 PCIe lane 신호와 동일하지 않으며, PIPE에서 보이는 상태가 analog lane에서 실제로 일어난 사건을 요약한 결과일 수 있습니다. 어떤 PIPE architecture를 썼는지 먼저 확인해야 debug signal의 주인을 올바르게 찾을 수 있습니다.

Tx path

Controller/Data Link/Transaction 계층에서 만들어진 데이터가 PCS encoding과 scrambling, lane distribution을 거쳐 PMA serializer와 transmitter를 통과합니다.

Rx path

PMA의 receiver, CDR와 deserializer를 지난 데이터가 PCS block alignment/decoding을 거쳐 controller의 LTSSM과 Data Link 계층으로 전달됩니다.

Traditional PIPE

PHY가 더 많은 PCS 기능을 포함하고 PIPE가 protocol-specific parallel data와 control을 전달하는 구성이 일반적입니다.

SerDes architecture

PIPE 5.x의 SerDes architecture는 protocol-specific PCS 기능 일부를 controller 쪽으로 이동시켜 PHY를 범용 SerDes에 가깝게 구성할 수 있습니다. 따라서 encoding 관련 error counter가 어느 bank에 있는지 달라집니다.

Rate change

Controller가 target rate와 power state 변경을 요청하고 PHY가 PLL/CDR/rate 전환을 완료한 뒤 status를 돌려줍니다. directed speed change가 멈추면 request와 acknowledgment 양쪽을 함께 봅니다.

Receiver detect

Controller가 detect 동작을 요청하고 PHY가 termination 감지 결과를 반환합니다. PLL lock만으로 receiver detect가 성공했다고 판단할 수 없습니다.

계층별 실제 책임

계층	Tx에서 하는 일	Rx에서 하는 일	대표 관찰값	흔한 오판
Transaction	Memory/Config/Message TLP 생성	TLP routing과 completion 처리	AER, requester/completer ID	TLP 오류를 PHY 오류로 부름
Data Link	sequence/LCRC, replay, credit	ACK/NAK, duplicate/replay 처리	replay/credit/DLL active	L0를 곧 forward progress로 봄
LTSSM/Controller PCS	TS1/TS2, ordered set, 상태 제어	training sequence 해석	LTSSM state/history	controller state를 PHY state로 부름
PHY PCS	encoding/scramble/gearbox 일부	block align/deskew/elastic buffer 일부	block lock, disparity/decoder error	PIPE architecture 차이를 무시
PHY PMA	serializer, swing, preset 적용	receiver, CDR, deserializer	PLL/CDR lock, Rx detect	lock 하나로 link-up 판정
Channel/board	package/trace/connector 전송	loss, crosstalk, reflection 영향	eye/BER/TDR	software 재시도로 SI를 가림

Elastic buffer와 lane de-skew의 역할을 구분한다

Elastic buffer의 클록 허용 오차 보상은 송신·수신 데이터율 차이를 SKP Ordered Set 처리로 흡수하는 일이다. Lane de-skew는 다중 lane 사이의 도착 시점 차이를 맞추는 일이다. 하나의 오류 카운터만으로 두 원인을 같다고 보지 않는다. 블록 위치와 관찰 신호도 PIPE architecture에 따라 다르다. 예를 들어 Synopsys의 PIPE 5.1 SerDes 설명은 elastic-buffer 제어를 MAC이 담당한다고 명시한다. 특정 PHY 그림의 블록 순서나 버퍼 깊이를 다른 구현의 공통 규칙으로 옮기지 않는다.

SKP 주기도 encoding과 세대를 붙여 읽는다. PCI-SIG의 PCIe 3.0 FAQ는 8b/10b의 1180~1538 symbol-times와 8 GT/s 128b/130b의 370~375 blocks를 구분한다. 8 GT/s에서는 송신 예약과 실제 전송 시점도 다르다. 진행 중인 TLP·DLLP와 framing 때문에 실제 간격이 늘거나 줄 수 있으므로 수신 버퍼는 최악의 전송 간격을 감당해야 한다. 이 수치를 Gen5·Gen6의 보편 SKP 주기로 확장하지 않는다.

관련 읽을거리인 Krishnan Babu의 elastic-buffer 개요와 구분해, 실측 기록에는 common clock·SRNS·SRIS 조건, 협상 속도·폭, SKP 처리와 lane별 오류를 함께 남긴다. 공통 REFCLK 구성에 분리 클록의 최악 편차를 그대로 적용하거나, underflow·overflow만으로 채널 불량 또는 클록 원인을 확정하지 않는다.

링크가 올라왔는데 TLP가 멈춘다면

물리 LinkUp을 확인했다고 해서 TLP 전송 준비까지 끝난 것은 아닙니다. 기존 비-FLIT PCIe 링크의 흐름 제어는 인접한 수신 측의 버퍼를 보호하며, 가상 채널별로 Posted, Non-Posted, Completion을 나눕니다. 각 종류의 헤더와 데이터 크레딧도 별개이므로 한 개의 합계만 확인하면 부족한 풀을 놓칠 수 있습니다.

TLP 종류	헤더	데이터
Posted	PH	PD
Non-Posted	NPH	NPD
Completion	CplH	CplD

데이터 크레딧 한 단위는 16바이트, 헤더 크레딧 한 단위는 3 또는 4 DW 헤더에 해당합니다. 실제 초기 크레딧은 IP 구성과 수신 버퍼 할당에 따라 확인합니다. AMD PG054의 fc_*를 읽을 때도 선택값이 송신/수신 중 어느 쪽인지, 가용량/한도/소비량 중 무엇인지 구분해야 합니다. PG054: 여섯 풀과 크레딧 단위

InitFC1과 InitFC2는 헤더와 데이터의 다른 이름이 아니라 초기화 단계입니다. UG197의 l0dlupdown은 InitFC1에서 InitFC2로의 전이를, l0dllvcstatus는 해당 가상 채널의 흐름 제어 초기화 완료를 나타냅니다. 초기화 후 UpdateFC는 수신 버퍼에서 공간이 다시 사용 가능해졌음을 알리는 크레딧 갱신이며, 소프트웨어 요청의 완료 통지가 아닙니다. UG197 v1.6: 초기화 상태(p.46), 크레딧 갱신(pp.63–64)

AMD PG156의 cfg_phy_link_status도 10(물리 링크 연결, DL 초기화 진행)과 11(물리 링크 연결, DL 초기화 완료)을 구분합니다. 이 비트값은 해당 IP의 예시이지 모든 컨트롤러에 공통인 레지스터 정의가 아닙니다. 따라서 먼저 물리 링크와 Data Link 준비 상태를 따로 확인하고, 다음으로 전송할 TLP의 정확한 크레딧 풀을 확인합니다. 크레딧이 충분해도 트랜잭션 성공까지 보장되지는 않습니다. PG156: 물리 링크와 DL 초기화 상태

관련 읽을거리: AI2VLSI의 PCIe Flow Control Part 1과 Part 2. 위 설명은 해당 제조사 문서의 신호와 적용 범위를 기준으로 구분했습니다.

TC·VC를 나눠도 지연이 사라지지는 않습니다

Traffic Class(TC)는 TLP의 분류이고 Virtual Channel(VC)은 포트가 매핑하는 전송 자원입니다. TC0→VC0는 필수지만 추가 TC·VC 지원은 선택적입니다. 요청자가 의도한 TC를 생성하고 경로의 root port·switch·endpoint가 매핑과 활성화를 지원해야 합니다. P·NP·Completion이라는 종류만으로 VC가 자동 분리되지 않으며, VC0 하나에서도 앞 절의 여섯 크레딧은 구분됩니다.

다중 VC는 한 흐름의 크레딧 부족이 다른 흐름에 미치는 영향을 줄일 수 있지만, 동일 출력 링크의 전송 시간과 중재는 남습니다. 패킷 크기·경쟁 부하·중재 정책 없이 지연 상한을 보장할 수 없습니다. PCIe 6.0의 Shared Flow Control은 공유 크레딧과 수신 버퍼 사용 한도를 지원하므로 모든 세대의 VC가 물리적으로 완전히 분리된 버퍼를 갖는다고 단정하지 않습니다.

서로 다른 TC 간의 순서 보장을 가정해 descriptor 게시와 doorbell을 임의로 분리하지 않습니다. 메모리 BAR의 MMIO doorbell은 보통 posted Memory Write이므로 그 쓰기에 Completion TLP가 돌아온다고 기대하지 않습니다. 요청→Completion과 doorbell→장치 완료는 서로 다른 측정 구간입니다.

실제 시스템에서는 TC 생성·포트 매핑·활성 상태와 중재 정책을 기록하고, 같은 링크의 경쟁 부하 유무를 나눠 측정합니다. 크레딧 부족·egress 점유·replay·링크 전원 상태와 호스트 메모리 경로를 가능한 관측 범위에서 분리합니다. 이 절은 특정 스위치의 버퍼 깊이나 실측 지연을 제시하지 않습니다.

PCIe Base 2.1: §2.5·§6.3 · PCI-SIG: PCIe 6.0 공유 흐름 제어 · Linux I/O ordering · DMA·MMIO 실행 경로

PIPE에서 확인할 사건과 양쪽 증거

사건	Controller 요청	PHY 응답/상태	다음 LTSSM 변화	불일치 해석
Receiver detect	detect request	lane별 detect result	Detect.Active→Polling	termination/PHY path 확인
Power state	P0/P1/P2/P3 요청	power state 완료	L0/L0s/L1/L2 전환	clock/power gate latency
Rate change	Gen target/rate request	PLL/rate complete	Recovery.Speed 진행	PHY PLL profile와 timeout
Electrical idle	TxElecIdle	RxElecIdle 판단	Polling/Recovery/power state	threshold와 lane 상태
Rx status	수신 데이터 해석 요청	decode/elastic status	TS/ordered set 처리	PCS 위치와 error source
Equalization control	preset/coefficient 요청	적용/FOM/status	Recovery.Equalization phase	controller와 PHY mailbox 경계

그림 1. 「3. PIPE, PCS, PMA와 controller의 책임을 나눈다」의 실행 순서왼쪽부터 신호나 데이터를 처리하는 순서를 나타냅니다. 각 단계에서 확인할 항목을 함께 표시했습니다.

01 TLP

02 Data Link/LCRC

03 LTSSM·Controller PCS

04 PIPE

05 PHY PCS/PMA

06 package·board channel

07 Endpoint PHY

08 Endpoint Controller

실제 검증 절차

순서	실행	남길 증거	판정 목적
1	integration 문서에서 PIPE version, data width, clock mode와 SerDes architecture 여부를 적습니다.	합성 report와 RTL wrapper port가 일치	debug signal 위치를 확정
2	LTSSM state와 PHY status를 동일 timestamp로 sampling합니다.	state transition 직전/직후 요청·응답 쌍	처음 어긋난 PIPE handshake 식별
3	lane별 receiver detect, block lock, error counter를 분리합니다.	모든 연결 lane가 같은 단계까지 진행	x4→x1 축소의 물리 lane 식별
4	Gen1 고정과 목표 generation을 비교합니다.	Gen1은 안정적이고 상위 Gen만 실패하는지	기본 연결과 equalization/SI를 분리

주의PIPE debug bus 이름과 bit 배치는 integration마다 다를 수 있습니다. 공개 Linux register offset을 PIPE signal offset처럼 쓰지 않습니다.

크레딧 여유와 순서상 통과 가능성은 별개입니다

수신 버퍼 크레딧은 전송량의 조건이지 모든 TLP가 도착 순서대로 처리된다는 약속이 아닙니다. 일반적인 메모리 트랜잭션 규칙에서 Posted Memory Write는 Completion을 기다리지 않습니다. Posted 요청이 앞선 Non-Posted 요청을 통과할 수 있어야 하는 규칙은 전진 진행을 위한 것이며, 무조건 FIFO로 막으면 교착 가능성이 생깁니다. 반면 Completion이 앞선 Posted 요청을 통과하는 것은 원칙적으로 제한되며, 해당 Relaxed Ordering(RO) 속성과 규칙이 허용하는 경우를 구별해야 합니다.

장치가 데이터를 쓴 뒤 완료 플래그를 쓰는 생산자·소비자 예에서는 플래그만 먼저 관측되면 아직 갱신되지 않은 데이터를 읽을 수 있습니다. 서로 독립인 데이터 쓰기의 재정렬을 허용하는 것과, 완료 플래그가 그 데이터들을 추월해도 된다는 것은 다릅니다. RO는 허용되는 순서 제약을 완화하는 속성이지 반드시 추월하라는 명령이나 보편적인 성능 향상 기능이 아닙니다. PCI-SIG UIO 설명 자료 10–11쪽의 기존 메모리 순서표와 데이터·플래그 예를 기준으로 이 경계를 확인할 수 있습니다. UIO의 새로운 트랜잭션 규칙을 기존 RO와 같은 기능으로 합치지 않습니다.

Device Control의 Enable Relaxed Ordering은 기능이 RO를 사용할 수 있게 하는 허용 조건이며, 실제 요청의 RO 속성·경로와 구별합니다. 특정 IP의 수신 트랜잭션 순서 규칙을 확인한 뒤 사용자 인터페이스 이후의 큐에서도 필요한 순서를 유지해야 합니다. CPU가 DMA 결과를 보는 순서와 드라이버의 메모리 장벽은 또 다른 계약입니다. Linux의 readl_relaxed() 설명을 PCIe TLP의 RO 비트를 직접 지정하는 API로 해석하지 않습니다.

Gray coding과 precoding은 같은 오류 대책이 아닙니다

Gen5의 32 GT/s는 NRZ이며 PAM4 Gray coding을 적용하는 세대가 아닙니다. 이 속도의 precoding은 선택적 동작입니다. Gen6·Gen7 PAM4의 Gray coding과 precoding 요구를 Gen5까지 소급하거나, 모든 비트에 같은 변환이 무조건 적용된다고 설명하면 안 됩니다. PCI-SIG Gen7 자료 32쪽의 세대 비교와 Cadence의 precoding 설명은 지원·활성화와 비트 적용 조건을 구분할 근거입니다.

PAM4 데이터 경로는 적용 대상 scrambling, 2비트 Gray coding, 활성화·적용 조건에 맞는 precoding, PAM4 변조 순으로 읽습니다. 인접 레벨을 잘못 판정했을 때 비트 차이를 줄이는 Gray 표현은 전압 판정 오류 자체를 없애지 않습니다. Precoding은 수신 DFE에서 생길 수 있는 오류 전파를 제한하는 목적이며 최초 오류를 없애는 FEC와 같지 않습니다. TS0처럼 precoding 대상이 아닌 비트의 예외를 남겨 두어야 합니다.

디버깅 기록에는 실제 링크 속도와 인코딩, 방향, 해당 훈련·데이터 구간, precoding 활성 상태를 함께 남깁니다. 이 구분만으로 DC 균형, CDR 잠금, EMI 적합성이나 실제 BER이 보장되는 것은 아닙니다. 이 글에서는 송수신기나 보드의 동작을 시험하지 않았습니다.

English summary. Buffer credits and transaction ordering are separate constraints. RO permission is not a CPU memory barrier. Gray coding and conditional precoding address different error mechanisms; Gen5 NRZ must not be described as PAM4.

공개적으로 다시 확인할 수 있는 자료

공개되지 않은 제조사 레지스터나 제품별 오프셋은 추측하지 않았습니다. 아래의 제조사 자료, 아키텍처 문서, Linux v6.18.37 원본으로 확인할 수 있는 내용만 다뤘습니다.

3. PIPE, PCS, PMA와 controller의 책임을 나눈다