01signal.com

Flow control: MGTs와 함께 사용하기 위한 방법 및 protocols

中文 | 日本語 | 한국어 | English

이 페이지는 Multi-Gigabit Transceiver (MGT)를 소개하는 일련의 페이지 중 여덟 번째이자 마지막 페이지입니다.

소개

Flow control은 다양한 데이터 링크에서 흔히 사용되는 메커니즘입니다. 이 메커니즘의 목적은 전송되는 데이터 양이 수신 측에서 처리할 수 있는 용량을 초과하는 상황을 방지하는 것입니다.

MGTs 와 관련된Protocols는 이 기능에 대해 서로 다른 수준의 지원을 제공합니다. 예를 들어, PCIe protocol 를 구현하는 logic은 수신측의 buffers가 가득 찬 경우 packet 전송을 절대 수락하지 않습니다. PCIe protocol을 사용하는 application logic은 이와 관련하여 아무것도 구현할 필요가 없습니다. 오히려 application logic 와 PCIe protocol logic 간의 인터페이스를 통해 protocol은 새로운 데이터 수신을 일시적으로 거부할 수 있습니다(예: VALID 및 READY와 같은 AXI-S ports 의 도움을 받음). 마찬가지로 application logic 도 상대방으로부터 도착하는 데이터 수신을 일시적으로 거부할 수 있습니다. 이렇게 함으로써 application logic은 overflow로부터 자신을 보호합니다.

flow control을 MGT자체의 elastic buffer에서 overflow를 방지하는 데 사용되는 메커니즘과 혼동하지 않는 것이 중요합니다. Flow control은 MGT자체의 buffers에 대한 페이지 에서 언급된 skip symbols 와는 전혀 관련이 없습니다. 오히려 flow control은 application logic의 buffers를 보호합니다. 그리고 MGT를 공유 리소스로 사용하는 데이터 채널이 여러 개 있는 경우가 많으므로 flow control은 이러한 각 채널에 대해 개별적으로 독립적으로 적용됩니다.

일반적으로 컴퓨터와의 통신을 정의하는 protocols는 flow control 메커니즘을 담당합니다. application logic은 다른 여러 유형의 logic blocks와 마찬가지로 간단한 handshake ports를 통해 protocol logic 와 인터페이스하기만 하면 됩니다. PCIe 외에도 SuperSpeed USB 와 SATA는 flow control을 자체적으로 처리합니다.

유감스럽게도 FPGAs 간 통신을 위한 protocols는 일반적으로 이 수준에서 flow control을 지원하지 않습니다. flow control을 완벽하게 처리하는 유일한 protocol은 Xillyp2p 입니다. FPGAs 용 다른 protocols는 application logic에서 flow control을 구현할 때 도움이 될 수 있는 몇 가지 기능만 제공합니다.

이 페이지에서는 flow control을 구현하는 몇 가지 기법을 살펴봅니다. Aurora 와 Interlaken이 flow control을 지원하는 방식에 대한 간략한 설명은 뒷부분에 나옵니다. 하지만 Xillyp2p를 사용하는 경우를 제외하고는 overflow를 방지하는 것은 application logic 라는 점을 기억하는 것이 중요합니다.

Flow control 기술

flow control 의 궁극적인 목표는 데이터를 수신하는 측에서 처리할 수 있는 용량보다 더 많은 데이터를 받는 상황을 방지하는 것입니다. 일반적으로 수신 측은 도착하는 데이터를 buffers (또는 FIFO)에 저장하므로, 모든 도착 데이터를 저장할 수 있도록 buffers 에 충분한 공간을 확보하는 것이 핵심입니다.

Flow control은 MGTs와 함께 사용하기 위해 구현하기가 더 어렵습니다. 주된 이유는 물리적 채널에 상당한 지연이 발생하기 때문입니다. 따라서 데이터 전송 중지 요청이 송신기에 도달하는 데 시간이 걸립니다. 또한 송신기가 데이터 전송을 중지한 시점부터 수신기에 데이터가 도착하지 않는 시점까지 일정 시간 간격이 있습니다.

