24 августа 2014 в 13:47

Взгляд на 10G Ethernet со стороны FPGA разработчика из песочницы

Всем привет!

Многие специалисты знают, что топовое сетевое оборудование использует специальные чипы для обработки трафика. Я принимаю участие в разработке таких молотилок и хочу поделиться своим опытом в создании таких высокопроизводительных девайсов (со интерфейсами 10/40/100G Ethernet).

Для создания нового канала сетевики чаще всего берут оптику, пару SFP+ модулей, втыкают их в девайсы: лампочки радостно загораются, пакеты начинают приходить: чип начинает их передавать получателям. Но как чип получает пакеты из среды передачи? Если интересно, то добро пожаловать под кат.

IEEE 802.3


Ethernet — это стандарт, принятый ассоциацией IEEE. Стандарты 802.3 охватывают все возможные разновидности Ethernet (от 10M до 100G). Сконцентрируемся на конкретной реализации физического уровня: 10GBASE-R («обычный» 10G, без излишеств).


На этом рисунке показаны уровни модели OSI и то, как они отображаются на подуровни протокола Ethernet.

Подуровни:
  • PHY — физический подуровень.
  • MAC — подуровень управления доступом к среде.

PHY разделяется на следующие части:
  • PMD — обеспечивает передачи и приема отдельных бит на физическом интерфейсе.
  • PMA — обеспечивает сериализацию/десериализацию данных, а так же выделение клока из последовательных данных (на приеме)
  • PCS — обеспечивает скремблирование/дескремблирование, а так же кодирование/декодирование (64b/66b) блоков данных
  • XGXS — XGMII расширитель: используется если PHY и MAC находится на расстоянии друг от друга (опционален).
  • RECONCILIATION — подуровень, транслирующий XGMII в сигналы MAC.

Термины:
  • Medium — среда передачи.
  • MDI — интерфейс, зависимый от среды передачи данных.
  • XGMII — 10G интерфейс, независимый от среды передачи данных. Задача XGMII — обеспечить простое и дешевое соединение между PHY и MAC.
  • XAUI — 10G интерфейс подключения к трансиверу.


Для каждого типа физического уровня может быть своя реализация отдельных PHY-подуровней: применяется различное кодирование, различные частоты передачи (длины волн), но четкое разделение на уровни везде прослеживается. Наличие независимого от среды интерфейса (XGMII) упрощает разработку прикладной логики чипов, т.к. при любом подключении разработчик где-то получит XGMII. О том, что собой представляет XGMII мы поговорим позже.

PMD


Самым близким к среде расположен подуровень PMD: его задачи решают специальные модули, которые хорошо известны сетевым специалистам:
Тип модуля Интерфейс
XENPAK XAUI
X2 XAUI
XFP XFI
SFP+ SFI

В этой таблице уже есть знакомая аббревиатура: XAUI. Оставим рассмотрение XENPAK/X2 на середину статьи, и обратимся к наиболее популярным модулям: XFP и SFP+.

XFI/SFI


XFI и SFI фактически представляют собой один и тот же интерфейс: дифпара, работающая на скоростях от 9.95 до 11.10 гигабод. Набор скоростей обуславливается тем, что несколько стандартов могут использовать этот интерфейс: от 10GBASE-W WAN до 10GBASE-R over G.709. Нас интересует 10GBASE-R LAN с скоростью в 10.3125 гигабод. Одна дифпара используется для приема, другая — для передачи.

XFI/SFI подключается напрямую к ASIC/FPGA





Задачи подуровней PMA и PCS можно решить на чипе, где мы будем выполнять дальнейшую обработку Ethernet пакетов (после того, как выделим их из XGMII). Напомню, что в подуровне PMA необходимо на приеме выделить тактовую частоту и десериализовать входной сигнал. Такую работу могут выполнить специальные аппаратные блоки, которые для других задач нельзя использовать. Эти блоки называются трансиверами. На их подробное описание может уйти целая статья: кому интересно, могут посмотреть посмотреть блок-схему трансиверов в FPGA компании Altera.

После десериализации, данные попадают в подуровень PCS, где производится дескремблирование и декодирование (64b/66b) и отдаются данные в виде XGMII в сторону MAC'a. На передаче выполняются обратные действия.

