[TeledyneLeCroy]‘PCIe CrossSync PHY로 다이나믹 링크 동작 디버깅하기’ 주제의 포스팅 업데이트
- 2022-09-19
- 조회수2980
최근에 발표한 PCI Express®는 8G,16G 또는 32Gbps의 비트 전송속도에서 신호 무결성을 유지하기 위해 링크 이퀄라이제이션 프로세스에 크게 의존합니다. 과정 1에서, PCIe 링크에 연결된 양측은 동작 링크를 수립할 수 있도록 TS1 오더셋(Ordered Set)을 교환합니다. 과정 2에서, 업스트림 포트는 다운스트림 포트에게 채널 링크 보상을 위한 트랜스미터 이퀄라이션 설정을 요청합니다. 과정 3에서는 과정2와 반대로 다운스트림 포트가 업스트림 포트에 트랜스미터의 이퀄라이저 설정을 요청합니다.
그림 1. 두 업스트림 레인은 정상적이지 않은 이퀄라이제인션 동작을 보이고 있습니다. 전기적인 신호만 보고 작업을 해야 한다면 어떻게 디버깅을 시작해야 할까요?
PCI Express 컴플라이언스 테스트 이벤트 또는 실험실에서 수행되는 사전-규정 준수 테스트에서, 디바이스가 단독으로 올바른 링크 이퀄라이제이션을 수행할 수 있는지 여부를 확인하기위해 트랜스미터 링크 이퀄라이제이션 테스트가 수행됩니다. 일반적으로 프로토콜을 인식하는 BERT 테스트 장비가 측정대상 디바이스(DUT)의 링크 파트너 역할을 합니다. BERT가 특정 프리셋 변경을 요청하고, 디바이스가 응답으로 채널 보상에 필요한 프리셋으로 변경합니다. 이 변화를 오실로스코프를 이용하여 포착합니다. 오실로스코프는 전기적인 레이어의 트랜스미터 이퀄라이제이션 변화 과정을 보여줄 수 있으며, 첫 번째로는 충분히 빠른 시간내에 변화되었는지, 두 번째로는 디바이스가 실제로 요청된 프리셋 레벨로 변경되었는지 여부를 측정 확인할 수 있으며, 이것은 순서대로 진행됩니다.
그럼, 실제 동작중인 두 디바이스 사이의 링크에서 "이상한" 이퀄라이제이션 동작이 의심된다면 (예: 과정 3에서 업스트림 이퀄라이제이션에 문제발생) 어떻게 될까요? 문제 디버깅을 하려고 한다면 어떻게 파형 또는 트레이스를 포착할 수 있을까요? 무슨 일이 발생했는지의 단서는 어떤 방법으로 찾을 수 있을까요?
그림 2. 신호를 두 개의 디바이스가 모두 포착할 수 있도록 고안된 CrossSync PHY 테크놀러지
첫 번째 문제는 링크의 각 측에서 동일한 신호를 두 개의 다른 기기(전기 계층 보기용 오실로스코프 및 프로토콜 계층 보기용 프로토콜 분석기)로 가져오는 것입니다. PCIe용 CrossSync™ PHY 설정에서는 CrossSync PHY 지원 인터포저가 DUT를 호스트에 연결하여 프로토콜 분석기와 오실로스코프에 동시에 신호를 분할할 수 있습니다. 고속 데이터 콘텐츠와 사이드밴드 신호는 모두 인터포저에서 교차 프로빙되어 두 개의 완전히 시간 동기화된 수집 결과를 낳습니다.
그림 3, 속도 변경후 첫번째로 발생하는 TS2에서 트리거하여 서로 주고 받은 프리셋을 포착합니다.
디버깅 중인 디바이스가 16Gbps의 PCIe® 4.0 디바이스라면,16Gbps로 속도가 변경된 후 첫 번째 TS2에서 트리거되도록 프로토콜 분석기를 설정하여 프로토콜 레이어에서 프리셋 정보를 어떻게 주고 받는지 포착할 수 있습니다. 하지만, 물리 계층에서 정확히 도일한 이벤트들을 오실로스코프 파형으로 확인하고 싶다면 어떻게 해야 할까요? 그런 종류의 트리거는 오실로스코프 단독으로 수행할 수 없고 프로토콜을 인식할 수 있는 수준의 설정이 가능한 무엇인가가 필요합니다. 만약 속도 변경을 요청하는 프로토콜 이벤트에서 프로토콜 분석기와 오실로스코프를 동시에 트리거할 수 있는 CrossSync™ PHY와 같은 장비를 사용하면 과정 3의 마지막 단계에서의 이퀄라이제이션 프리셋과 계수를 보여주는 프로토콜 트레이스와 시간이 일치한 오실로스코프 트레이스를 통해 전기적으로 설정에 따라 어떻게 영향을 받는지 확인할 수 있습니다.
그림 4. TS1 패킷을 확장해보면 각레인의 설정된 프리셋 값을 확인할 수 있지만 일치하지 않는다면 로직 문제인가요 아니면 전기적인 문제인가요?
모든 트레이스를 동시에 이동시킬 수 있는 프로토콜 분석기 화면에서 업스트림 방향이라고 표시된 TS1 패킷을 확장하여 보고된 프리셋을 확인해봅니다. 그림 4에서는 과정 3의 마지막 절차에서 레인 0과 레인 2는 트랜스미터 이퀄라이제이션 프리셋 P6으로 트레이닝되었다고 표시되었습니다. 레인 1과 레인 3은 TxEQ 프리셋 P10으로 트레이닝되었다고 표시하고 있습니다. 레인이 서로 다른 프리셋 설정에 따라 트레이닝 되었다는 것을 알 수 있습니다. 이것은 예상하고 있덙 결과인가요? 사양서에 의하면 P10은 실제 동작중인 링크에 사용되는 프리셋이 아니라 테스트용으로 디자인한 프리셋입니다. P10의 부스트 값은 정해지지도 않았으며, 다른 프리셋들과 다르게 P10을 요청하면 어떤 동작을 해야하는지 조차 알 수 없습니다. 분명한 것은 문제가 있다는 것입니다. 하지만 디바이스가 P10으로 트레이닝 된 것이 문제인가요 아니면 단순히 P10으로 트레이닝되었다고 잘못 표시하고 있는 것이 문제일까요? 이것은 순전히 프로토콜적인 문제인가요? 아니면 프로토콜과 전기적인 문제가 동시에 있는 것인가요?
그림 5, EIEOS 심볼을 중심으로 오실로스코프 트레이스를 확대/축소하면 레인이 실제로 서로 다른 프리셋에 맞춰 트레이닝되고 있음을 확실하게 알 수 있습니다.
프로토콜 화면과 오실로스코프 화면이 결합되있는 CrossSync™ PHY 화면에서 프로토콜 디스플레이에서 EIEOS 심볼을 클릭하면 EIEOS 심볼을 중심으로 오실로스코프 파형이 확대되면서 두 신호사이의 전기적인 엠퍼시스의 차이를 확실하게 볼 수 있습니다. P10 레인은 분명히 P6로 트레이닝된 레인보다 신호에 훨씬 더 엠퍼시스되어 있습니다. 따라서, 프로토콜적인 문제로 잘못된 프리셋으로 트레이닝된 것으로 보입니다. 이 사실로부터 디바이스가 왜 P10으로 트레이닝되었는지 알아보기위해 펌웨어를 살펴보기 시작할 수 있는 근거를 제공합니다.