이 페이지는 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이 네트워크를 통해 데이터를 전송하는 방식과 유사하게 애플리케이션 데이터의 전송, 스케줄링, 재전송 및 flow control 관리를 담당합니다. 모든 데이터는 반대편에 정확하게 도착하는 것이 보장됩니다.
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은 simplex link (단방향 물리 채널)에 대해 정의됩니다. full duplex link (양방향 물리 채널)를 사용하는 경우, simplex link와 동일하게 작동하지만 flow control 메시지는 반대 방향으로 전송될 수 있습니다.
protocol의 기본 전송 단위는 가변 길이의 버스트입니다. 제어 단어는 각 버스트 직전과 직후에 전송됩니다. 이 두 제어 단어에는 패킷과 채널의 추상화를 허용하는 정보가 들어 있습니다. 여기에는 다음이 포함됩니다.
- 채널 번호: 0에서 255 사이의 숫자로, 뒤따르는 데이터 버스트를 채널과 연결합니다. 채널 수는 최대 65536개까지 확장할 수 있습니다.
- SOP: 뒤따르는 데이터가 packet의 시작임을 나타내는 플래그입니다.
- EOP: 제어 단어 앞의 packet는 패킷의 마지막 데이터임을 나타내는 플래그입니다. EOP는 또한 버스트의 마지막 단어에 있는 유효 바이트 수와 패킷에 오류가 포함되어 있는지 여부를 나타냅니다.
각 버스트의 길이는 BurstMax 보다 길거나 BurstShort보다 짧아서는 안 됩니다. BurstMax 와 BurstShort는 특정 용도에 맞게 선택되는 매개변수입니다. BurstShort는 최소 32 bytes 이상이어야 하며 (8의 배수여야 함), BurstMax는 64 bytes의 배수여야 합니다.
제어어의 내용과 (아마도) 그 전에 온 데이터 버스트는 CRC24를 이용해 비트 오류가 있는지 검사됩니다.
버스트가 CRC24 테스트에 실패하면(즉, 비트 오류가 감지되면) Interlaken Retransmit Extension Protocol Definition에 정의된 대로 재전송을 요청할 수 있습니다. 제안된 메커니즘에 따르면, 이 요청은 수신기에서 송신기로 연결되는 세 개의 물리적 회선을 통해 전송됩니다. 이 회선들은 FC_CLK, FC_DATA , FC_SYNC라는 이름을 가지며, 원래는 out-of-band flow control (OOBFC)용으로 설계되었습니다. flow control 요청을 전송하기 위한 간단한 직렬 데이터 전송 프로토콜이 정의되어 있습니다. 재전송이 활성화된 경우, 이 중 하나의 비트가 "RT"라고 불리며 재전송을 요청하는 데 사용됩니다. 다시 말해, protocol은 MGT 링크 자체에서 재전송 요청을 보내는 방법을 정의하는 것이 아니라, 대역 외의 세 개의 별도 물리적 회선을 통해 요청을 보내는 방법을 정의합니다.
재전송 요청에는 재전송을 시작할 버스트에 대한 정보가 포함되어 있지 않습니다. 대신, 송신 측에서는 buffer에 정의된 양의 버스트 데이터를 저장해야 합니다. 재전송 요청이 도착하면 buffer 에 저장된 모든 버스트가 재전송됩니다. 따라서 buffer 의 크기는 손실된 버스트를 저장할 수 있을 만큼 충분히 커야 합니다. 하지만 buffer 의 크기가 너무 크면 재전송 시간이 불필요하게 길어집니다. buffer의 크기를 정의하려면 버스트를 전송한 시점부터 Interlaken protocol을 구현하는 로직에 도달하여 재전송 요청이 도착할 때까지의 왕복 시간을 신중하게 계산해야 합니다.
수신기는 처음 전송되는 각 버스트마다 증가하는 카운터를 이용하여 재전송된 버스트를 감지합니다(2, 4, 8 등의 버스트마다 카운터를 증가시키는 것도 가능합니다). 이 카운터 값은 각 버스트 전송 전후에 전송되는 제어어의 Multiple-Use 부분에 포함되어 전송됩니다. 수신기는 이 카운터를 사용하여 새로운 버스트와 재전송된 버스트를 구분합니다.
Interlaken protocol 에는 진단 목적으로 CRC32 검사 기능도 있습니다( Meta Frame오류 발생 시마다 한 번씩). 하지만 이 검사를 통해 오류가 감지되더라도, 특정 버스트나 packet오류가 아닌 데이터의 큰 부분과 관련된 오류일 가능성이 높습니다. 즉, bit error오류가 발생했음에도 불구하고 데이터가 CRC24 검사를 통과한 경우, 이는 나중에야 감지되며, 오류가 있는 데이터가 포함된 버스트를 특정할 수는 없습니다.
MGT의 반대 방향 데이터 흐름을 기반으로 하는 재전송 메커니즘을 설계하고 구현하는 것이 가능합니다. Interlaken protocol은 이러한 재전송 메커니즘에 대한 방법을 제시하지는 않지만, packets가 재전송을 요청할 때 전용 채널을 할당하는 것은 가능합니다. 이러한 해결책은 재전송할 대상을 더욱 구체적으로 요청할 수 있게 해주므로 상당한 이점을 제공할 수 있습니다. 또한, 버스트 방식이 아닌 packets 에 더 나은 CRC를 적용하는 것도 가능합니다. 그러나 이 방식을 채택할 경우 전체 메커니즘을 application logic에 구현해야 합니다.
Interlaken의 flow control 메커니즘에 대한 설명은 별도의 페이지 에서 확인할 수 있습니다.
Aurora
Aurora는 Xilinx (현재는 AMD)가 자체 FPGAs를 위해 개발한 protocol 입니다. 이 protocol의 기본 전송 단위는 단일 워드(관련된 MGTs 의 수에 따라 고정된 폭을 가짐)입니다. 그러나 protocol은 packets ( frames라고도 함) 전송도 지원합니다. application logic은 "last" input port를 이용하여 데이터 스트림을 packets 로 분할합니다.
Aurora에는 두 가지 변형이 있습니다. 8b/10b 인코딩 과 64b/66b 인코딩을 사용합니다. 64b/66b 인코딩이 더 효율적이므로 가능하면 이 변형을 사용하는 것이 좋습니다.
Aurora는 simplex link (단방향 물리 채널)와 full duplex link (양방향 물리 채널) 모두에 대해 정의됩니다. application logic의 관점에서 두 옵션 간에는 큰 차이가 없으며, 다만 simplex link에서는 flow control이 무의미하다는 점만 다릅니다.
Interlaken와 달리 Aurora protocol 에는 channels에 대한 언급이 없다는 점에 유의하십시오. 즉, 물리 채널을 통해 전송되는 모든 데이터는 하나의 데이터 스트림에 속합니다. protocol에서 "channel"라는 용어가 사용될 때, 이는 물리 채널을 의미하며 데이터를 독립적인 데이터 스트림으로 분할하는 것을 의미하지 않습니다. 만약 그러한 분할이 필요하다면, application logic에서 이를 구현해야 하며, 각 packet에 header를 추가하는 방식으로 구현할 수 있습니다.
물리 채널의Bit errors 오류는 protocol에서 수정되지 않습니다. 그러나 protocol을 사용하여 packets를 전송할 때, 송신기는 선택적으로 각 packet 끝에 CRC를 추가합니다( Xilinx의 protocol구현에서). protocol구현은 수신 측에서 이 CRC를 검사하고 패킷에서 오류가 감지되면 application logic 에 알립니다. packets 없이( "last" signal없이) Aurora가 사용되는 경우, protocol에서 오류 감지가 지원되지 않습니다.
protocol자체 제어 정보는 bit errors에 대한 어떠한 보호 장치 없이 전송됩니다. 이러한 트래픽에는 CRC가 존재하지 않습니다. 물리적 링크에 bit errors가 있는 경우 protocol은 다양한 방식으로 오작동할 수 있습니다.
모든 재전송 메커니즘, 다중 채널 다중화 및 전송 스케줄링은 application logic에서 구현되어야 합니다. 별도의 페이지 에서 Aurora를 사용하여 flow control을 구현하는 가능성에 대해 설명합니다.
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에서 자주 사용되는 몇 가지 인코딩 방법을 소개합니다.