PCS может быть реализован как с использованием специальных аппаратных блоков (Hard PCS), так и с помощью логики, доступной пользователю (Soft PCS). Разумеется, это утверждение справедливо только для FPGA: в ASIC'ах всё сделанно аппаратно. Производители FPGA закладывают аппаратные PCS блоки для стандартных протоколов, экономя разработчику время и ресурсы FPGA. Наличие таких блоков очень подкупает, т.к. многие стандартные протоколы по опыту работают из коробки, и для большинства из них код предоставляется бесплатно производителем FPGA.

Подключение через внешний чип-трансивер



Трансиверы в FPGA — вещь дорогая, дополнительный десяток трансиверов может значительно поднять цену на чип. Есть более дешевые чипы, с трансиверами, работающими на меньших скоростях (могут сериализовать/десериализовать данные на меньших частотах). Другим высокочастотным интерфейсом, который определен в секции 4 стандарта 802.3, является XAUI: 4 дифференциальные пары с скоростью передачи в 3.125 гигабод (для одной линии передачи).

При использовании XAUI возникает опциональный уровень XGXS, который позволяет отдалить PHY и MAC друг от друга на расстояние. Например, выполнять в разных чипах.

Задачу PMA и PCS в таком подключении могут выполнить специальные 10G трансиверы (Допускаю, что может возникнуть путаница, т.к. чуть ранее «трансиверы» вспыли в FPGA, и теперь тут возникает этот термин. Между прочим, модули XFP/SFP+ тоже называются трансиверами.)

Примеры 10G трансиверов:

Этот трансивер является отдельным чипом, ставится между XFP/SFP+ модулем и «нашим» чипом, который будет обрабатывать Ethernet пакеты. По факту, такой трансивер используя блоки PMA и PCS производит преобразование XFI/SFI в XGMI, а затем XGMII преобразуется в XAUI.

XAUI подается на ASIC/FPGA, где используются трансиверы, аналогичные тем, что были рассмотрены ранее, но на скорости 3.125G. Работа трансивера отличается от того варианта, как это происходит в режиме 10G:
  • Необходимо четыре трансивера (четыре аппаратных блока), т.к. используется 4 дифпары для этого интерфейса.
  • XAUI PCS использует кодирование 8b/10b. В 10G PCS применяется 64b/66b.

XAUI PCS на выходе выдает интерфейс XGMII.

Некоторые PHY-трансиверы могут сразу выдавать на пины интерфейс XGMII и тогда трансиверы в ASIC/FPGA не надо использовать:


У такого метода подключения есть весомые недостатки:
  • Большой расход пинов: в варианте XGMII у одного чипа используется минимум 78 ножек, против 16 в варианте с XAUI.
  • Параллельные интерфейсы могут требовать выравнивания дорожек по плате, что иногда бывает нетривиальным.


Подключение XENPAK/X2



Как я и обещал, мы добрались до этих типов модулей. Несложно увидеть, что их подключение сводится ко второму варианту, только без использования внешнего чипа-трансивера. Модуль возьмет на себя задачи подуровней PMD, PMA и PCS.

XGMII


XGMII определяется в clause 46 стандарта 802.3. Этот интерфейс состоит из независимого приема и передачи. Каждое из направлений имеет 32-битную шину данных (RXD/TXD [31:0]), четыре контрольных сигнала (RXC/TXC [3:0]) и клок, по которому работает направление (RX_CLK/TX_CLK). В стандарте определено, что шины данных и контрольных сигналов анализируются на каждый фронт клока (DDR). По шине данных идёт сам пакет, контрольные сигналы определяют начало помогают «выделять» начало и конец пакета, а так же сообщают об авариях.

Значение RX_CLK/TX_CLK равно 156.25 МГц. Перемножение 156.25 * 10^6 * 32 * 2 дает ровно 10 Gbit/s. Чаще всего от защелкивания по обоим фронтам клока уходят, повышая частоту или ширину данных:
  • Шина 36 бит (32 + 4) на частоте 312.5 МГц.
  • Шина 72 бит (32 * 2 + 4 * 2) на частоте 156.25 МГц.

Чем меньше частота, тем проще обработать эти данные и тем более бюджетные чипы можно использовать. Работу на частотах в ~300 МГц могут себе позволить только топовые (читай, дорогие) FPGA.

