01signal.com

흐름 제어: MGT와 함께 사용하는 기법 및 프로토콜

中文 | 日本語 | 한국어 | Français | Deutsch | Español | English

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

소개

흐름 제어(flow control)는 다양한 유형의 데이터 링크에서 자주 사용되는 메커니즘입니다. 이 메커니즘의 목적은 전송되는 데이터의 양이 수신 측이 처리할 수 있는 양보다 많아지는 상황을 방지하는 것입니다.

MGT와 관련된 프로토콜들은 이 기능을 서로 다른 수준으로 지원합니다. 예를 들어 PCIe 프로토콜을 구현하는 로직은 수신 측의 버퍼가 가득 차 있으면 전송용 패킷을 절대 받아들이지 않습니다. PCIe 프로토콜을 사용하는 애플리케이션 로직은 이와 관련하여 아무것도 구현할 필요가 없습니다. 대신 애플리케이션 로직과 PCIe 프로토콜 로직 사이의 인터페이스는 프로토콜이 새 데이터의 수용을 일시적으로 거부할 수 있게 해 줍니다(예: VALID, READY와 같은 AXI-S 포트를 이용). 마찬가지로 애플리케이션 로직도 반대편에서 도착하는 데이터를 일시적으로 거부할 수 있습니다. 이렇게 함으로써 애플리케이션 로직은 자신을 오버플로(overflow)로부터 보호합니다.

흐름 제어를 MGT 자체의 탄력 버퍼(elastic buffer)에서 오버플로를 방지하는 메커니즘과 혼동하지 않는 것이 중요합니다. 흐름 제어는 MGT 자체 버퍼에 관한 페이지에서 언급한 스킵 심볼과는 아무 관련이 없습니다. 오히려 흐름 제어는 애플리케이션 로직의 버퍼를 보호합니다. 또한 MGT를 공유 리소스로 사용하는 여러 데이터 채널이 흔히 있으므로, 흐름 제어는 각 채널마다 별도로 그리고 독립적으로 적용됩니다.

일반적으로 컴퓨터와의 통신을 규정하는 프로토콜은 흐름 제어 메커니즘을 자체적으로 처리합니다. 애플리케이션 로직은 다른 많은 로직 블록과 마찬가지로 단순한 핸드셰이크 포트를 통해 프로토콜 로직과 인터페이스하기만 하면 됩니다. 또한 PCIe, SuperSpeed USB, SATA도 흐름 제어를 자체적으로 처리합니다.

안타깝게도 FPGA 간 통신용 프로토콜은 보통 이 수준의 흐름 제어를 지원하지 않습니다. 흐름 제어를 완전히 처리하는 유일한 프로토콜은 Xillyp2p입니다. 그 밖의 FPGA용 프로토콜들은 애플리케이션 로직에서 흐름 제어를 구현할 때 도움이 될 수 있는 몇 가지 기능만 제공할 뿐입니다.

이 페이지에서는 흐름 제어를 구현하는 몇 가지 기법을 살펴봅니다. Aurora와 Interlaken이 흐름 제어를 어떻게 지원하는지에 대한 간략한 요약은 뒤에서 제공합니다. 그렇지만 Xillyp2p를 사용하는 경우를 제외하고는, 오버플로를 방지할 책임이 애플리케이션 로직에 있다는 점을 기억하는 것이 중요합니다.

흐름 제어 기법

흐름 제어의 궁극적인 목표는 데이터를 수신하는 측이 처리할 수 있는 것보다 더 많은 데이터를 받는 상황을 방지하는 것입니다. 수신 측은 보통 도착하는 데이터를 버퍼(또는 FIFO)에 저장하므로, 결국 도착하는 모든 데이터를 저장할 공간이 버퍼에 남아 있도록 하는 문제로 귀결됩니다.

흐름 제어를 MGT와 함께 사용하도록 구현하는 것은 더 어렵습니다. 주된 이유는 물리 채널의 지연이 상당하기 때문입니다. 따라서 데이터 전송을 중단하라는 요청이 송신기에 도착하는 데도 시간이 걸립니다. 게다가 송신기가 데이터 전송을 중단한 시점부터 수신기에 데이터 도착이 멈출 때까지도 일정한 시간이 걸립니다.