MGTs 의 또 다른 어려움은 물리적 채널에서 bit errors 로 인해 데이터 전송 중지 요청이 손실될 수 있다는 점입니다.

이 두 가지 어려움 외에도 MGTs 의 데이터 전송률은 높기 때문에 일반적으로 이러한 물리적 데이터 채널을 효율적으로 사용해야 한다는 기대가 있습니다.

예를 들어 serial port (RS-232)와 같은 단순한 통신 채널과 비교했을 때, MGT 에 대한 flow control은 overflow가 발생하지 않도록 보장하기 위해 더욱 정교해야 합니다. 아래에서는 세 가지 기술을 설명합니다.

프로젝트에 protocol을 사용할지 고려할 때는 다음 두 가지 질문을 던지는 것이 중요합니다.

In-band 및 out-of-band

이 세 가지 기술을 각각 논의하기 전에 in-band flow control 와 out-of-band flow control의 차이점을 명확히 구분하는 것이 중요합니다.

flow control 메커니즘에서 수신 측은 데이터 흐름을 조절하기 위해 송신 측에 요청이나 정보를 보내야 합니다. 많은 실제 사용 시나리오에서 양방향으로 물리적인 데이터 채널이 존재합니다. 즉, 수신 측은 데이터를 전송하기 위한 반대 방향의 물리적 채널도 가지고 있습니다.

만약 반대 방향으로 물리적인 채널이 존재한다면, 해당 채널을 flow control 요청 전송에 사용하는지 여부가 관건입니다. 만약 채널이 이러한 방식으로 사용된다면, 해당 메커니즘을 in-band flow control라고 부릅니다. 그렇지 않다면 out-of-band flow control이 적용됩니다.

일반적으로 out-of-band flow control은 특히 별도의 물리적 케이블이 필요하기 때문에 그다지 깔끔한 해결책은 아닙니다. 하지만 MGT의 채널이 단방향인 경우에는 이것이 유일한 선택지입니다.

이 주제는 Interlaken이 flow control을 구현하는 방식과 관련하여 아래에서 더 자세히 논의됩니다.

자, 이제 flow control 의 세 가지 기술에 대해 알아보겠습니다.

XON / XOFF

XON / XOFF는 transmit on / off를 의미합니다. 이는 flow control 메커니즘 중 가장 간단한 형태이지만, 몇 가지 중요한 단점이 있습니다.

이 방법은 여러 가지 방식으로 구현할 수 있지만, 기본 아이디어는 항상 동일합니다. 수신기는 더 이상 데이터를 수신할 수 없을 때 송신기에게 "지금 전송을 중지하십시오"라는 의미의 메시지를 보냅니다. 이것이 XOFF 의 의미입니다. 이후 수신기가 데이터를 수신할 수 있게 되면 데이터 전송 재개를 요청하는 XON 메시지를 보냅니다. 이러한 요청은 간단하기 때문에 in-band 와 out-of-band모두에 적합합니다.

위에서 언급한 MGT를 사용한 flow control 관련 모든 어려움은 XON / XOFF 방식을 통해서도 나타납니다. 첫 번째 어려움은 XOFF 요청이 송신기에 도달하는 데 시간이 다소 걸린다는 점입니다. 송신기는 이 요청이 도착할 때까지 데이터 전송을 계속합니다. 또한, 요청이 도착할 때 물리적 채널에 이미 있는 데이터는 수신기로 계속 전송됩니다.

따라서 수신기는 이후에 도착하는 데이터를 처리할 수 있도록 XOFF 신호를 충분히 일찍 보내야 합니다. 하지만 얼마나 일찍 보내야 충분히 이른 것일까요? 이는 물리적 채널의 왕복 시간에 따라 다릅니다. 어떤 시나리오에서는 이 매개변수를 알 수 있거나, 적어도 왕복 시간이 짧다는 것을 알 수 있습니다.