Для того, что бы «выцепить» из XGMII пакет применяется специальное MAC-ядро:
  • Пропреитарное. После покупки лицензии на такое IP-ядро, вы (чаще всего) получаете зашифрованные исходники (без возможности модификации) и нет особого ограничения на количество чипов, в которых можно использовать это ядро. Пример.
  • С открытым кодом. Такие ядра очень полезны для новичков, т.к. код открыт, и можно разобраться как работает. Лицензия на использование определяется отдельно. Пример.
  • Самописное.

Разумеется, у этого ядра есть передающая часть, которая пакет «преобразует» в интерфейс XGMII.

Чаще всего такое ядро реализуется на логике, которая доступна для пользовательских задач. Однако, есть производитель FPGA, который MAC-ядра реализовал аппаратно, экономя ресуры пользователю.

MAC-ядро, выделив пакет из XGMII и разместив пакет во внутренней памяти чипа, «передает» контроль над пакетом прикладной логике чипа: парсерам, фильтрам, системам коммутации и пр. К примеру, если чип стоит на сетевой карте и будет принято решение о том, что надо пакет переслать на хост, то он может быть отправлен с помощью PCIe в оперативную память, подключенную к CPU.

Личный опыт


С L1 в большей степени приходится сталкиваться инженерам-схемотехникам, которые разводят платы для приборов. FPGA-программисты с этим работают только в начале подъема железа: когда заработал XGMII и все трансиверы прошли тесты, то мы концентрируемся на том, как сделать обработку трафика. В одном приборе сделано подключение по первому варианту: SFI напрямую заходит в FPGA. В двух других по второму варианту (с использованием трансивера и XAUI). Так же есть девайс у которого есть подключение как напрямую SFI, так и через XAUI, но без трансивера (FPGA подключается к другому чипу).

Для использования внешних трансиверов (да и вообще, большинства специализированных чипов) необходимо подписать NDA. С этим особых проблем чаще всего не возникает. Вместе с NDA выдаются различные доки, например, настройки регистров чипа. Из опыта работы с трансиверами от двух разных производителей замечу, что при подъеме железа в первой партии стабильно возникают какие-то проблемы с настройкой трансивера, которые относительно быстро решались: трансиверы многофункциональные и иногда для настройки на необходимый режим работы надо пошаманить. Иногда бывает, что документация на чипы бывает очень плохая, и приходиться перебирать разные варианты, а техподдержка не отвечает или открыто заявляет, что поддержку по этим чипам она не осуществляет.

Один из плюсов использования чипа-трансивера является то, что вместе с документацией может распространяться набор прошивок-настроек, которые необходимо загружать в трансивер при установке определенного типа модуля. На сколько я понимаю, эти прошивки производят хитрую настройку эквалайзеров, без которой определенный тип модулей будет работать с битовыми ошибками. Один из таких SFP+ модулей (с лимитирующим усилителем) лечился именно таким образом. Если подключаться без трансивера, то такие настройки надо готовить самим для ASIC/FPGA, что может быть нетривиальной задачей.

Наличие интерфейса, который независим от среды передачи, очень упрощает жизнь, т.к. код (application logic: парсеры, генераторы, анализаторы, фильтры, и пр.) очень легко портировать из старых проектов в новые, т.к. не важно, какой тип подключения использовался.

Подключение (и обработка) 40G/100G к ASIC/FPGA похожа на 10G, однако, там есть свои нюансы. Если будет интересно, этому можно будет посвятить отдельную статью, правда, большой она не будет.

Hello, habr!


Возьмем обычный UDP-пакет с строчкой «Hello, habr!» и отправим на прибор, что бы посмотреть, как он будет выглядеть на XGMII.



У меня на столе лежит разобранный девайс, на котором чаще всего происходит тестирование новых фич: используем его для наглядного примера. Для этого подготовим специальную прошивку и подключим отладчик, чтобы увидеть сигналы внутри чипа. Подключение 10G сделано по второму варианту: с помощью внешнего трансивера, который отдает данные по XAUI в сторону FPGA. Этот трансивер двухканальный: может работать с двумя SFP+.



Как выглядит XGMII (и наш пакет) внутри FPGA:



В этом приборе внутри FPGA используется 72 битная шина XGMII, работающая на по положительному фронту частоты 156.25 МГц.