MGT와 관련된 또 다른 어려움은 물리 채널의 비트 오류로 인해 데이터 전송 중단 요청이 유실될 수 있다는 것입니다.

이 두 가지 어려움 외에도, MGT의 데이터 속도는 높으며 보통 이 물리 데이터 채널을 효율적으로 사용해야 한다는 기대도 있습니다.

예를 들어 직렬 포트(RS-232)와 같은 더 단순한 통신 채널과 비교할 때, MGT의 흐름 제어는 오버플로가 발생하지 않음을 보장하기 위해 더 정교해야 합니다. 다음의 세 가지 기법은 아래에서 설명합니다.

프로젝트에서 사용할 프로토콜을 고려할 때, 다음 두 가지 질문을 하는 것이 중요합니다.

대역 내(in-band) 및 대역 외(out-of-band)

이 세 가지 기법을 각각 논의하기 전에, 대역 내 흐름 제어(in-band flow control)와 대역 외 흐름 제어(out-of-band flow control)를 구분하는 것이 중요합니다.

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

이런 반대 방향 물리 채널이 있다면, 그 채널을 흐름 제어 요청 전송에 사용할지가 문제입니다. 그렇게 사용하면 그 메커니즘을 대역 내 흐름 제어라고 하며, 그렇지 않으면 대역 외 흐름 제어가 적용됩니다.

일반적으로 대역 외 흐름 제어는 덜 우아한 해결책입니다. 특히 이 용도로 별도의 물리적 전선이 필요하기 때문입니다. 하지만 MGT의 채널이 단방향이라면 이것이 유일한 가능성입니다.

이 주제는 아래에서 Interlaken이 흐름 제어를 구현하는 방식과 관련하여 더 자세히 논의합니다.

이제 세 가지 흐름 제어 기법에 대해 살펴보겠습니다.

XON / XOFF

XON / XOFF는 transmit on/off를 뜻합니다. 이것은 가장 간단한 흐름 제어 메커니즘이지만 몇 가지 중요한 단점이 있습니다.

이 방법은 여러 방식으로 구현할 수 있지만, 아이디어는 항상 동일합니다. 수신기가 더 이상 데이터를 받을 수 없을 때, 수신기는 송신기에게 '지금 전송을 중단하라'는 의미의 메시지를 보냅니다. 이것이 XOFF의 의미입니다. 나중에 수신기가 데이터를 받을 수 있게 되면, 데이터 흐름의 재개를 요청하기 위해 XON이 전송됩니다. 이 요청들 자체는 단순하므로 대역 내(in-band) 방식과 대역 외(out-of-band) 방식 어느 쪽으로든 전송하기에 적합합니다.

위에서 언급한 MGT 흐름 제어의 모든 어려움은 XON / XOFF 방식에서 그대로 드러납니다. 첫 번째 어려움은 XOFF 요청이 송신기에 도착하는 데 시간이 걸린다는 것입니다. 송신기는 이 요청이 도착할 때까지 데이터를 계속 보냅니다. 게다가 요청이 도착할 때 이미 물리 채널에 있던 데이터는 계속해서 수신기에 도착합니다.

따라서 수신기는 이후에 도착하는 데이터를 여전히 처리할 수 있도록 XOFF를 충분히 일찍 보내야 합니다. 하지만 얼마나 일찍 보내야 충분할까요? 그것은 물리 채널의 왕복 시간(round-trip time)에 따라 달라집니다. 일부 시나리오에서는 이 매개변수를 알고 있거나, 적어도 왕복 시간이 짧다는 것을 알고 있습니다.

예를 들어 SATA 프로토콜은 XON / XOFF를 사용합니다. SATA 프로토콜은 SATA 컨트롤러와 물리적으로 가까운 하드 디스크와의 통신을 위해 만들어졌으므로 이는 타당합니다. 두 링크 상대 사이의 거리를 알 수 없고 그 거리가 클 가능성이 있다면, XOFF를 요청해야 하는 최적의 시점을 정하기가 어려울 수 있습니다.