예를 들어, SATA protocol은 XON / XOFF를 사용합니다. 이는 protocol이 SATA controller와 물리적으로 가까운 하드 디스크와의 통신을 위해 설계되었기 때문에 타당합니다. 두 링크 파트너 간의 거리를 알 수 없거나 거리가 멀 경우, XOFF를 요청하는 최적의 시점을 정의하기 어려울 수 있습니다.

또 다른 고려 사항은 송신기가 XOFF를 수신했을 때 즉시 전송을 중지할 수 있는지 여부입니다. 예를 들어, 전송 내용이 packets로 구성된 경우, protocol은 packet전송 도중에 전송을 중지하는 것을 허용하지 않을 수 있습니다. XOFF 또는 XON전송 조건을 정의할 때는 모든 시나리오를 고려해야 합니다.

또 다른 문제는 bit error 오류나 물리적 채널의 다른 문제로 인해 XOFF 메시지가 손실될 경우 어떻게 되는가 하는 것입니다. 이러한 경우 송신기는 데이터 흐름을 계속하여 overflow오류를 발생시킬 수 있습니다. 따라서 protocol은 XOFF 요청 손실 가능성이 있을 때 전송을 중단해야 합니다. Interlaken이 이 문제를 어떻게 해결하는지는 아래를 참조하십시오.

이 메커니즘을 요약하면 다음과 같습니다. XON / XOFF는 간단한 개념에 기반하지만, 이 방법을 사용하여 overflow가 절대 발생하지 않도록 하는 것은 아쉽게도 어렵고 예상치 못한 상황에 세심한 주의를 기울여야 합니다. 아래에서 설명하는 credits 방법은 이와 정반대입니다. 이해하기는 복잡하지만, 목표는 쉽게 달성한다.

기간 한정 XOFF ("Pause")

기간 한정 XOFF는 XON / XOFF 방식의 변형입니다. flow control 요청에는 숫자가 첨부됩니다. 이 숫자는 송신기가 이 요청을 수신한 순간부터 데이터 전송을 일시 중지해야 하는 시간을 나타냅니다. 더 정확히 말하면, 이는 송신기가 데이터를 전송하지 않아야 하는 clock cycles 번호입니다. 이 방식은 Ethernet Pause frame와 유사합니다.

이 방법의 장점은 이후에 XON이 필요하지 않다는 것입니다. 이 기능은 특정 상황에서 유용할 수 있지만, 그 장점조차도 미미합니다.

여기서 시간 제한이 있는 XOFF가 언급되는 유일한 이유는 이 방법이 Aurora Protocol의 일부이기 때문입니다.

Credits

Credits는 통신 채널이 초기화된 이후 전송 가능한 데이터 요소의 최대 개수를 제한하는 값입니다. 이 값은 protocol로 정의된 제어 채널을 통해 수신기에서 송신기로 전송됩니다. 이를 통해 수신기는 자신에게 전송되는 데이터 양을 제어할 수 있습니다.

간단한 예를 들면 가장 잘 설명할 수 있습니다. 수신기의 buffer가 초기에는 1000개의 데이터 요소를 수신할 수 있다고 가정해 보겠습니다. 이에 따라 수신기는 송신기에게 credits가 1000개의 데이터 요소를 수신했다는 메시지를 보냅니다. 송신기는 즉시 1000개의 데이터 요소를 전송할 수도 있고, 나중에 전송할 수도 있습니다. 하지만 credits가 업데이트되지 않는 한, 송신기가 전송하는 총 데이터 요소 수는 1000개를 초과하지 않습니다.

시간이 흘러 500개의 데이터 요소가 수신기에 도착했습니다. 이 과정에서 application logic은 100개의 데이터 요소를 소비했습니다. 따라서 buffer에는 400개의 데이터 워드가 저장되어 있으므로 buffer에는 추가로 600개의 데이터 요소를 저장할 공간이 있습니다.

