이 페이지는 Multi-Gigabit Transceiver (MGT)를 소개하는 일련의 페이지 중 두 번째입니다.
소개
Multi-Gigabit transceivers (MGTs)는 잘 알려진 많은 protocols의 기본 구성 요소입니다. PCIe, SATA, Gigabit Ethernet, SuperSpeed USB, Thunderbolt , Displayport. 이 모든 protocols 에는 공통점이 하나 있습니다. 컴퓨터가 관련되어 있습니다. 또한 광섬유 링크를 통해 전화 통화를 전송하는 데 사용되는 통신용 protocols 도 여러 대 있습니다.
MGTs는 두 개의 FPGAs간에 데이터를 교환하는 데에도 유용합니다. 이 목적으로 MGT를 사용할 때 주의해야 할 몇 가지 사항은 이전 페이지 에 나와 있습니다. 분명히 데이터가 물리적 채널을 통해 적절하게 그리고 허용 가능한 신뢰성으로 전송되도록 하기 위해 어떤 종류의 protocol이 필요합니다. 이러한 protocol 의 구현은 매우 복잡하므로 문제는 기성품인 protocols 또는 도움이 될 수 있는 다른 빌딩 블록이 있는지 여부입니다.
이 페이지는 주요 대안을 요약하려는 시도입니다. application logic의 복잡도 수준에 따라 아래에 나열되어 있으며, 가장 복잡도가 낮은 것이 먼저 나열됩니다.
달리 명시되어 있지 않는 한, 아래의 모든 protocols는 단방향 링크(반이중)뿐만 아니라 양방향 링크(풀 듀플렉스)로도 작동할 수 있습니다.
Xillyp2p
Xillyp2p는 두 개의 FPGAs간에 여러 데이터 스트림을 안정적으로 전송하는 독점적인 protocol 입니다. protocol은 TCP/IP protocol이 네트워크를 통해 데이터를 전송하는 방식과 유사하게 애플리케이션 데이터의 전송, 흐름 제어, 스케줄링 및 재전송을 관리합니다. 모든 데이터는 반대편에 정확하게 도착하는 것이 보장됩니다.
application logic은 표준 FIFOs를 통해 protocol의 구현과 상호 작용합니다. protocol은 두 개의 FPGAs에 걸쳐 있는 표준 FIFO 의 환상을 만듭니다. 이 가상 FIFO에서 쓰기용 면은 한 FPGA에 있고, 읽기용 면은 다른 FPGA에 있습니다.
두 개의 FPGAs각각에서 FIFO 의 한 쪽은 application logic 에 연결되고 다른 쪽은 protocol의 logic와 상호 작용합니다. 따라서 송신 측의 application logic은 FIFO 에 데이터를 쓰고 수신 측의 application logic은 다른 FIFO에서 데이터를 읽습니다. protocol은 송신 FPGA 의 FIFO 에서 수신 FPGA의 FIFO 로 데이터를 이동하는 역할을 합니다. protocol의 흐름 제어는 대상 FPGA 의 FIFO가 결코 가득 차지 않도록 보장합니다.
protocol은 양방향으로 여러 개의 FIFOs를 제공할 수 있습니다. 공정한 데이터 전송 스케줄러는 MGT대역폭의 효율적인 활용을 보장합니다. 송신기 측 FIFO 의 데이터는 충분히 빨리 소모되므로 이 FIFO는 가득 차지 않습니다(대역폭이 허용하고 데이터가 다른 쪽의 FIFO 에서 소모되는 한).
protocol은 패킷을 전송하기 위한 다른 인터페이스도 갖고 있습니다( EOP port의 도움을 받아).
반이중 옵션도 지원됩니다. 이 경우 protocol은 도착하는 모든 데이터가 올바른지 확인합니다. 물리적 채널에서 비트 오류가 발생하면 오류가 있는 데이터가 application logic에 도달하기 전에 데이터 흐름이 중단됩니다.
Gigabit Ethernet
Gigabit Ethernet는 컴퓨터 간 통신을 위해 고안되었지만, 이 간단한 protocol을 사용하여 두 개의 FPGAs간에 패킷을 전송할 수 있습니다. 적합한 IP는 일반적으로 FPGA 제조업체에서 제공합니다. 따라서 application logic은 표준 인터페이스(GMII, RGMII, XGMII 등) 중 하나를 통해 Ethernet 패킷을 생성하고 수신하는 역할을 합니다.
모든 Ethernet 링크와 마찬가지로 application logic의 역할은 데이터를 패킷으로 구성하고 링크의 오류(예: 재전송)를 처리하는 것입니다.
Interlaken
Interlaken은 chips간 통신을 위한 개방형 protocol 입니다. 64b/67b 인코딩을 기반으로 합니다. 저수준 데이터 흐름은 64 bits의 세그먼트를 반복적으로 전송하는 것으로 구성됩니다. 이러한 각 세그먼트 앞에 3 bits가 추가되어 애플리케이션 데이터와 제어 단어를 구분합니다.
protocol의 기본 전송 단위는 가변 길이의 버스트입니다. 제어 단어는 각 버스트 직전과 직후에 전송됩니다. 이 두 제어 단어에는 패킷과 채널의 추상화를 허용하는 정보가 들어 있습니다. 여기에는 다음이 포함됩니다.
- 채널 번호: 0에서 255 사이의 숫자로, 이어지는 데이터 버스트를 채널과 연결합니다.
- SOP: 패킷의 시작 부분에 오는 데이터를 나타내는 플래그입니다.
- EOP: 제어 단어 이전의 버스트가 패킷의 마지막 데이터였음을 나타내는 플래그입니다. EOP는 또한 버스트의 유효 바이트 수와 패킷에 오류가 있는지 여부를 나타냅니다.
제어어의 내용과 (아마도) 그 전에 온 데이터 버스트는 CRC24를 이용해 비트 오류가 있는지 검사됩니다.
Interlaken protocol은 진단 목적으로 CRC32 검사도 합니다( Meta Frame당 한 번). 그러나 이 테스트의 도움으로 오류가 감지되면 특정 버스트나 패킷이 아니라 대량의 데이터 세그먼트와 관련이 있습니다. 즉, 비트 오류에도 불구하고 데이터가 CRC24 테스트를 통과한 경우 이는 나중에야 감지되고, 오류가 있는 데이터가 포함된 버스트를 가리킬 수 없습니다.
Interlaken은 또한 두 가지 메커니즘을 사용하여 흐름 제어 요청을 보내는 것을 허용합니다. 대역 내 흐름 제어 및 대역 외 흐름 제어(OOBFC). 두 메커니즘 모두 수신기가 XON/XOFF 의미론을 사용하여 데이터를 수신할 준비가 되었는지 광고하는 수단으로 구성됩니다. 이 정보는 각 수신 엔터티에 대한 단일 bit 로 구성됩니다. 이 bit은 이 엔터티가 데이터를 수신할 준비가 되면 '1'이고 그렇지 않으면 '0'입니다. "수신 엔터티"의 정확한 의미는 애플리케이션에 따라 다릅니다.
인밴드 흐름 제어 메커니즘은 흐름 제어 요청을 전송하기 위해 제어 단어에서 16 bits를 사용합니다. 아웃오브밴드 흐름 제어 메커니즘은 정보를 전송하기 위해 세 개의 추가 물리적 와이어(clock, sync 및 data)가 필요합니다.
Interlaken은 중재 또는 전송 스케줄링 메커니즘을 포함하지 않으므로 흐름 제어를 강제할 수 없습니다. application logic은 다른 소스에서 데이터 전송을 중재하고 흐름 제어 요청이 준수되도록 해야 합니다. Interlaken IP core가 흐름 제어를 지원한다고 발표하면 종종 데이터 흐름을 제어하는 것이 아니라 흐름 제어 요청을 보낼 수 있음을 의미합니다.
버스트가 CRC24 테스트에 실패하면(즉, 비트 오류가 감지되면) Interlaken Retransmit Extension Protocol Definition에 정의된 대로 재전송을 요청할 수 있습니다. 이 재전송 요청은 위에서 언급한 대역 외 인터페이스(OOBFC)에서 전송됩니다. 즉, protocol은 MGT 링크 자체에서 재전송 요청을 보내는 방법을 정의하지 않고, 대신 세 개의 별도 물리적 대역 외 와이어에서 보냅니다.
Aurora
Aurora는 Xilinx (현재는 AMD)가 자체 FPGAs를 위해 개발한 protocol 입니다. 이 protocol의 기본 전송 단위는 단일 단어(관련된 MGTs 의 수에 따라 고정된 폭을 가짐)입니다. 그러나 protocol은 패킷 모드도 지원하여 패킷의 마지막 단어와 함께 채널을 통과하는 "last" 신호를 선택적으로 노출합니다.
protocol은 물리적 채널의 비트 오류를 수정하지 않습니다.
송신 측에서는 양쪽( protocol 및 application logic) )이 핸드셰이크 신호로 데이터 흐름을 제한할 수 있습니다. 수신 측에서는 application logic이 도착하는 모든 데이터 단어를 항상 수락해야 합니다. 그러나 protocol은 송신기가 데이터를 보내지 못하도록 하는 두 가지 옵션을 제공합니다.
- Native Flow Control (NFC) : 수신 측의 application logic은 송신 측에 요청에서 주어진 데이터 슬롯 수만큼 데이터 전송을 일시 중지하도록 요청합니다. protocol의 logic은 송신 측의 핸드셰이크 신호에 의해 이 요청을 따르는 역할을 합니다.
- User Flow Control (UFC) : protocol은 수신 측이 별도의 채널을 통해 임의의 메시지를 보낼 수 있도록 합니다. 송신 측의 application logic은 이 요청을 처리하고 준수할 책임이 있습니다.
두 흐름 제어 메커니즘은 모두 반대 방향의 데이터 링크를 기반으로 하므로 풀 듀플렉스 모드에서만 사용할 수 있습니다.
protocol을 사용하여 패킷을 전송하는 경우, 송신기는 선택적으로 각 패킷의 끝에 CRC를 추가합니다( protocol의 Xilinx구현에서). protocol의 구현은 수신 측에서 이 CRC를 확인하고 패킷에서 오류가 감지되었는지 application logic 에 알립니다. Aurora를 패킷 없이("last" 신호 없이) 사용하는 경우, protocol에서 오류 감지를 하지 않습니다.
재전송 메커니즘, 다중 채널 다중화, 전송 스케줄링은 모두 application logic에서 구현해야 합니다.
Aurora에는 두 가지 변형이 있습니다. 8b/10b 인코딩 과 64b/66b 인코딩을 사용합니다. 64b/66b 인코딩이 더 효율적이므로 가능하면 이 변형을 사용하는 것이 좋습니다.
Serial Lite
Altera 에는 Serial Lite라는 이름을 공유하는 protocols 및 IP cores 시리즈가 있습니다.
- SerialLite II: 데이터 수신 및 전송을 위한 패킷 기반 또는 비패킷 인터페이스("Atlantic Interface"로 명명). 비트 오류에 대한 응답으로 재전송을 지원합니다. 초기 FPGAs 에만 적용 가능( Arria II 에서 series-V FPGAs까지).
- Serial Lite III: 연속 및 버스트 모드를 지원합니다. 연속 모드에서 데이터 스트림은 송신기와 수신기 사이에 중단 없이 갭 없이 흐를 수 있습니다. 이를 위해서는 양측이 동일한 reference clock에 의존해야 합니다. 이 protocol은 내부적으로 Interlaken을 기반으로 하지만 지원 채널이나 SOP/EOP는 없습니다. 따라서 인터페이스의 데이터 폭은 64 bits 에 사용된 MGTs 수를 곱한 값입니다. 물리적 링크의 비트 오류는 이를 발생시킨 MGT 와 관련하여 진단 이벤트로 보고되지만 특정 데이터 세그먼트와 관련하여 보고되지는 않습니다. series-V FPGAs 및 series-10 FPGAs에 적용 가능합니다.
- Serial Lite IV: 패킷의 시작과 끝을 위한 신호가 있는 Avalon streaming 인터페이스 기반(MAC). CRC는 선택적으로 송신기에 의해 패킷 끝에 삽입되고 수신기에 의해 확인됩니다. 패킷으로 구분되지 않는 기본 모드도 있습니다. Stratix 10 및 Agilex E-tile에 적용 가능합니다.
IP cores는 이 protocols시리즈의 다른 멤버들과 호환되지 않습니다. SerialLite II 만이 재전송을 시작할 수 있습니다.
RapidIO
RapidIO 는 패킷 기반 protocol 로, 지원하는 패킷 유형이 CPU에서 요구하는 작업과 일치한다는 점에서 PCIe 와 유사합니다.
- 쓰다: address에 데이터를 씁니다. 이 작업에는 여러 가지 변형이 있는데, 그 중 하나는 작업이 완료되었다는 응답 표시가 필요합니다.
- 읽다: address에서 데이터를 읽으라는 요청. 대상은 이 요청에 응답 패킷을 보냅니다.
- 원자 읽기-수정-쓰기: 이전 값을 읽은 후 address 에 데이터를 쓰라는 요청(원자적 연산). 지원되는 연산 중: Atomic increment 와 atomic decrement, atomic swap, compare and swap 등.
- 발견, 제어 및 상태에 대한 여러 유지 관리 요청. PCI protocol의 configuration register space와 유사하게 이러한 유지 관리 요청은 registers capability registers (CAR) 및 command and status registers (CSR)에 액세스합니다.
RapidIO 와 PCIe 의 주요 기능적 차이점은 PCIe protocol은 중앙 장치( Root Complex, 보통 CPU)가 시스템의 모든 엔드포인트를 구성해야 한다는 것입니다. RapioIO 시스템은 이런 종류의 중앙 장치가 필요하지 않습니다.
PCIe 와의 또 다른 차이점은 패킷 재전송이 선택 사항이라는 것입니다. 재전송은 "reliable traffic"(RT)로 전송된 패킷에 대해서만 발생합니다. 패킷은 "continuous traffic"(CT)로 전송될 수도 있습니다. 이러한 패킷은 확인되지도 재전송되지도 않습니다.
RapidIO protocol은 전기적 사양부터 패킷 형식, 재전송 및 흐름 제어까지 통신의 모든 측면을 정의합니다.
RapidIO는 이 protocol의 복잡성으로 인해 두 개의 FPGAs사이의 간단한 지점 간 연결에 매력적인 후보가 아닐 수 있습니다. RapidIO는 switch를 통한 여러 FPGAs 사이의 상호 연결로 더 적합할 수 있으며, 특히 PCIe가 시스템에 CPU가 필요하기 때문에 적합하지 않은 경우 더욱 그렇습니다.
요약
애플리케이션 데이터를 전송하기 위한 여러 개의 protocols가 제시되었습니다. 각 protocol은 데이터 전송을 구현하고, 흐름을 제어하고, 비트 오류에 응답하는(있는 경우) 다른 방법을 제시합니다. 애플리케이션에 적합한 protocol은 protocol이 제공하는 기능과 application logic에서 누락된 부분을 구현하는 데 필요한 노력 간의 균형입니다.
이것으로 MGTs에 대한 이 시리즈 의 두 번째 페이지를 마무리합니다. 다음 페이지에서는 MGTs에서 자주 사용되는 몇 가지 인코딩 방법을 소개합니다.