또 다른 요소는 송신기가 XOFF를 받았을 때 즉시 중단할 수 있는지 여부입니다. 예를 들어 전송 내용이 패킷으로 구성된 경우, 프로토콜은 패킷 중간에 전송을 중단하는 것을 허용하지 않을 수 있습니다. XOFF나 XON을 보내는 조건을 정의할 때는 이러한 모든 시나리오를 고려해야 합니다.

또 다른 문제는 XOFF 메시지가 비트 오류나 물리 채널의 다른 장애로 인해 유실되면 어떻게 되느냐는 것입니다. 이런 일이 발생하면 송신기가 데이터 흐름을 계속해서 오버플로가 생길 수 있습니다. 따라서 프로토콜은 XOFF 요청이 유실될 가능성이 있을 때 전송이 중단되도록 보장해야 합니다. Interlaken이 이 문제를 어떻게 다루는지는 아래를 참조하십시오.

이 메커니즘을 요약하면 다음과 같습니다. XON / XOFF는 쉬운 개념에 기반하지만, 이 방법을 사용해 오버플로가 절대 발생하지 않도록 하는 것은 불행히도 어렵고, 예상치 못한 시나리오에 세심한 주의를 기울여야 합니다. 아래에서 논의할 크레딧(credits) 방법은 그와 반대입니다. 이해하기는 복잡하지만 목표를 쉽게 달성합니다.

시간 제한 XOFF('Pause')

시간 제한 XOFF('Pause')는 XON / XOFF 방식의 변형입니다. 흐름 제어 요청에 숫자가 첨부됩니다. 이 숫자는 송신기가 이 요청을 받은 시점부터 데이터 전송을 얼마나 오랫동안 일시 중지해야 하는지를 나타냅니다. 더 정확히 말하면, 송신기가 데이터를 보내지 말아야 하는 클록 주기의 수입니다. 이 방식은 이더넷의 PAUSE 프레임(Pause frame)과 비슷합니다.

이 방식의 장점은 이후에 XON이 필요하지 않다는 것입니다. 이 기능은 특정 상황에서 유용할 수 있지만, 그 경우에도 장점은 상당히 작습니다.

여기서 시간 제한 XOFF를 언급하는 유일한 이유는 이 방식이 Aurora 프로토콜의 일부이기 때문입니다.

크레딧(credits)

크레딧(credits)은 통신 채널이 초기화된 이후 전송이 허용되는 데이터 요소의 개수에 대한 제한입니다. 이 숫자는 프로토콜이 정의하는 어떤 형태의 제어 채널을 통해 수신기에서 송신기로 전송됩니다. 이렇게 함으로써 수신기는 자신에게 전송되는 데이터의 양을 제어합니다.

이것은 간단한 예로 설명하는 것이 가장 좋습니다. 수신기의 버퍼가 처음에 데이터 요소 1000개를 수신할 수 있다고 가정해 보겠습니다. 그러면 수신기는 크레딧이 데이터 요소 1000개라는 메시지를 송신기로 보냅니다. 송신기는 데이터 요소 1000개를 즉시 보낼 수도 있고 나중에 보낼 수도 있습니다. 그러나 크레딧이 갱신되지 않는 한, 송신기가 보내는 데이터 요소의 총 개수는 1000개를 초과하지 않습니다.

시간이 조금 지나 데이터 요소 500개가 수신기에 도착했다고 합시다. 그동안 애플리케이션 로직은 데이터 요소 100개를 소비했습니다. 이 상황에서 버퍼에는 데이터 워드 400개가 있으므로, 버퍼에는 추가로 데이터 요소 600개를 더 저장할 공간이 있습니다.

이 시점에서 수신기는 크레딧을 1100으로 갱신하는 또 다른 메시지를 보냅니다. 이것은 데이터 요소 500개가 이미 도착했고, 애플리케이션 로직이 버퍼에서 데이터를 소비하지 않더라도 추가로 600개가 허용된다는 사실을 반영합니다. 따라서 송신기가 처음부터 총 1100개의 데이터 요소를 보냈다면 버퍼는 가득 차게 됩니다. 다른 방식으로 보면, 수신기는 버퍼에서 소비된 데이터 요소의 개수만큼 크레딧을 항상 증가시킵니다.