이 시점에서 수신기는 credits를 1100으로 업데이트하는 또 다른 메시지를 보냅니다. 이는 이미 500개의 데이터 요소가 도착했고, application logic이 buffer에서 데이터를 소비하지 않더라도 600개의 데이터 요소를 더 수신할 수 있음을 나타냅니다. 따라서 송신기가 처음부터 총 1100개의 데이터 요소를 전송했다면 buffer는 채워진 상태가 됩니다. 다른 관점에서 보면 다음과 같습니다. 수신기는 buffer에서 소비되는 데이터 요소의 수만큼 credits 값을 항상 증가시킵니다.

이 메커니즘은 송신기가 수신기가 허용한 것보다 더 많은 데이터를 전송하지 않도록 함으로써 overflow 오류를 방지합니다. 하지만 이 방법에는 두 가지 사소하지만 중요한 문제가 있습니다.

첫 번째 문제는 수신기와 송신기가 전송되는 데이터 요소의 개수가 0인 시작점에 합의해야 한다는 것입니다. 이를 위해서는 양측 모두 counters를 재설정하는 일종의 초기화 절차가 필요합니다. credits를 사용하는 모든 protocols는 이와 유사한 초기 시작 절차를 가지고 있습니다. 이는 protocol을 복잡하게 만드는데, 양측 모두 동시에 하나의 state 에서 다른 state 로 전환할 수 있어야 하기 때문입니다.

두 번째 문제는 데이터 흐름이 무한히 지속되어야 한다는 것입니다. credits는 계속 증가합니다. 어떻게 제한된 비트 수를 가진 숫자로 credits를 전송할 수 있을까요? 이 질문에 대한 답은 credits 의 이진 표현의 하위 부분(즉, LSbs만)을 전송하는 것으로 충분하다는 것입니다. 송신기는 전송한 데이터 요소의 개수를 나타내기 위해 동일한 개수의 bits를 사용합니다.

송신기는 credits를 전송 가능한 데이터 요소 수를 계산하는 용도로만 사용하기 때문에 이 정도면 충분합니다. 이 수는 credits 에서 이미 전송한 데이터 요소 수를 뺀 값으로 계산됩니다. 따라서 이 값은 수신기에서 buffer 의 크기보다 클 수 없습니다. 만약 이 값이 2n보다 작으면 n LSbs 이상의 모든 bits는 0이 되므로 계산할 필요가 없습니다. n bits만 사용하여 뺄셈을 수행하면 충분합니다. 그러므로 flow control 요청에서는 credits 의 이진 표현 중 더 작은 값인 n bits 만 필요합니다.

예를 들어, PCIe의 flow control은 flow control이 보호하는 buffer 의 유형에 따라 8 bits 또는 12 bits로 구성된 이진 단어로 credits를 전송하는 것을 기반으로 합니다.

credits를 사용하면 많은 장점이 있습니다.

Flow control 와 Interlaken

Interlaken protocol은 다른 페이지 에서 간략하게 소개됩니다.

flow control에 대해 논의할 때, protocol은 각 데이터 버스트에 채널 번호(일반적으로 0에서 255 사이)를 할당한다는 점에 유의하십시오. 즉, protocol은 물리적 채널을 공유하는 여러 개의 application data 스트림 개념을 기반으로 합니다. 따라서 flow control 메커니즘은 각 application data 스트림을 독립적으로 제어합니다.

이 protocol 모델은 두 가지 유형의 flow control 메커니즘을 제공합니다. In-band flow control 및 out-of-band flow control (OOBFC)는 모두 XON/XOFF 메커니즘입니다. 상태는 각 channel에 대해 하나의 bit을 통해 전달됩니다. 이 bit은 해당 채널이 데이터 수신 준비 상태(XON)일 때 '1'이고, 그렇지 않을 때(XOFF) '0'입니다.