Легенда:
  • xgmii_rxc — набор контрольных сигналов.
  • xgmii_rxd — набор сигналов данных (разбито на байты для удобства).
  • IDLE — сигналы отсутствия передачи пакета.
  • PREAMBLE — преамбула, обозначает начало передачи пакета.
  • L2_HDR — заголовок 2 уровня: Ethernet.
  • L3_HDR — заголовок 3 уровня: IP.
  • L4_HDR — заголовок 4 уровня: UDP.
  • MSG — наше сообщение («Hello, habr!»).
  • PAD — заполнение. Присуствует в пакете, если изначальная длина полезной нагрузки была меньше 60 байт.
  • FCS — проверочная сумма пакета. По ней можно определить, побился пакет во время пересылки, или нет.
  • TERM — сигнал окончания передачи пакета.

Можно заметить, что для получения Ethernet пакета осталось немного: найти его начало и конец (по контрольным символам) и вырезать лишнее: IDLE, PREAMBLE и TERM.

Спасибо за уделенное время и внимание! Если появились вопросы, задавайте без сомнений.

P.S.
Благодарю моих коллег по цеху des333 и paulig за конструктивную критику и советы.
Иван Шевчук @ishevchuk
карма
82,5
рейтинг 8,8
FPGA Design/Verification Engineer
Самое читаемое Разработка