이 메커니즘은 송신기가 수신기가 허용한 양보다 더 많은 데이터를 절대 보내지 않기 때문에 오버플로가 발생하지 않도록 보장합니다. 다만 이 방식에는 두 가지 미묘한 문제가 있습니다.

첫 번째 문제는 수신기와 송신기가 전송된 데이터 요소의 개수가 0인 시작점에 동의해야 한다는 것입니다. 이를 위해서는 양쪽이 카운터를 리셋하는 어떤 종류의 초기화 절차가 필요합니다. 크레딧을 사용하는 모든 프로토콜에는 어떤 형태로든 초기 시작 절차가 있습니다. 이 절차는 양쪽이 동시에 한 상태에서 다른 상태로 전환할 수 있어야 하므로 프로토콜을 복잡하게 만듭니다.

두 번째 문제는 데이터 흐름이 영원히 계속될 수 있어야 한다는 것입니다. 크레딧은 계속 증가합니다. 그렇다면 제한된 비트 수의 숫자로 크레딧을 보내는 것이 어떻게 가능할까요? 이 질문에 대한 답은 크레딧의 이진 표현에서 하위 부분, 즉 LSB들만 보내면 충분하다는 것입니다. 송신기는 자신이 전송한 데이터 요소의 개수를 나타낼 때도 동일한 비트 수를 사용합니다.

이렇게 해도 충분한 이유는 송신기가 크레딧을 전송이 허용된 데이터 요소의 개수를 계산하는 데만 사용하기 때문입니다. 이 숫자는 크레딧에서 이미 전송한 데이터 요소의 개수를 뺀 값으로 계산됩니다. 그 결과는 수신기 버퍼의 크기보다 클 수 없습니다. 이 숫자가 2n보다 작다면, n개의 LSB 위에 있는 모든 비트는 0입니다. 따라서 그 비트들을 계산하는 것은 의미가 없습니다. n비트만으로 뺄셈을 수행하면 충분합니다. 그러므로 흐름 제어 요청에는 크레딧의 이진 표현 중 하위 n비트만 있으면 됩니다.

예를 들어, PCIe의 흐름 제어는 흐름 제어가 보호하는 버퍼의 유형에 따라 크레딧을 8비트 또는 12비트로 구성된 이진 워드로 전송하는 방식에 기반합니다.

크레딧을 사용하면 많은 장점이 있습니다.

Interlaken에서의 흐름 제어

Interlaken 프로토콜은 다른 페이지에서 간략히 소개되어 있습니다.

흐름 제어를 논의하기 위해, 이 프로토콜이 각 데이터 버스트에 채널 번호(보통 0에서 255 사이)를 할당한다는 점을 유의하십시오. 다시 말해, 이 프로토콜은 물리 채널을 공유하는 여러 애플리케이션 데이터 스트림이라는 개념에 기반합니다. 따라서 흐름 제어 메커니즘은 각 애플리케이션 데이터 스트림을 독립적으로 제어합니다.

이 프로토콜은 두 가지 유형의 흐름 제어 메커니즘을 제공합니다. 대역 내(in-band) 흐름 제어와 대역 외(out-of-band) 흐름 제어(OOBFC)가 그것입니다. 둘 다 XON / XOFF 메커니즘입니다. 상태는 각 채널마다 하나의 비트로 전달됩니다. 이 비트는 해당 채널이 데이터를 수신할 준비가 되었으면 '1'(XON), 그렇지 않으면 '0'(XOFF)입니다.