이 두 메커니즘의 차이점은 bits가 전송되는 방식에 있습니다. in-band flow control 메커니즘은 각 버스트 전후에 control word가 전송된다는 사실에 기반합니다. 이 control word는 64 bits로 구성되며, 그중 16 bits는 flow control용도로 할당됩니다. 따라서 각 control word에 대해 최대 16개의 XON / XOFF 요청이 가능합니다. 하지만 이는 최대 256개 채널을 지원하기에는 충분하지 않습니다. 각 채널에는 고유한 XON / XOFF bit이 있습니다. 이를 해결하기 위해 flow control 정보를 여러 개의 control words로 분할합니다. 이 방법을 calendar 라고 합니다. control word 내의 Bit 56은 "Reset Calendar"라고 합니다. 이 bit이 "1"인 경우, control word 에는 채널 0부터 15까지의 XON / XOFF 요청이 포함됩니다. 그 다음 control word 에는 채널 16부터 31까지의 요청이 포함되고, 이런 식으로 계속됩니다. 모든 채널에 대한 요청이 완료되면(단 하나의 control word로 완료될 수도 있음), "Reset Calendar"를 사용하여 이 과정을 다시 시작합니다.

버스트의 CRC24에 의해 bit error가 감지되면 모든 채널은 XOFF 상태로 전환됩니다. 이는 CRC24가 control word까지 포함하기 때문에 오류가 감지될 경우 flow control 부분은 무시되기 때문입니다. 따라서 이러한 상황이 발생한 후에는 어떤 채널에서도 송신하는 것이 안전하지 않습니다. 정상적인 작동은 뒤이어 발생하는 control words 의 flow control 요청에 따라 점진적으로 재개됩니다.

in-band flow control 의 주요 단점은 XON / XOFF 요청의 전달이 동일 방향으로 전송되는 데이터 버스트에 의존한다는 점입니다. 이러한 버스트가 길거나 일정 시간 동안 버스트가 전혀 전송되지 않으면 XON / XOFF 전달에 더 오랜 시간이 걸릴 수 있습니다. 이는 동일한 물리적 채널에서 전송되는 데이터 전송과 flow control 메시지가 대역폭을 놓고 경쟁하는 것이 불가피하기 때문에 어느 정도 정당화될 수 있습니다. 그러나 일반적으로 다른 protocols 방식은 flow control 메시지의 우선순위를 지정하여 최대 지연 시간을 일정하게 유지합니다.

out-of-band flow control (OOBFC) 대안은 데이터 버스트와의 경쟁을 피합니다. 이 방식에서는 XON / XOFF 요청이 세 개의 추가 물리적 회선(FC_CLK, FC_DATA 및 FC_SYNC)을 통해 전송됩니다. 모든 채널의 XON / XOFF bits는 하나의 긴 frame로 전송됩니다.

FC_SYNC signal은 high 와 이 frame의 첫 번째 bit을 포함합니다. FC_CLK 의 frequency는 0 와 100 MHz 사이에 있으며 DDR clocking이 허용됩니다. 4 bits (CRC-4)로 구성된 CRC는 64개의 XON / XOFF 요청 이후 또는 마지막 요청 이후에 삽입됩니다. CRC로 인해 오류가 감지되면 모든 채널은 XOFF 상태로 전환됩니다.

in-band flow control 와 out-of-band flow control 중 어떤 것을 선택할지는 물론 프로젝트 요구 사항에 따라 달라집니다.

Interlaken은 채널 간 데이터 다중화를 위한 메커니즘을 포함하지 않습니다. 따라서 application logic은 채널들의 데이터 전송 요청을 중재하고, 버스트(또는 전체 packet) 전송 권한을 어떤 채널에 부여할지 결정해야 합니다. 또한 application logic은 XOFF에서 필요로 하는 경우 특정 채널의 전송을 일시 중지하는 역할도 담당합니다. Interlaken protocol을 구현하는 logic은 XON / XOFF 요청을 송수신하는 역할만 합니다.

protocol은 flow control을 구현하는 한 가지 방법으로 credits를 언급하지만, 이는 전용 채널을 통해 이 방법을 구현할 수 있도록 허용하는 것에 불과합니다. protocol 에는 이 방법을 구현하는 방법에 대한 자세한 내용은 없습니다.

Flow control 와 Aurora

Aurora protocol은 다른 페이지 에서 간략하게 소개됩니다. 이 protocol은 flow control을 용이하게 하는 두 가지 메커니즘을 제안합니다. NFC 와 UFC. 이 두 제품은 아래에서 각각 별도로 설명합니다.

