이 페이지는 MGT(Multi-Gigabit Transceiver)를 소개하는 페이지 시리즈 중 두 번째입니다.
소개
MGT는 PCIe, SATA, Gigabit Ethernet, SuperSpeed USB, Thunderbolt, DisplayPort 등 잘 알려진 여러 프로토콜의 기본 구성 요소입니다. 이 프로토콜들에는 공통점이 하나 있습니다. 바로 컴퓨터가 관여한다는 점입니다. 또한 광섬유 링크를 통해 전화 통화를 전송하기 위한 통신용 프로토콜도 여럿 있습니다.
MGT는 두 FPGA 사이에서 데이터를 교환하는 데에도 유용합니다. MGT를 이런 용도로 사용할 때 유의할 몇 가지 사항은 이전 페이지에 정리되어 있습니다. 물리 채널을 통해 데이터가 제대로, 그리고 허용 가능한 신뢰성으로 전송되게 하려면 어떤 형태로든 프로토콜이 필요합니다. 이런 프로토콜을 구현하는 일은 꽤 복잡하므로, 바로 사용할 수 있는 기성 프로토콜이나 도움이 될 만한 다른 구성 요소가 있는지가 관건입니다.
이 페이지에서는 주요 대안들을 정리해 보았습니다. 아래에는 애플리케이션 로직의 복잡도가 낮은 순서대로 나열되어 있습니다.
별도로 명시하지 않는 한, 아래의 모든 프로토콜은 양방향 링크(전이중, full duplex)와 단방향 링크(반이중, half duplex) 모두로 동작할 수 있습니다.
Xillyp2p
Xillyp2p는 두 FPGA 사이에서 여러 데이터 스트림을 안정적으로 전송할 수 있게 해 주는 독자(proprietary) 프로토콜입니다. 이 프로토콜은 TCP/IP가 네트워크에서 데이터를 전송하는 방식과 유사하게, 애플리케이션 데이터의 전송, 스케줄링, 재전송, 흐름 제어(flow control)를 관리합니다. 모든 데이터는 반대편에 정확하게 도착하는 것이 보장됩니다.
애플리케이션 로직은 표준 FIFO를 통해 이 프로토콜의 구현과 상호 작용합니다. 이 프로토콜은 두 FPGA에 걸쳐 있는 표준 FIFO가 있는 것처럼 보이게 만듭니다. 즉, 이 가상 FIFO의 쓰기 측은 한쪽 FPGA에, 읽기 측은 다른 쪽 FPGA에 있습니다.
두 FPGA 각각에서 FIFO의 한쪽은 애플리케이션 로직에 연결되고, 다른 쪽은 프로토콜 로직과 인터페이스합니다. 따라서 송신 측 애플리케이션 로직은 FIFO에 데이터를 쓰고, 수신 측 애플리케이션 로직은 다른 FIFO에서 데이터를 읽습니다. 프로토콜은 송신 FPGA의 FIFO에서 수신 FPGA의 FIFO로 데이터를 옮기는 역할을 담당합니다. 프로토콜의 흐름 제어 덕분에 대상 FPGA의 FIFO가 가득 차는(full) 일은 발생하지 않습니다.
이 프로토콜은 양방향으로 여러 FIFO를 지원할 수 있습니다. 공정한 데이터 전송 스케줄러가 MGT 대역폭을 효율적으로 활용하도록 보장합니다. 송신 측 FIFO에 쌓인 데이터는 곧바로 소비되므로, 대역폭이 허용하고 반대편 FIFO에서 데이터를 읽어 가는 한 이 FIFO가 가득 차는(full) 일은 없습니다.
이 프로토콜에는 패킷을 전송하기 위한 별도의 인터페이스도 있습니다(EOP 포트를 사용).
반이중(half-duplex) 옵션도 지원됩니다. 이 경우 프로토콜은 도착하는 모든 데이터가 정확함을 보장합니다. 물리 채널에서 비트 오류가 발생하면, 잘못된 데이터가 애플리케이션 로직에 도달하기 전에 데이터 흐름이 중단됩니다.
Gigabit Ethernet
Gigabit Ethernet은 컴퓨터 간 통신을 위해 만들어졌지만, 이 단순한 프로토콜을 두 FPGA 사이에서 패킷을 주고받는 용도로 사용할 수도 있습니다. 적합한 IP 코어(IP core)는 보통 FPGA 제조사가 제공합니다. 따라서 애플리케이션 로직은 표준 인터페이스(GMII, RGMII, XGMII 등)를 통해 이더넷 패킷을 생성하고 수신하는 역할을 담당합니다.
다른 이더넷 링크와 마찬가지로, 데이터를 패킷으로 구성하고 링크 오류를 처리하는 일(예: 재전송)은 애플리케이션 로직의 몫입니다.
Interlaken
Interlaken은 칩 간에 패킷을 전송하기 위한 개방형(open) 프로토콜입니다. 64b/67b 인코딩을 기반으로 하며, 저수준 데이터 흐름은 64비트 세그먼트를 반복적으로 전송하는 방식입니다. 각 세그먼트 앞에는 애플리케이션 데이터와 제어 워드를 구분하기 위한 3비트가 덧붙여집니다. 이 프로토콜은 simplex 링크(단방향 물리 채널)용으로 정의되었습니다. 전이중(full duplex) 링크(양방향 물리 채널)를 사용하는 경우에도 흐름 제어 메시지를 반대 방향으로 보낼 수 있다는 점만 제외하면 simplex 링크와 동일하게 동작합니다.
이 프로토콜의 기본 전송 단위는 가변 길이를 갖는 버스트(burst)입니다. 각 버스트의 바로 앞과 뒤에는 제어 워드가 하나씩 전송됩니다. 이 두 제어 워드에는 패킷과 채널을 추상화하는 데 필요한 정보가 담겨 있습니다. 그 내용 중 일부는 다음과 같습니다.
- 채널 번호(Channel number): 0에서 255 사이의 숫자로, 뒤따르는 데이터 버스트를 특정 채널에 연결합니다. 채널 수는 최대 65536개까지 확장할 수 있습니다.
- SOP: 뒤따르는 데이터가 패킷의 시작임을 나타내는 플래그입니다.
- EOP: 그 앞의 데이터가 패킷의 마지막 데이터임을 나타내는 플래그입니다. EOP는 또한 버스트의 마지막 워드에 있는 유효 바이트 수와 패킷에 오류가 포함되어 있는지 여부도 나타냅니다.
각 버스트의 길이는 BurstMax보다 길면 안 되고 BurstShort보다 짧으면 안 됩니다. BurstMax와 BurstShort는 모두 특정 애플리케이션에 맞게 선택하는 매개변수입니다. BurstShort는 최소 32바이트(8의 배수이어야 함)이고, BurstMax는 64바이트의 배수이어야 합니다.
제어 워드와 그 앞에 올 수 있는 데이터 버스트의 내용은 CRC24를 통해 비트 오류가 검사됩니다.
버스트가 CRC24 검사를 통과하지 못하면(즉 비트 오류가 검출되면), Interlaken 재전송 확장 프로토콜 정의(Interlaken Retransmit Extension Protocol Definition)에 정의된 대로 재전송을 요청할 수 있습니다. 이 메커니즘에 따르면 재전송 요청은 수신기에서 송신기로 연결된 세 개의 물리적 전선을 통해 전송됩니다. 이 전선들의 이름은 FC_CLK, FC_DATA, FC_SYNC이며, 원래는 대역 외 흐름 제어(OOBFC, Out-of-Band Flow Control)를 위해 마련된 것입니다. 흐름 제어 요청을 보내기 위한 간단한 직렬 데이터 전송 프로토콜이 정의되어 있습니다. 재전송이 활성화되면 이 비트들 중 하나가 "RT"라는 이름으로 재전송을 요청하는 데 사용됩니다. 다시 말해, 이 프로토콜은 MGT 링크 자체를 통해서가 아니라 별도의 물리적인 대역 외(out-of-band) 전선 세 개를 통해서 재전송 요청을 보내도록 정의하고 있습니다.
재전송 요청에는 어느 버스트부터 재전송해야 하는지에 대한 정보가 포함되지 않습니다. 대신 송신 측은 일정량의 버스트 데이터를 버퍼에 저장해 두어야 합니다. 재전송 요청이 도착하면 버퍼에 있는 모든 버스트가 재전송됩니다. 따라서 버퍼의 크기는 손실된 버스트를 포함할 수 있을 만큼 충분히 커야 합니다. 하지만 버퍼가 너무 크면 재전송이 필요 이상으로 길어집니다. 버퍼 크기를 정하려면, Interlaken 프로토콜을 구현하는 로직에 버스트를 전달한 시점부터 재전송 요청이 도착할 때까지의 왕복 시간을 신중하게 계산해야 합니다.
수신기는 처음 전송되는 버스트마다 1씩 증가하는 카운터를 사용해 재전송된 버스트를 식별합니다(2개, 4개, 8개 등의 버스트마다 증가시키는 것도 가능합니다). 이 카운터 값은 각 버스트의 앞뒤로 전송되는 제어 워드의 Multiple-Use 부분에 실려 전송됩니다. 수신기는 이 카운터로 새 버스트와 재전송된 버스트를 구분합니다.
Interlaken 프로토콜에는 진단 목적의 CRC32 검사도 있습니다(각 메타 프레임(Meta Frame)당 한 번). 하지만 이 검사로 오류가 검출되더라도 그 오류는 특정 버스트나 패킷이 아니라 큰 데이터 구간과 관련된 것입니다. 즉, 비트 오류가 있었는데도 CRC24 검사를 통과한 데이터는 나중에야 오류가 검출되며, 어떤 버스트에 잘못된 데이터가 들어 있는지 지적할 수 없습니다.
MGT의 반대 방향 데이터 흐름을 기반으로 하는 재전송 메커니즘을 설계하고 구현하는 것도 가능합니다. Interlaken 프로토콜은 이런 방식을 제시하지는 않지만, 재전송을 요청하는 패킷 전용 채널을 따로 할당하는 것은 가능합니다. 이렇게 하면 무엇을 재전송할지 더 구체적으로 요청할 수 있다는 큰 장점이 있습니다. 또한 버스트 단위가 아니라 패킷 단위로 더 나은 CRC를 적용할 수도 있습니다. 다만 이 방식을 택한다면 전체 메커니즘을 애플리케이션 로직으로 구현해야 합니다.
Interlaken의 흐름 제어 메커니즘은 별도 페이지에서 다룹니다.
Aurora
Aurora는 Xilinx(현재 AMD)가 자사 FPGA를 위해 개발한 프로토콜입니다. 이 프로토콜의 기본 전송 단위는 단일 워드입니다(사용되는 MGT 수에 따라 고정된 폭을 갖습니다). 또한 패킷(여기서는 프레임(frame)이라고 함) 전송도 지원합니다. 애플리케이션 로직은 "last" 입력 포트를 사용하여 데이터 스트림을 패킷으로 나눕니다.
Aurora에는 8b/10b 인코딩과 64b/66b 인코딩이라는 두 가지 변형이 있습니다. 64b/66b 인코딩이 더 효율적이므로 가능하면 이 변형을 사용하는 것이 좋습니다.
Aurora는 simplex 링크(단방향 물리 채널)와 전이중(full duplex) 링크(양방향 물리 채널) 모두로 정의되어 있습니다. 애플리케이션 로직의 관점에서는 두 옵션 사이에 큰 차이가 없습니다. 다만 simplex 링크에서는 흐름 제어가 의미가 없습니다.
Interlaken과 달리 Aurora 프로토콜에는 채널(channel)이라는 개념이 없습니다. 다시 말해, 물리 채널을 통해 전송되는 모든 데이터는 하나의 데이터 스트림에 속합니다. 이 프로토콜에서 "채널"이라는 단어를 사용한다면 이는 물리 채널을 가리키는 것이지, 데이터를 독립적인 스트림들로 나누는 것을 의미하지 않습니다. 그러한 분할이 필요하다면, 각 패킷에 헤더를 추가하는 방식으로 애플리케이션 로직이 직접 구현해야 합니다.
물리 채널의 비트 오류는 프로토콜이 교정하지 않습니다. 다만 패킷 전송용으로 이 프로토콜을 사용할 때는 송신기가 각 패킷의 끝에 CRC를 선택적으로 추가할 수 있습니다(Xilinx의 프로토콜 구현 기준). 프로토콜 구현은 수신 측에서 이 CRC를 확인하고, 패킷에서 오류가 검출되면 애플리케이션 로직에 알려 줍니다. 만약 "last" 신호 없이 패킷을 사용하지 않는 방식으로 Aurora를 사용한다면, 이 프로토콜은 오류 검출 기능을 지원하지 않습니다.
프로토콜 자체의 제어 정보는 비트 오류에 대한 어떠한 보호도 없이 전송됩니다. 이런 트래픽에는 CRC가 적용되지 않습니다. 물리 링크에 비트 오류가 있으면 프로토콜이 다양한 방식으로 오작동할 수 있습니다.
재전송 메커니즘, 다중 채널 다중화, 전송 스케줄링은 모두 애플리케이션 로직으로 구현해야 합니다. Aurora에서 흐름 제어를 구현하는 방법에 대해서는 별도 페이지에서 논의합니다.
Serial Lite
Altera는 Serial Lite라는 이름을 공유하는 일련의 프로토콜 및 IP 코어 제품군을 보유하고 있습니다.
- SerialLite II: 패킷 기반 또는 패킷 기반이 아닌 데이터 송수신 인터페이스("Atlantic Interface"라고 함)입니다. 비트 오류에 대응하는 재전송을 지원합니다. 초기 FPGA에서만 사용할 수 있습니다(Arria II부터 5세대(series-V) FPGA까지).
- Serial Lite III: 연속(Continuous) 모드와 버스트(Burst) 모드를 지원합니다. 연속 모드에서는 데이터 스트림이 송신기와 수신기 사이에서 끊김이나 공백 없이 흐를 수 있습니다. 양쪽이 동일한 기준 클록(reference clock)을 사용해야 합니다. 이 프로토콜은 내부적으로 Interlaken을 기반으로 하지만, 채널이나 SOP/EOP는 지원하지 않습니다. 따라서 인터페이스 데이터 폭은 사용된 MGT 수에 64비트를 곱한 값입니다. 물리 링크의 비트 오류는 해당 오류를 유발한 MGT와 관련된 진단 이벤트로 보고되며, 특정 데이터 구간과 관련지어 보고되지는 않습니다. 5세대(series-V) FPGA와 10세대(series-10) FPGA에서 사용할 수 있습니다.
- Serial Lite IV: 패킷의 시작과 끝을 나타내는 신호를 가진 Avalon 스트리밍 인터페이스(MAC) 기반입니다. 송신기는 패킷 끝에 CRC를 선택적으로 삽입하고 수신기가 이를 확인합니다. 패킷으로 나누지 않는 기본(Basic) 모드도 있습니다. Stratix 10 및 Agilex E-tile에서 사용할 수 있습니다.
이 프로토콜 시리즈에서 서로 다른 버전 간에는 IP 코어의 호환성이 없습니다. 재전송을 시작할 수 있는 것은 SerialLite II뿐입니다.
RapidIO
RapidIO는 패킷 기반 프로토콜로, 지원하는 패킷 유형이 CPU가 필요로 하는 연산에 대응한다는 점에서 PCIe와 유사합니다. 그중 일부는 다음과 같습니다.
- Write: 주소에 데이터를 씁니다. 이 연산에는 여러 변형이 있으며, 그중 하나는 연산이 완료되었음을 알리는 응답을 요구합니다.
- Read: 주소에서 데이터를 읽어 오라는 요청입니다. 요청을 받은 대상(target)이 응답 패킷을 보냅니다.
- 원자적 읽기-수정-쓰기(Atomic read-modify-write): 이전 값을 읽은 후 해당 주소에 데이터를 쓰는 원자적(atomic) 연산 요청입니다. 지원되는 연산으로는 원자적 증가(atomic increment), 원자적 감소(atomic decrement), 원자적 교환(atomic swap), 비교 후 교환(compare and swap) 등이 있습니다.
- 탐색, 제어 및 상태 확인을 위한 여러 유지보수 요청도 있습니다. PCI 프로토콜의 구성 레지스터 공간과 유사하게, 이 유지보수 요청들은 기능 레지스터(CAR, Capability Register)와 명령 및 상태 레지스터(CSR, Command and Status Register)에 접근합니다.
RapidIO와 PCIe의 주요 기능적 차이는, PCIe 프로토콜은 중앙 유닛(루트 콤플렉스(Root Complex), 보통 CPU)이 시스템의 모든 엔드포인트를 구성해야 한다는 점입니다. RapidIO 시스템에는 이런 중앙 유닛이 필요하지 않습니다.
PCIe와의 또 다른 차이점은 패킷 재전송이 선택적이라는 것입니다. 재전송은 "신뢰성 트래픽(reliable traffic, RT)"으로 전송된 패킷에 대해서만 이루어집니다. 패킷은 "연속 트래픽(continuous traffic, CT)"으로도 보낼 수 있는데, 이런 패킷은 확인 응답(acknowledgement)도 재전송도 이루어지지 않습니다.
RapidIO 프로토콜은 전기적 사양부터 패킷 형식, 재전송, 흐름 제어까지 통신의 모든 측면을 정의합니다.
RapidIO는 프로토콜이 복잡하기 때문에 두 FPGA 사이의 단순한 point-to-point 연결에는 매력적인 선택지가 아닐 수 있습니다. RapidIO는 스위치를 통해 여러 FPGA를 서로 연결하는 인터커넥트에 더 적합할 수 있으며, 특히 시스템에 CPU가 필요하다는 이유로 PCIe를 사용하기 어려운 경우에 유용합니다.
요약
애플리케이션 데이터를 전송하기 위한 여러 프로토콜을 살펴보았습니다. 각 프로토콜은 데이터 전송, 흐름 제어, 비트 오류 대응(지원하는 경우)을 구현하는 방식이 서로 다릅니다. 애플리케이션에 적합한 프로토콜을 고르는 일은 프로토콜이 제공하는 기능과, 빠진 부분을 애플리케이션 로직으로 구현하는 데 필요한 노력 사이에서 균형을 잡는 문제입니다.
이것으로 MGT에 관한 이 시리즈의 두 번째 페이지를 마칩니다. 다음 페이지에서는 MGT에서 자주 사용되는 몇 가지 인코딩 방식에 대해 소개합니다.