이 두 메커니즘의 차이는 바로 이 비트들이 어떻게 전송되느냐입니다. 대역 내 흐름 제어 메커니즘은 각 버스트의 앞뒤로 제어 워드가 전송된다는 사실에 의존합니다. 이 제어 워드는 64비트로 구성되며, 그중 16비트가 흐름 제어 목적으로 할당됩니다. 따라서 각 제어 워드마다 최대 16개의 XON / XOFF 요청을 보낼 수 있습니다. 그러나 이것으로는 최대 256개 채널을 지원하기에 충분하지 않습니다. 각 채널에는 고유한 XON / XOFF 비트가 있기 때문입니다. 이 문제를 해결하기 위해 흐름 제어 정보는 여러 제어 워드로 나뉩니다. 이 방식을 캘린더(calendar)라고 합니다. 제어 워드의 56번째 비트는 'Reset Calendar'라고 부릅니다. 이 비트가 '1'이면 해당 제어 워드에는 채널 0부터 15까지의 XON / XOFF 요청이 들어 있습니다. 그다음 제어 워드에는 채널 16부터 31까지의 요청이 포함되며, 이런 식으로 계속됩니다. 모든 채널이 처리되고 나면(어쩌면 제어 워드 하나만으로도 충분할 수 있음), 'Reset Calendar'를 이용해 이 순서가 다시 시작됩니다.

버스트의 CRC24로 비트 오류가 검출되면 모든 채널이 XOFF 상태로 들어갑니다. 그 이유는 CRC24가 제어 워드도 포함하므로, 오류가 검출되면 흐름 제어 부분이 무시되기 때문입니다. 따라서 이런 사건이 발생한 후에는 어떤 채널에서도 전송하는 것이 안전하지 않습니다. 정상 동작은 뒤따르는 제어 워드들의 흐름 제어 요청에 따라 점진적으로 재개됩니다.

대역 내 흐름 제어의 주요 단점은 XON / XOFF 요청의 전달이 같은 방향으로 전송되는 데이터 버스트에 의존한다는 것입니다. 이 버스트들이 길거나, 일정 시간 동안 버스트가 전혀 전송되지 않으면 XON / XOFF 전달이 더 오래 걸릴 수 있습니다. 같은 물리 채널에서 전송되는 데이터와 흐름 제어 메시지가 대역폭을 두고 서로 경쟁하는 것은 피할 수 없으므로, 이것은 어느 정도 정당화될 수 있습니다. 그러나 다른 프로토콜들은 보통 일정한 최대 지연을 보장하는 방식으로 흐름 제어 메시지에 우선순위를 부여합니다.

대역 외 흐름 제어(OOBFC) 방식은 데이터 버스트와의 경쟁을 피합니다. 이 방식에서는 XON / XOFF 요청이 세 개의 추가 물리 전선(FC_CLK, FC_DATA, FC_SYNC)을 통해 전송됩니다. 모든 채널의 XON / XOFF 비트는 하나의 긴 프레임으로 전송됩니다.

FC_SYNC 신호는 이 프레임의 첫 번째 비트와 함께 high가 됩니다. FC_CLK의 주파수는 0~100MHz이며 DDR 클로킹이 허용됩니다. 4비트로 구성된 CRC(CRC-4)는 XON / XOFF 요청 64개 뒤 또는 마지막 요청 뒤에 삽입됩니다. CRC를 통해 오류가 검출되면 모든 채널이 XOFF 상태로 들어갑니다.

물론 대역 내 흐름 제어와 대역 외 흐름 제어 사이의 선택은 프로젝트의 요구 사항에 따라 달라집니다.

Interlaken에는 채널들의 데이터를 다중화하는 메커니즘이 포함되어 있지 않습니다. 따라서 각 채널의 데이터 전송 요청 사이에서 중재하고, 어느 채널이 버스트(또는 전체 패킷)를 전송할 수 있는지 선택하는 일은 애플리케이션 로직의 몫입니다. 그러므로 XOFF가 요구할 때 특정 채널의 전송을 일시 중지하는 일도 애플리케이션 로직의 책임입니다. Interlaken 프로토콜을 구현하는 로직은 XON / XOFF 요청을 보내고 받는 일만 담당합니다.

프로토콜은 크레딧을 흐름 제어 구현의 한 가지 가능성으로 언급하지만, 다만 전용 채널을 통해 이 방법을 구현하라는 권고 정도로만 언급합니다. 이 방법을 어떻게 구현할지에 대한 세부 사항은 프로토콜에 없습니다.

Aurora에서의 흐름 제어