먼저, Native Flow Control (NFC)입니다. 이 메커니즘을 통해 수신 측의 application logic은 송신 측으로 flow control 요청을 전송하기 위한 인터페이스를 갖습니다. 이러한 요청은 두 부분으로 구성됩니다. XOFF bit 와 시간 제한형 XOFF ("pause") 부품(두 개념 모두 위에서 설명됨)이 있습니다. 송신기 측의 protocol의 logic은 이러한 요청을 처리하는 역할을 합니다. XOFF bit이 '0'인 경우, 송신기는 flow control 요청에 포함된 8비트 숫자에 해당하는 clock cycles 횟수만큼 데이터 전송을 일시 중지합니다. 이 숫자가 0이면 데이터 전송은 즉시 재개됩니다. 요청에 포함된 숫자는 누적되지 않고, 각 NFC 요청이 일시 중지 카운트다운을 새로운 값으로 업데이트합니다.

XOFF bit이 '1'인 경우, 송신기는 데이터 전송을 무기한으로 일시 중지합니다. 송신기는 XOFF = '0'을 포함하는 flow control 요청에 응답할 때만 데이터 전송을 재개합니다. 이러한 요청은 위에서 설명한 대로 처리됩니다.

참고로, flow control 메커니즘은 물리적 데이터 채널을 통한 모든 데이터 트래픽을 제어합니다. 따라서 NFC는 여러 채널을 개별적으로 제어하는 데에는 적합하지 않습니다(이러한 기능이 구현된 경우).

두 번째 메커니즘은 User Flow Control (UFC)입니다. 실제로 이는 최대 256바이트의 메시지를 상대방에게 전송하기 위한 별도의 채널입니다. UFC 메시지는 데이터 전송보다 우선순위가 높기 때문에 지연 시간이 짧아 상대방에게 빠르게 도달합니다.

프로토콜에서 이러한 메시지의 형식을 정의하지 않으므로, 이를 사용하여 어떤 유형의 flow control 든 구현할 수 있습니다. 이러한 구현은 application logic에서 완전히 이루어집니다. UFC 메시지는 다른 종류의 상태 정보를 전송하는 데에도 사용할 수 있습니다.

참고로, 이 두 가지 flow control 메커니즘에서 사용되는 메시지는 물리적 링크에서 bit errors 공격으로부터 보호되지 않습니다. 따라서 flow control 요청이 잘못 도착하거나 전혀 도착하지 않을 수 있으며, 이로 인해 수신측에서 overflow 오류가 발생할 수 있습니다.

두 가지 흐름 제어 메커니즘 모두 반대 방향의 데이터 링크를 기반으로 하므로 full duplex 모드에서만 사용할 수 있습니다.

요약

이 페이지에서는 flow control 에 대한 두 가지 주요 기술이 소개되었습니다. XON / XOFF 및 credits. 컴퓨터 관련 protocols (예: PCIe, SuperSpeed USB 및 SATA)의 경우, flow control은 protocol logic에서 구현됩니다. 반면, FPGAs간의 통신을 위한 protocols 의 경우, application logic이 구현의 전부 또는 대부분을 담당합니다. 유일한 예외는 Xillyp2p로, flow control을 포함한 데이터 통신의 모든 측면, 즉 오류 감지 및 재전송을 처리합니다.

FPGAs 용 protocols 두 대의 flow control 관련 기능이 제시되었습니다. Interlaken 및 Aurora. 보시는 바와 같이, 이러한 protocols는 flow control 구현의 더 큰 부담을 application logic에 맡기지만, 특정 사용 시나리오에서는 protocol자체의 기능이 일부 작업을 수행할 수도 있습니다.

이것으로 MGTs에 대한 시리즈 의 마지막 페이지를 마치겠습니다.

이 페이지는 영어에서 자동으로 번역됩니다. 불분명한 사항이 있으면 원본 페이지를 참조하십시오.
Copyright © 2021-2026. All rights reserved. (62b1b7b8)