Comments 47
Очень круто. Спасибо. Пишите чаще. На хабре очень не хватает статей такого уровня.
Спасибо за теплый прием.
Есть несколько идей для следующих статей, но хотелось бы узнать пожелания сообщества)
Есть несколько идей для следующих статей, но хотелось бы узнать пожелания сообщества)
Вот мне хотелось бы побольше инфы на тему того, как наиболее эффективно разбирать сетевой трафик и парсить протокол на кристалле. Задачи прозаичны — нужны фид-хэндлеры, которые берут известные протоколы (к пр. FIX) и парсят данные с бирж на FPGA.
Еще сейчас копаю MATLAB HDL Coder как вариант не писать на VHDL, если у вас есть опыт с этой тулой — поделитесь мнением.
Еще сейчас копаю MATLAB HDL Coder как вариант не писать на VHDL, если у вас есть опыт с этой тулой — поделитесь мнением.
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: может кто-то игрался с этой утилитой.
С 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: может кто-то игрался с этой утилитой.
Так точно, существуют. binpac, например. Задача моей курсовой достаточно тесно связана с тематикой Вашей статьи, но моя часть работы как раз заключается в реализации высокоэффективных парсеров различных протоколов.
Кстати, по заявлению разработчиков вышеупомянутого binpac, код, сгенерированный этим компилятором и в надёжности и в производительности превосходит рукописный (http://www.icir.org/vern/papers/binpac.IMC06.pdf). В скором будущем буду исследовать сий момент.
Кстати, по заявлению разработчиков вышеупомянутого binpac, код, сгенерированный этим компилятором и в надёжности и в производительности превосходит рукописный (http://www.icir.org/vern/papers/binpac.IMC06.pdf). В скором будущем буду исследовать сий момент.
Как я понял, binpac генерирует С++ код. А нам «интересен» парсер, который генерит VHDL/Verilog из такого или похожего описания :)
Да, конкретно для С++ сделать парсер чего-то не так уж и сложно: я в свое время писал XML+XSLT описания которые генерили поддержку протоколов на разных языках. Сейчас кажется универсальным решением стали Google Protocol Buffers. Но на РС нет таких ограничений как на FPGA, поэтому там можно все просто мэпить на структуры и все работает.
Если я правильно понимаю, девайсы от Altera которые поддерживают OpenCL стоят $5k, хотя может я ошибаюсь — сам эту тему еще не начал копать.
HDL Coder — очень удобное средство если у вас dataflow обработка. Т.е. для задач DSP и т.п. С пакетной передачей сложнее, придется руками городить какое-то управление скорее всего. Задачи управления (через Stateflow) на мой взгляд совершенно неудобоваримы, хотя может быть я просто не умею его готовить — старый добрый конечный автомат на VHDL куда как нагляднее.
Минус HDL Coder'a — невозможно (или очень неудобно) пользоваться готовыми IP-компонентами компании-разработчика FPGA (Altera,Xilinx, ...). Хотя в последнее время у них все больше имеется интеграции с Xilinx.
Минус HDL Coder'a — невозможно (или очень неудобно) пользоваться готовыми IP-компонентами компании-разработчика FPGA (Altera,Xilinx, ...). Хотя в последнее время у них все больше имеется интеграции с Xilinx.
NDA в данной сфере — это большой тормоз.
Почему?
На самом начальном этапе, когда подбираешь элементную базу хочется знать все о компоненте. А не так, что — вы сперва подпишите NDA, а мы вам потом документацию предоставим. Как правило, подбирается компонент от разных конкурирующих производителей. И как правило, выигрывает тот, у которого лучшая документация и есть примеры. Подписывать с каждым производителем NDA, чтобы почитать полный даташит — это глупость.
Ну и по теме Ethernet Transceivers.
По личному опыту, Micrel — наше все. Доступная документация, примеры, адекватная цена и доступность на рынке.
Например, для вот этого проекта irbis.cc для свзяки с ARM Cortex M3 подобрали PHY трансивер KSZ8051RNLI. Никаких тебе NDA, скачал с сайта доки, ознакомился с примерами. Понравилось, заказали и не ошиблись, все завелось с первого раза.
Почему?
На самом начальном этапе, когда подбираешь элементную базу хочется знать все о компоненте. А не так, что — вы сперва подпишите NDA, а мы вам потом документацию предоставим. Как правило, подбирается компонент от разных конкурирующих производителей. И как правило, выигрывает тот, у которого лучшая документация и есть примеры. Подписывать с каждым производителем NDA, чтобы почитать полный даташит — это глупость.
Ну и по теме Ethernet Transceivers.
По личному опыту, Micrel — наше все. Доступная документация, примеры, адекватная цена и доступность на рынке.
Например, для вот этого проекта irbis.cc для свзяки с ARM Cortex M3 подобрали PHY трансивер KSZ8051RNLI. Никаких тебе NDA, скачал с сайта доки, ознакомился с примерами. Понравилось, заказали и не ошиблись, все завелось с первого раза.
В скоростях 10/100/1000M выбор трансиверов больше, чем в 10G :) У нас используется Marvell на низких скоростях.
Повторюсь, у нас с подписанием NDA больших проблем не возникало.
Кстати, при использовании сторонних IP-корок, тоже могут попросить подписать NDA.
Повторюсь, у нас с подписанием NDA больших проблем не возникало.
Кстати, при использовании сторонних IP-корок, тоже могут попросить подписать NDA.
Злые языки утверждают, что производителям стыдновато раздавать материалы, не заткнув предварительно возмущенные рты NDA :)
Соглашусь.
Бывает, errata возникает и внезапно оказывается, что в определенном режиме будут потери данных.
Документация иногда ожидают лучшего.
Бывает, errata возникает и внезапно оказывается, что в определенном режиме будут потери данных.
Документация иногда ожидают лучшего.
Какие ПЛИСы используете для 10/40/100?
Я смотрю, у вас там вентиляторы предусмотрены. Без них совсем никак 10GE?
Я смотрю, у вас там вентиляторы предусмотрены. Без них совсем никак 10GE?
10G: Arria II, Cyclone IV, Stratix V.
40G/100G: Stratix V.
Когда FPGA молотит на максимуме: пакеты идут по всем портам, и много логики использовано, то чип греется. Плюс греется трансивер и SFP+, так что без вентиляторов никуда :)
40G/100G: Stratix V.
Когда FPGA молотит на максимуме: пакеты идут по всем портам, и много логики использовано, то чип греется. Плюс греется трансивер и SFP+, так что без вентиляторов никуда :)
А с Xilinx не работаете принципиально? Интересно просто, чем обусловлен выбор.
Кстати, как в данный момент обстоят дела со средствами разработки и отладки у Altera? Где в основном отлаживаете, в симуляции или на железе? Ну и с какой попытки удается уложиться в тайминги :)
Особенно было бы интересно послушать сравнение с ISE, если доводилось использовать.
Кстати, как в данный момент обстоят дела со средствами разработки и отладки у Altera? Где в основном отлаживаете, в симуляции или на железе? Ну и с какой попытки удается уложиться в тайминги :)
Особенно было бы интересно послушать сравнение с ISE, если доводилось использовать.
Просто исторически сложилось, что контора уже 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 не делал :)
Принципиальной разницы я не вижу, однако то, что Altera подписала сотрудничество с Intel и божатся, что:
а) Stratix 10 (14 нм) будет просто бомбой ( с частотами до 1ГГц )
б) Xillinx не получит права печатать чипы на фабриках Intel'a
Говорит о том, что Altera хочет забрать часть рынка себе. 400G скорее всего Альтера покажет первой. Допускаю, что Xillinx делает упор на другие области, например, ЦОС, но в этой теме я не знаток)
Отлаживаем всё на симуляции, на железе только какие-то финальные тесты, когда релиз тестим. Раз в квартал, бывает, вылезает бага, которую проще на железе посмотреть с помощью SignalTap'a. GUI квартуса почти не пользуемся, т.к. сборка из консоли идет, а прошивается всё не через JTAG.
Тайминги же больше от приложения зависят, и о того как писать код :) Насчет таймингов скажу так: на 10G их намного делать, чем на 100G :)
В ISE никогда не работал и сравнений производительности Xillinx vs Altera не делал :)
Понятно, спасибо.
Ну про фабрики и Altera+Intel=♥ только глухой не слышал. Надеялся, что вам будет что-то сказать определенное, а по всему выходит, что выбор того или иного вендора определяется субъективными и историческими причинами. Кого не спрашивал, у всех примерно одинаково :)
Ну про фабрики и Altera+Intel=♥ только глухой не слышал. Надеялся, что вам будет что-то сказать определенное, а по всему выходит, что выбор того или иного вендора определяется субъективными и историческими причинами. Кого не спрашивал, у всех примерно одинаково :)
Разница между Altera и сопоставимым семейством Xilinx глазу не заметна. Среди контор, занимающихся прототипированием своих ASIC-ов на ПЛИСах, они используются одинаково часто — так что выбор действительно это определяется другими факторами (например, у вас офис в Калифорнии по соседству).
Раньше у Альтеры было преимущество поддержки констрэйнов в настоящем формате SDC (том, который жрет Design Complier), так что не надо было переписывать одно и то же два раза. Но теперь Xilinx тоже этот формат поддерживает (правда только для седьмой серии и только в Vivado и еще зачем-то назвали его FDC). Но для тех, кто ASIC-и не делает, это не столь важно.
Ладно, открою страшную тайну. Альтера дешевле :) Поэтому ее все любят.
Раньше у Альтеры было преимущество поддержки констрэйнов в настоящем формате SDC (том, который жрет Design Complier), так что не надо было переписывать одно и то же два раза. Но теперь Xilinx тоже этот формат поддерживает (правда только для седьмой серии и только в Vivado и еще зачем-то назвали его FDC). Но для тех, кто ASIC-и не делает, это не столь важно.
Ладно, открою страшную тайну. Альтера дешевле :) Поэтому ее все любят.
Исправлюсь:
«на 10G их намного проще делать, чем на 100G :)»
А Вы Xillinx используете?
«на 10G их намного проще делать, чем на 100G :)»
А Вы Xillinx используете?
Нув моем случае да. Но опять же, по историческим причинам, да и опыт у меня не сравнится с вашим.
Вообще, когда только начинал ковыряться с ПЛИСами, Xilinx показался более навороченным и организация ячеек более логичной, что ли. Почему и начал его изучать. Как сейчас не знаю, но в то время было ощущение, что все новшества появлялись таки у Xilinx-а первым, а Altera догоняли. Сейчас видимо не так.
Вообще, когда только начинал ковыряться с ПЛИСами, Xilinx показался более навороченным и организация ячеек более логичной, что ли. Почему и начал его изучать. Как сейчас не знаю, но в то время было ощущение, что все новшества появлялись таки у Xilinx-а первым, а Altera догоняли. Сейчас видимо не так.
Где моделируете? В QuestaSim? Или на каких то ускорителях?
Огонь. Пишите, пожалуйста, еще.
Круто, зачет :) Было бы круто статью о реализации серьезной обработки пакетов на таких скоростях силами FPGA.
Очень круто.Занимался задачей формирования линейно моделированных сигналов с частотой порядка 10 ГГц, простейшие чипы типа усилителя или делителя частоты стоят 30-40 долларов в розницу. Мне трудно даже представить себе чипы способные передавать информацию с тактовой частотой порядка 10 ГГц!
Кстати, где работаете, если не секрет?
Кстати, где работаете, если не секрет?
Внутри чипа только отдельный блок (PMA часть трансивера) работает на 10ГГц. Вся прикладная логика (парсеры, фильтры) работают на 156.25 МГц (если шина xgmii 72 бита).
Цены на FPGA, которые могут принять 10G начинаются от 150-200$ (для каких-то маленьких задач). Для серьезных задач цены от 1k$ начинаются. (По ценам на оф. сайте Альтеры).
А где работаю см. в профиле ;)
Цены на FPGA, которые могут принять 10G начинаются от 150-200$ (для каких-то маленьких задач). Для серьезных задач цены от 1k$ начинаются. (По ценам на оф. сайте Альтеры).
А где работаю см. в профиле ;)
UFO just landed and posted this here
Классно, буквально как неделю в свободное время читаю про SFP трансиверы. Как у SFP называется интерфейс? Судя по схемам на модули, там тоже две дифпары. В каком стандарте он описывается? В стандарте по SFP описаны только габариты и распиновка. Единственно, нашел доки Maxim на референс дизайн модуля и хост-платы.
А у SFI какой протокол передачи данных? Он где-то описан?
И вам приходилось работать с GPON?
А у SFI какой протокол передачи данных? Он где-то описан?
И вам приходилось работать с GPON?
Название интерфейса для SFP для дифпары как-то не отложилось. В 1000M Ethernet cкорость у этого интерфейса 1.25 Gbps, т.к. используется кодирование 8b/10b.
Описание SFI можно найти в спецификации SFF-8431. Как такового «протокола» передачи данных там нет.
С GPON не работал)
Описание SFI можно найти в спецификации SFF-8431. Как такового «протокола» передачи данных там нет.
С GPON не работал)
SFP вполне дельно описан в Википедии, в конце куча ссылок en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver
Да, там две дифпары. Некоторые вендоры даже выпускали «котороткие» провода (например CISCO CAB-SFP-50CM= около 50см.) для соединения портов коммутаторов Ethernet SFP--SFP напрямую. Там маленький i2c чип для опознавания трансивера и просто «нульмодем» RX на TX.
Да, там две дифпары. Некоторые вендоры даже выпускали «котороткие» провода (например CISCO CAB-SFP-50CM= около 50см.) для соединения портов коммутаторов Ethernet SFP--SFP напрямую. Там маленький i2c чип для опознавания трансивера и просто «нульмодем» RX на TX.
почему-то в источниках, нагугливаемых по запросу «ethernet преамбула», собственно преамбула представлена как последовательность из 7 или 8 байт «10101010b». в вашем же скриншоте порядок бит в байтах преамбулы перевёрнут (я имею ввиду, перевёрнут, если сравнивать с информацией о преамбуле в нагугленных источниках); особенно наглядно это видно по байту начала кадра. остальные данные в вашем скриншоте перевёрнутыми не выглядят, откуда вывод, что переворот как-раз таки в нагугленном.
интересно, это общий подход — в описаниях формата кадра ethernet переворачивать биты преамбулы? или же просто ноги растут из самих описаний кадра в IEEE 802.2 и 802.3?
интересно, это общий подход — в описаниях формата кадра ethernet переворачивать биты преамбулы? или же просто ноги растут из самих описаний кадра в IEEE 802.2 и 802.3?
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).
Скажите, а как выглядит подключение медным кабелем, т.е. 10GbaseT?
Правда ли, что при подключении оборудования медным кабелем задержка в передаче пакетов серьезно больше, чем оптикой (трансиверами SFP+) или напрямую (direct attach SFP+ / твинаксиальными кабелями)?
Правда ли, что при подключении оборудования медным кабелем задержка в передаче пакетов серьезно больше, чем оптикой (трансиверами SFP+) или напрямую (direct attach SFP+ / твинаксиальными кабелями)?
К сожаленью, с 10GBASE-T работать не приходилось. Интересно, насколько он популярен?
У Marvell'a есть трансивер 88X3240P, который берет 10GBASE-T и отдает XFI или RXAUI. RXAUI это как XAUI, только на частоте в два раза больше ;) так что схема подключения примерно вырисовывается.
Про задержку ничего, увы сказать не могу: приборы, что бы её измерить есть, а 10GBASE-T нет.
У Marvell'a есть трансивер 88X3240P, который берет 10GBASE-T и отдает XFI или RXAUI. RXAUI это как XAUI, только на частоте в два раза больше ;) так что схема подключения примерно вырисовывается.
Про задержку ничего, увы сказать не могу: приборы, что бы её измерить есть, а 10GBASE-T нет.
Реально интересно! А не хотите академическую статью по этому материалу написать? Журнал в МГУ — INJOIT injoit.org
Спасибо за предложение, но не могу представить эту статью в виде академической. У меня она скорее научно-популярная с опусканием деталей и обхождением острых углов. Я тут выступаю как практик, который знает какие кубики в каком порядке собрать для того, что бы получить 10G, а не «академик», который сделал эксперименты/расчеты и предлагает решение какой-то проблемы.
Ну, блин, я думал сейчас будет ссылочка на код самописного MAC-ядра и блочка для настройки «физической» микрухи! А всё что вы написали, в Инете найти можно.
На самописное ядро я дал ссылку в статье: opencores.org/project,xge_mac,overview (Из-за запятых ссылка может не выделиться цветом полностью).
Во-вторых, для тех трансиверов с которыми я работаю, у конторы, в которой я работаю, подписан NDA и никакую их настройку, разумеется, я не могу выкладывать.
Во-вторых, для тех трансиверов с которыми я работаю, у конторы, в которой я работаю, подписан NDA и никакую их настройку, разумеется, я не могу выкладывать.
Sign up to leave a comment.
Взгляд на 10G Ethernet со стороны FPGA разработчика