Aurora 프로토콜은 다른 페이지에서 간략히 소개됩니다. 이 프로토콜은 흐름 제어를 용이하게 하는 두 가지 메커니즘, 즉 NFC와 UFC를 제안합니다. 이 두 가지는 아래에서 각각 설명합니다.

첫 번째는 NFC(Native Flow Control)입니다. 이 메커니즘에서 수신 측 애플리케이션 로직에는 송신기로 흐름 제어 요청을 보내는 인터페이스가 있습니다. 이 요청은 두 개의 별도 부분, 즉 XOFF 비트와 시간 제한 XOFF('Pause') 부분으로 구성됩니다(두 개념 모두 위에서 설명했습니다). 송신 측의 프로토콜 로직은 이 요청을 따를 책임이 있습니다. XOFF 비트가 '0'이면 송신기는 흐름 제어 요청에 포함된 8비트 숫자에 해당하는 클록 주기 수만큼 데이터 전송을 일시 중지합니다. 이 숫자가 0이면 데이터 전송은 즉시 재개됩니다. 요청의 숫자들은 누적되지 않습니다. 대신 각 NFC 요청은 일시 중지의 카운트다운을 새 값으로 갱신합니다.

XOFF 비트가 '1'이면 송신기는 데이터 전송을 무기한 일시 중지합니다. 송신기는 XOFF = '0'인 흐름 제어 요청이 있을 때만 데이터 전송을 재개합니다. 그러한 요청은 위에서 언급한 대로 처리됩니다.

이 흐름 제어 메커니즘은 물리 데이터 채널을 통과하는 모든 데이터 트래픽을 제어한다는 점에 유의하십시오. 따라서 NFC는 여러 채널이 구현된 경우 각 채널을 개별적으로 제어하는 데는 적합하지 않습니다.

두 번째 메커니즘은 UFC(User Flow Control)입니다. 실제로 이것은 최대 256바이트의 메시지를 반대편으로 전송하기 위한 별도의 채널입니다. UFC 메시지는 데이터 전송보다 우선순위가 높으므로 낮은 대기 시간으로 반대편에 도달합니다.

프로토콜은 이 메시지들의 형식을 정의하지 않으므로, 이 메시지들을 사용해 어떤 유형의 흐름 제어든 구현할 수 있습니다. 그러한 구현은 전적으로 애플리케이션 로직에서 이루어집니다. UFC 메시지는 다른 종류의 상태 정보를 전송하는 데에도 사용할 수 있습니다.

이 두 흐름 제어 메커니즘에서 사용되는 어떤 메시지도 물리 링크의 비트 오류로부터 보호되지 않는다는 점에 유의하십시오. 따라서 흐름 제어 요청이 잘못 도착하거나 전혀 도착하지 않을 수 있으며, 이로 인해 수신기에서 오버플로가 발생할 수 있습니다.

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

요약

이 페이지에서는 주로 두 가지 흐름 제어 기법, 즉 XON / XOFF와 크레딧(credits)을 소개했습니다. 컴퓨터와 관련된 프로토콜(예: PCIe, SuperSpeed USB, SATA)에서는 흐름 제어가 프로토콜 로직으로 구현됩니다. 반면 FPGA 간 통신용 프로토콜에서는 애플리케이션 로직이 전부 또는 대부분의 구현을 담당합니다. 유일한 예외는 Xillyp2p인데, 이 프로토콜은 흐름 제어, 오류 검출, 재전송을 포함한 데이터 통신의 모든 측면을 처리합니다.

또한 FPGA용 두 프로토콜, 즉 Interlaken과 Aurora의 흐름 제어 관련 기능을 살펴보았습니다. 위에서 본 것처럼, 이 프로토콜들은 특정 사용 시나리오에서 프로토콜 자체의 기능이 일부 작업을 처리해 주기도 하지만, 흐름 제어 구현의 더 큰 부담은 애플리케이션 로직에 남겨 둡니다.

이것으로 MGT에 관한 이 시리즈의 마지막 페이지를 마칩니다.

이 페이지는 영어 원문을 기계 번역한 것입니다. 의문이 드는 부분이 있으면 원문을 참조하시기 바랍니다.
Copyright © 2021-2026. All rights reserved. (dcc38493)