Комментарии (47)

  • +12
    Очень круто. Спасибо. Пишите чаще. На хабре очень не хватает статей такого уровня.
    • +5
      Спасибо за теплый прием.
      Есть несколько идей для следующих статей, но хотелось бы узнать пожелания сообщества)
      • +1
        Вот мне хотелось бы побольше инфы на тему того, как наиболее эффективно разбирать сетевой трафик и парсить протокол на кристалле. Задачи прозаичны — нужны фид-хэндлеры, которые берут известные протоколы (к пр. FIX) и парсят данные с бирж на FPGA.

        Еще сейчас копаю MATLAB HDL Coder как вариант не писать на VHDL, если у вас есть опыт с этой тулой — поделитесь мнением.
        • +5
          High Frequency Trading?

          С MATLAB HDL Coder, увы, не знаком.

          Для парсинга протоколов (IP,UDP, RTP/RTCP, TWAMP и пр.) мы пишем код на SystemVerilog, и генераторами не пользуемся.
          Если надо парсить простые протоколы, то ИМХО, лучше писать парсеры на Verilog/VHDL (хотя последний я не особо люблю, но это дело вкуса ). Выстраивается конвеер, где в зависимости от номера такта выбираются нужные данные из шины данных пакета и защелкиваются в специальные регистры.

          Допускаю, что существуют какие-то генераторы кода, которому скармливается описание протокола и он выдает код, но таких я не видел. Такой генератор может сгенерировать неоптимально, а когда пишешь сам — всё в твоих руках.

          Еще есть вариант c OpenCL: пишешь на C, и выполняешь на fpga. Я сам не игрался с этим, т.к. немного скептически отношусь к возможности применения этой фичи в своей сфере (выжимании 100% при обработки Ethernet пакетов). На ЦОСе OpenCL может реально заруливать. Возможно пасинг с помощью OpenCL на fpga для вашей задачи это будет очень дорогой (по времени обработки) операцией. Altera SDK for OpenCL

          Об этой утилите можно спросить на форуме electronix'a в разделе FPGA: может кто-то игрался с этой утилитой.
          • +1
            Так точно, существуют. binpac, например. Задача моей курсовой достаточно тесно связана с тематикой Вашей статьи, но моя часть работы как раз заключается в реализации высокоэффективных парсеров различных протоколов.
            Кстати, по заявлению разработчиков вышеупомянутого binpac, код, сгенерированный этим компилятором и в надёжности и в производительности превосходит рукописный (http://www.icir.org/vern/papers/binpac.IMC06.pdf). В скором будущем буду исследовать сий момент.
            • 0
              Как я понял, binpac генерирует С++ код. А нам «интересен» парсер, который генерит VHDL/Verilog из такого или похожего описания :)
              • 0
                Да, конкретно для С++ сделать парсер чего-то не так уж и сложно: я в свое время писал XML+XSLT описания которые генерили поддержку протоколов на разных языках. Сейчас кажется универсальным решением стали Google Protocol Buffers. Но на РС нет таких ограничений как на FPGA, поэтому там можно все просто мэпить на структуры и все работает.
          • 0
            Если я правильно понимаю, девайсы от Altera которые поддерживают OpenCL стоят $5k, хотя может я ошибаюсь — сам эту тему еще не начал копать.
        • +2
          HDL Coder — очень удобное средство если у вас dataflow обработка. Т.е. для задач DSP и т.п. С пакетной передачей сложнее, придется руками городить какое-то управление скорее всего. Задачи управления (через Stateflow) на мой взгляд совершенно неудобоваримы, хотя может быть я просто не умею его готовить — старый добрый конечный автомат на VHDL куда как нагляднее.
          Минус HDL Coder'a — невозможно (или очень неудобно) пользоваться готовыми IP-компонентами компании-разработчика FPGA (Altera,Xilinx, ...). Хотя в последнее время у них все больше имеется интеграции с Xilinx.
          • 0
            DSP Builder (или System Generator) вам в помощь!
  • +7
    NDA в данной сфере — это большой тормоз.
    Почему?
    На самом начальном этапе, когда подбираешь элементную базу хочется знать все о компоненте. А не так, что — вы сперва подпишите NDA, а мы вам потом документацию предоставим. Как правило, подбирается компонент от разных конкурирующих производителей. И как правило, выигрывает тот, у которого лучшая документация и есть примеры. Подписывать с каждым производителем NDA, чтобы почитать полный даташит — это глупость.

    Ну и по теме Ethernet Transceivers.
    По личному опыту, Micrel — наше все. Доступная документация, примеры, адекватная цена и доступность на рынке.
    Например, для вот этого проекта irbis.cc для свзяки с ARM Cortex M3 подобрали PHY трансивер KSZ8051RNLI. Никаких тебе NDA, скачал с сайта доки, ознакомился с примерами. Понравилось, заказали и не ошиблись, все завелось с первого раза.
    • +4
      В скоростях 10/100/1000M выбор трансиверов больше, чем в 10G :) У нас используется Marvell на низких скоростях.
      Повторюсь, у нас с подписанием NDA больших проблем не возникало.
      Кстати, при использовании сторонних IP-корок, тоже могут попросить подписать NDA.
    • +9
      Злые языки утверждают, что производителям стыдновато раздавать материалы, не заткнув предварительно возмущенные рты NDA :)
      • +4
        Соглашусь.
        Бывает, errata возникает и внезапно оказывается, что в определенном режиме будут потери данных.
        Документация иногда ожидают лучшего.
        • +2
          По своему небольшому опыту могу сказать, что начинать читать доки надо именно с errata :) В свое время были неприятно удивлены обилием веселья в Ethernet контроллере ENC28J60, хотя там скорость-то смешные 10M. Страшно даже представить, что может твориться на 100G.
          • +2
            Ещё, кстати, стоит смотреть исходники драйверов linux'а — из них можно узнать много нового о существующих проблемах и способах их обхода.
  • +3
    Какие ПЛИСы используете для 10/40/100?

    Я смотрю, у вас там вентиляторы предусмотрены. Без них совсем никак 10GE?
    • +4
      10G: Arria II, Cyclone IV, Stratix V.
      40G/100G: Stratix V.

      Когда FPGA молотит на максимуме: пакеты идут по всем портам, и много логики использовано, то чип греется. Плюс греется трансивер и SFP+, так что без вентиляторов никуда :)
      • 0
        А с Xilinx не работаете принципиально? Интересно просто, чем обусловлен выбор.

        Кстати, как в данный момент обстоят дела со средствами разработки и отладки у Altera? Где в основном отлаживаете, в симуляции или на железе? Ну и с какой попытки удается уложиться в тайминги :)

        Особенно было бы интересно послушать сравнение с ISE, если доводилось использовать.
        • +2
          Просто исторически сложилось, что контора уже 10 лет работает на чипах фирмы Altera. ИМХО, Xillinx больше на военных ориентирована, а Альтера на обычного пользователя.

          Принципиальной разницы я не вижу, однако то, что Altera подписала сотрудничество с Intel и божатся, что:
          а) Stratix 10 (14 нм) будет просто бомбой ( с частотами до 1ГГц )
          б) Xillinx не получит права печатать чипы на фабриках Intel'a

          Говорит о том, что Altera хочет забрать часть рынка себе. 400G скорее всего Альтера покажет первой. Допускаю, что Xillinx делает упор на другие области, например, ЦОС, но в этой теме я не знаток)

          Отлаживаем всё на симуляции, на железе только какие-то финальные тесты, когда релиз тестим. Раз в квартал, бывает, вылезает бага, которую проще на железе посмотреть с помощью SignalTap'a. GUI квартуса почти не пользуемся, т.к. сборка из консоли идет, а прошивается всё не через JTAG.

          Тайминги же больше от приложения зависят, и о того как писать код :) Насчет таймингов скажу так: на 10G их намного делать, чем на 100G :)

          В ISE никогда не работал и сравнений производительности Xillinx vs Altera не делал :)
          • 0
            Понятно, спасибо.

            Ну про фабрики и Altera+Intel=♥ только глухой не слышал. Надеялся, что вам будет что-то сказать определенное, а по всему выходит, что выбор того или иного вендора определяется субъективными и историческими причинами. Кого не спрашивал, у всех примерно одинаково :)
            • +2
              Разница между Altera и сопоставимым семейством Xilinx глазу не заметна. Среди контор, занимающихся прототипированием своих ASIC-ов на ПЛИСах, они используются одинаково часто — так что выбор действительно это определяется другими факторами (например, у вас офис в Калифорнии по соседству).

              Раньше у Альтеры было преимущество поддержки констрэйнов в настоящем формате SDC (том, который жрет Design Complier), так что не надо было переписывать одно и то же два раза. Но теперь Xilinx тоже этот формат поддерживает (правда только для седьмой серии и только в Vivado и еще зачем-то назвали его FDC). Но для тех, кто ASIC-и не делает, это не столь важно.

              Ладно, открою страшную тайну. Альтера дешевле :) Поэтому ее все любят.
          • +1
            Исправлюсь:
            «на 10G их намного проще делать, чем на 100G :)»

            А Вы Xillinx используете?
            • 0
              Нув моем случае да. Но опять же, по историческим причинам, да и опыт у меня не сравнится с вашим.

              Вообще, когда только начинал ковыряться с ПЛИСами, Xilinx показался более навороченным и организация ячеек более логичной, что ли. Почему и начал его изучать. Как сейчас не знаю, но в то время было ощущение, что все новшества появлялись таки у Xilinx-а первым, а Altera догоняли. Сейчас видимо не так.
          • 0
            Где моделируете? В QuestaSim? Или на каких то ускорителях?
            • 0
              Не, ускорители не используем.
              Моделируем весь проект (начиная с XGMII) без трансиверов. Бывает, на отдельные модули свой tb пишем, но бывает редко)
  • +5
    Огонь. Пишите, пожалуйста, еще.
  • +4
    Круто, зачет :) Было бы круто статью о реализации серьезной обработки пакетов на таких скоростях силами FPGA.
  • +1
    Очень круто.Занимался задачей формирования линейно моделированных сигналов с частотой порядка 10 ГГц, простейшие чипы типа усилителя или делителя частоты стоят 30-40 долларов в розницу. Мне трудно даже представить себе чипы способные передавать информацию с тактовой частотой порядка 10 ГГц!
    Кстати, где работаете, если не секрет?
    • +6
      Внутри чипа только отдельный блок (PMA часть трансивера) работает на 10ГГц. Вся прикладная логика (парсеры, фильтры) работают на 156.25 МГц (если шина xgmii 72 бита).

      Цены на FPGA, которые могут принять 10G начинаются от 150-200$ (для каких-то маленьких задач). Для серьезных задач цены от 1k$ начинаются. (По ценам на оф. сайте Альтеры).

      А где работаю см. в профиле ;)
      • +2
        на сайте из профиля в разделе вакансий очень прикольно нажать ctrl+a ))
  • +1
    название девайса — kvazymodo-1 ))
    • +4
      Не, у самого девайса официальное название немного другое) У конкретного этого экземпляра есть кое-какие отличия от «mass product», которые уходят пользователям, его закрепили на дощечке и отдали нам на растерзание. А название на дощечку нарисовали схемотехники)
  • +1
    Классно, буквально как неделю в свободное время читаю про SFP трансиверы. Как у SFP называется интерфейс? Судя по схемам на модули, там тоже две дифпары. В каком стандарте он описывается? В стандарте по SFP описаны только габариты и распиновка. Единственно, нашел доки Maxim на референс дизайн модуля и хост-платы.

    А у SFI какой протокол передачи данных? Он где-то описан?

    И вам приходилось работать с GPON?
    • +2
      Название интерфейса для SFP для дифпары как-то не отложилось. В 1000M Ethernet cкорость у этого интерфейса 1.25 Gbps, т.к. используется кодирование 8b/10b.

      Описание SFI можно найти в спецификации SFF-8431. Как такового «протокола» передачи данных там нет.

      С GPON не работал)

      • 0
        Правильно ли я понимаю, что по дифпарам в 1GE SFP формат кадров будет аналогичен передаваемому по оптике, т.е. 1GE? Есть ли различие в реализации в разных вендоров в формате кадров по дифпарам, или все негласно используют тот же формат, что идёт по оптике?
    • +1
      SFP вполне дельно описан в Википедии, в конце куча ссылок en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver

      Да, там две дифпары. Некоторые вендоры даже выпускали «котороткие» провода (например CISCO CAB-SFP-50CM= около 50см.) для соединения портов коммутаторов Ethernet SFP--SFP напрямую. Там маленький i2c чип для опознавания трансивера и просто «нульмодем» RX на TX.
  • 0
    почему-то в источниках, нагугливаемых по запросу «ethernet преамбула», собственно преамбула представлена как последовательность из 7 или 8 байт «10101010b». в вашем же скриншоте порядок бит в байтах преамбулы перевёрнут (я имею ввиду, перевёрнут, если сравнивать с информацией о преамбуле в нагугленных источниках); особенно наглядно это видно по байту начала кадра. остальные данные в вашем скриншоте перевёрнутыми не выглядят, откуда вывод, что переворот как-раз таки в нагугленном.
    интересно, это общий подход — в описаниях формата кадра ethernet переворачивать биты преамбулы? или же просто ноги растут из самих описаний кадра в IEEE 802.2 и 802.3?
    • +2
      Since octets are transmitted least-significant bit first, the corresponding hexadecimal representation is 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5

      http://en.wikipedia.org/wiki/Ethernet_frame

      Замечу, что 0xFB это специальный XGMII символ, который означает начало преамбулы (если на соответствующей этому байту контрольной линии стоит 1).
  • +1
    Скажите, а как выглядит подключение медным кабелем, т.е. 10GbaseT?
    Правда ли, что при подключении оборудования медным кабелем задержка в передаче пакетов серьезно больше, чем оптикой (трансиверами SFP+) или напрямую (direct attach SFP+ / твинаксиальными кабелями)?
    • 0
      К сожаленью, с 10GBASE-T работать не приходилось. Интересно, насколько он популярен?
      У Marvell'a есть трансивер 88X3240P, который берет 10GBASE-T и отдает XFI или RXAUI. RXAUI это как XAUI, только на частоте в два раза больше ;) так что схема подключения примерно вырисовывается.

      Про задержку ничего, увы сказать не могу: приборы, что бы её измерить есть, а 10GBASE-T нет.
  • 0
    Реально интересно! А не хотите академическую статью по этому материалу написать? Журнал в МГУ — INJOIT injoit.org
    • 0
      Спасибо за предложение, но не могу представить эту статью в виде академической. У меня она скорее научно-популярная с опусканием деталей и обхождением острых углов. Я тут выступаю как практик, который знает какие кубики в каком порядке собрать для того, что бы получить 10G, а не «академик», который сделал эксперименты/расчеты и предлагает решение какой-то проблемы.
  • 0
    Ну, блин, я думал сейчас будет ссылочка на код самописного MAC-ядра и блочка для настройки «физической» микрухи! А всё что вы написали, в Инете найти можно.
    • 0
      На самописное ядро я дал ссылку в статье: opencores.org/project,xge_mac,overview (Из-за запятых ссылка может не выделиться цветом полностью).

      Во-вторых, для тех трансиверов с которыми я работаю, у конторы, в которой я работаю, подписан NDA и никакую их настройку, разумеется, я не могу выкладывать.
      • 0
        Если точнее говорить, это ядро не самописное, а открытое.
        Своими исходники MAC-ядра я не планирую делиться, т.к. за это на работе могут наругать)
      • 0
        Сорри, не заметил ссылочку.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.