Несколько слов об отладке 1Gb Ethernet-проектов на ПЛИС. Часть II.

В продолжение темы собственно об отладке 1Гбит-Ethernet-девайсов. Данный пост будет носить немного философский характер, т.е. много букв, мало картинок и совсем не будет кода или схем. Но в данном посте я поделюсь с читателями теми «граблями», на которые я реально налетал я и мои подчинённые/коллеги при разработке Ethernet-устройств (а этим делом я занимаюсь весьма немалое кол-во времени), дабы дать возможности избежать оных тем, кто идёт за мной.

Итак , начнём с такого интересного момента, как пауза между пакетами.

Дело в том, что если вы хотите выжать из сетки всё на что она только способна, то вас, понятно дело, будет интересовать, а какова же минимально допустимая пауза между пакетами. Вообще говоря, стандарт не запрещает (ну, по-крайней мере мы не нашли никакой инфы) слать пакеты хоть подряд друг за другом с однобайтовой паузой (что бы определить, где последний байт КС расположен, передача-то всё-таки пакетная :)). Т.е., вроде «шмаркнул» TX_EN разок — и начинай следующий пакет. Но реально не один из известных нам СП или сетевых карт в компах не могут принимать стабильно пакеты, если расстояние между ними меньше 5 «холостых» тактов (байтов). Причём, если предстоит стыковка с незнакомым сетевым оборудованием, лучше увеличить её до 7-8, тогда 99,9% пройдёт через почти везде.
У D-Link'овских СП, например, слишком короткая пауза отлично видна по лампочкам: они начинают моргать, модулируя частоту по закону, напоминающему силу порывистового ветра холодным зимним вечером: то как дунет, то затихнет :).

Кстати, для работ с сетью я крайне рекомендую некий индикатор, тестер что ли. В качестве которого рекомендую использовать, как их только не называют любители русского языка, «свитчи», «хабы», «роутеры» (хотя это, конечно, разные классы устройств, но с точки зрения отладки сетевого устройства на плисине, разницы нет). А мы далее по тексту их будем называть так, как предписывает ГОСТ: сетевые переключатели (СП).

Я очень рекомендую использовать СП, даже если конечное назначение разрабатываемого устройства работа в режиме «точка-точка». Причём опять же не важно кто является «концевиком» — ЭВМ или другое аналогичное устройство. Лично мне понравилось работать вот с такой коробочкой (D-Link DSG-1005D, автор никак не связан с компаний D-Link, просто по положительному опыту)



В частности, очень информативными являются лампочки на передней панели СП. Если у вас идёт стабильный поток с постоянной достаточно высокой скоростью и скважностью, то лампочки, соответствующие входной и выходной линиям должны моргать стабильно и абсолютно синхронно друг с другом. Малейшее «перемыргивание» лампочек синхронно или друг относительно друга – признак проблемы. Кстати, при определённом навыке, по морганию лампочек можно определить потерю уже где-то 5-6% пакетов.

Если же моргает только входная лампочка – это 90% ошибка в контрольной сумме (КС) пакета (CRC32). С этой самой темой мы намучались в своё время по полной программе. Напомню вам структуру Ethernet II — пакета по свистнутой с «Википедии» картинке:



С одной стороны, CRC, или, как их обозначали в советской и российской литературе, ЦПК – циклический проверочный код, штука весьма простая. Это – остаток от деления двух двоичных чисел друг на друга поразрядно по модулю 2 (т.е. аналог суммирования – это «исключающее ИЛИ» (XOR), а аналог обычного умножения – «И» (AND)). Или, другими словами, это обычное деление двоичных чисел, но без переноса в старший разряд.

Часто двоичные числа типа представляются полиномами и начинается наукообразное обвешивание всего этого хоз-ва терминами типа «поля Галуа», «неприводимые полиномы» и т.д. и т.п. На самом деле, поля Галуа и связанные с ним несколько теорем – тоже весьма элементарные вещи, но для понимания работы CRC, в принципе, нафиг это всё не нужно. Нужно просто понять, что CRC – это, по-сути, обобщение бита чётности на случай нескольких проверочных бит. Вот и всё!

Так вот понять просто, а реализовать – не очень. Дело в том, что для собственно вычисления КС существует куча способов от классического деления в столбик на сдвиговом регистре (тоже есть несколько вариантов), до «лобовых» способов. Где-то даже видел изящный способ деления вообще в одну строчку на Verilog'е. Мы, например, не заморачивались и просто воспользовались web-инструментом отсюда www.easics.com, который генерит Eth II – вычислитель КС с побайтной подачей.

Но дальше начинаются «пляски с бубном». Разработчикам Ethernet'а явно шило в одном месте мешало: при расчёте КС биты каждого байта должны идти в обратном порядке, после вычисления КС, она должна быть проинвертирована, а байты КС должны идти также в обратном порядке (LSBy first). Кроме того, если вы используете любую итерационную форму деления (сдвиговый регистр или побайтовую подачу), то исходное значение регистра промежуточного результат должно быть = все единицы! Наверное, применив знания в области работы с теми самыми несчастными двоичными полиномами это всё как-то можно упростить. Но мы же не диссер сюда пришли писать, мы — простые инженеры :)

А дальше начинаются уже подводные камни железячной реализации. Если пакеты формируются на лету (real-time) на максимальной скорости (т.е., почти некогда «дух перевести» (см. выше абзац про паузу между пакетами)), то вы можете посмотреть в первой части поста, какие жёсткие требования налагаются на точность синхронизации. И, в большинстве случаев, возникает три проблемы: разъезжается синхра при подачи бит(байт) либо на вычислитель КС, либо с КС, либо банально «съезжает» TX_EN (вот ещё, кстати, почему я в первой части рекомендовал его протаскивать через ALTDDIO).

Причём, самое паршивое, что при включённом внутреннем ФАПЧ PHY (см. первую часть) вы никак физически это сползание увидеть не сможете. Поэтому, «Таймквесты» и временные ограничения («Тайм констрейнты») – вам в помощь.

В 10% бывают и ошибки, не связанные с КС пакета. Обычно (у некоторых моделей СП это задаётся в настройках), если только СП не является «маршрутизатором», то им до лампочки КС IP. Но вот ошибки в установке длины пакета они почему-то простить не могут.

Некоторые реагируют только на нереальные значения длин (обычно превышающие длину Jumbo-пакетов), а некоторые капризные модели обижаются уже, если просто заявленная длина не соответствует истинной длине пакета. В общем, тут всё либо опытным путём, либо внимательным чтением доки к вашему СП. Ну и, конечно, не забудьте, что оконечное устройство должно иметь IP и MAC-адреса, которые установлены вами в проекте.

И хочу предостеречь от весьма распространённой ошибки. Часто, когда проект не работает через СП, разрабатываемое устройство напрямую соединяют с ЭВМ и оказывается, что всё работает. Разработчик радостно объявляет, что «всё работает» и во всём виноват «кривой свитч» и на этом радостно успокаивается.

НЕ НАДО ТАК ДЕЛАТЬ! Как будет описано далее, сетевые карты ЭВМ имеют очень много особенностей. И часто, да, бывает, что после устранения СП данные начинают поступать к потребителю. Но после этого типично случается следующий конфуз. Проект проверен (даже на паре ЭВМ), СП «выбракован», разработчик едет с проектом в «поле» на другой конец страны (земли), куда одни билеты на самолёт только стоят как его месячная зп. Прилетает на место, включается – и … обломись.

А дело в том, что на месте стоит другая ЭВМ (или походный ноут, привезённый с собой, но на котором, есс-но проект проверять не стали). Что бы так не было, запомните: если пакеты не проходят (или теряются) даже на максимальной скорости при прохождении СП, однозначно ищите ошибку в проекте!!! Только после 100% прохождения через СП, можно считать, что проект на 99% исправен :)

Кроме того, если у вас на плате есть две «азернет-соски», или есть другая плата с плисиной и азеренетом можно за пять минут сварганить схему, позволяющую подсматривать пакеты. Если кто не догадался, делается совершенно элементарно: на ноги, соединённые с приёмной частью PHY вешается СигналТап (ЧипСкоуп). На запускающий триггер вешается вход строба (типа RX_DV) и – вуаля: вот он ваш пакет. Конечно, лучше не поленится, потратить несколько дней и сварганить что-либо более удобное.

Ну или хотя бы (как это сделал в своё время автор поста в Матлабе) слепить программку, которая прямо, подсоединившись к СигналТапу из Матлаба рассчитает и сверит КС.

Вообще говоря, перед каждым пакетом должно передаваться вступление («преамбула») из 7 байт 55H и одного D5H. Для чего нужна эта последовательность, данные весьма разнятся: кто-то утверждает, что это – наследие тех времён, когда 10Мб-сеть работала на общий кабель, и нужно было разрешать конфликты доступа к среде, которые ленивые переводчики обозвали «коллизиями». Вторые утверждают, что она нужна для символьной синхронизации.

Похоже на то, что более близки к истине первые, ибо многочисленные эксперименты (в основном из-за ошибок в коде :) показали, что СП и сетевые карты спокойно поедают пакеты, у которых вместо 55H стоит любая ахинея или вообще TX_EN взводится прямо на байте D5H. Главное что бы был байт D5H. Походу, большинство современных сетевых устройств просто считают, что пакет начинается со следующего байта за первым встреченным в потоке байтом D5H.

Кстати сказать, если приёмным устройством в вашей системе является устройство вашего же розлива, то можно вообще забить на все заголовки, включая Eth II, и гнать свой формат. Кстати, такие пакеты можно принять и на ЭВМ, но придётся писать программу, которая напрямую цепляется к драйверу-перехватчику типа pcap, также как это делает популярная подсматривалка Wireshark.

Можно, кстати, забить даже на пакетность передачи данных и перейти в синхронный режим без пауз (PHY это фиолетово). Правда тогда, этот поток уже никакая ЭВМ прочитать не сможет – только промеж вашими девайсами.

Очень часто бывает так, что пакеты видятся тем же Варешарком, но до конечного приложения они не доходят. Например, автор поста чаще всего загоняет пакеты прямо в Матлаб для дальнейшей обработки.

В Матлабе достаточно создать объект udp и дальше, если лень писать код, открыть его свойства, задать приёмный порт, сказать fopen(u) и следить за свойством BytesAvailable. Если это свойство упорно показывает нуль, то пакеты действительно до вас не доходят. В этом случае не надо кидаться рубить антивирусники и курочить настройки безопасности системы. Как показывает практика, даже самые пароноидальные пожарные стенки и антивирусы типа Касперского, никак не реагируют на поток udp-пакетов с местными адресами, даже если ваше устройство генерит их со скоростью «тапку в пол» (хотя на DDOS-атаку очень смахивает и девайс с таким потоком, включённый в офисную сеть запросто её может положить :). Поэтому, запомните главное: если пакеты не доходят до приложений, однозначно ищите ошибку в своём микропрограммном (firmware) коде!



Причём мест, где можно накосячить довольно много. Первое, проверяйте КС. Про КС всего пакета уже всё сказано выше. Что касается КС UDP, то нулевое значение (+0 в обратном коде, см. правленую мной статью на Википедии: ru.wikipedia.org/wiki/UDP, если его ещё не заблокировали :( ) означает, что её не вычисляли. По стандарту, все сетевые уст-ва MUST такое понимать. Но не все китайские разработчики, похоже, стандарты читают :).

Кстати, 100% проверено пакеты с нулевой КС UDP не проходят через Интернет. В местных сетях в 99% случаев такие пакеты свободно гуляют и это очень хорошо, т.к. КС UDP считать «на лету» ну очень не удобно технически (стоит она в заголовке, но считается по всем данным UDP-пакета, кто такой идиотизм придумал?!).

Второе – это КС IP-заголовка. Я здесь буду говорить только про версию 4, ибо версия 6 в местной сети нужна только для гарантированной стрельбы Jumbo-пакетами, но большинство IPv4-устройств уже давно Jumbo-пакеты тоже поддерживают, так что IPv6 в местных сетях, по-сути, нафиг никому не нужен.

В отличие от маразма с КС UDP, КС IP считается только по данным из IP-заголовка. Формально, эту КС тоже можно не считать, но реально даже Wireshark ругается на IPv4-заголовок с нулями в позиции с КС. Тем более что считается она элементарно, хотя есть простой способ её самому не считать, а просто посмотреть правильную КС в том же Wireshark’е и пересобрать с ней проект. А вот пакет с битой КС IP однозначно до верхнего потребителя не доберётся. Ну и не забудьте проверить установку флагов. Проще всего байты с 5ого по 8ой положить нулевыми.

Кстати, по поводу использования КС. У большинства сетевых карт имеются настройки «разгрузки КС». Суть в том, что пользователю предлагается выбрать, кто будет считать КС: само железо сетевой карты или программно ядро ОС. В первом варианте, при неправильной КС, пакет будет безжалостно прибит и не доберётся даже до подсматривалок. А если КС верные, то в первом варианте, некоторые сетевые карты делают то, о чём их никто не просит: зануляют КС. В результате уже подсматривалки начинают ругаться на неверную КС, вы в панике хватаетесь за голову, в то время как всё правильно.



Третье – это тщательная проверка IP-адресов и макушников. У автора поста был постыдный эпизод, когда было спущено два дня известному домашнему животному под хвост, только из-за того, что автор ошибся в одной цифре номера подсети и в упор этого не видел. Не забывайте также, что адреса передатчика и приёмника лучше всего выбирать из одной подсети. Особенно, если ваш девайс не отвечает на ARP-запросы (или вообще работает в режиме монолога и чихать на всех хотел :).

Кстати, по-крайней мере, в Win XP и Win 7 различных версий в большинстве случаев есть ещё одна подстава: если макушник не соответствует макушнику ЭВМ, то опять ни черта вы не получите. Win 8, вроде, поспокойней к этому относится (Win 10 – не знаю и знать не хочу :) ). Иногда это ограничение удаётся объехать на «кривой кобыле» в виде подстановки широковещательного MAC-адреса. Видимо это зависит от каких-то настроек ОС, но автор не специалист в вопросах администрирования ОСей.

Кстати, ещё один вариант «объезда» этой проблемы – использование т.н. «мультикаст» адреса, или, по-русски, «распределённого» адреса. Их плюс в том, что со стороны передатчика ничего делать не надо, кроме прописывания выбранного адреса и макушника (для распределённого адреса IP и MAC строго связаны (http://juniper.ucoz.ru/index/peresylka_multicast/0-73).

Их минус в том, что на приёмной стороне на них нужно «подписываться», что бы начать получать эти пакеты. Процедура не сложная, но, например, из Матлаба это сделать достаточно сложно.

А вообще рекомендую использовать утилитку netstat, обычно имеющуюся в наборе стандартных программ ОС и запускающуюся из консоли. Она вам многое подскажет.

Ну и последнее – это иногда встречающиеся и весьма неприятные прибабахи с КС всего пакета (CRC32). Дело в том, что некоторые производители сетевых карт умудряются разрешать пропускать через себя пакеты с битой CRC32 и, причём, (есс-но!) эта фича оказывается по умолчанию включенной. Причём, самая подстава состоит в том, что ещё и встречаются два варианта поведения таких карт. Первый – это когда карта переключается в прозрачный режим и пропускает в систему весь пакет даже с CRC32-хвостом.

Видимо разработчики того же Wireshark’а с подобной ситуацией сталкивались, т.к. в этом случае, Wireshark понимает, что последние 4 байта – это КС и предупреждает вас о том, что она неверная. Гораздо хуже – вторая ситуация: когда карта молча отбрасывает последние 4 байта. Именно поэтому, в том числе, следует всегда использовать СП, автор никогда не встречался с ситуацией, что бы пакеты с битой CRC32 проходили СП.

Ну а дальше гигабитный поток с близким к 100% заполнения канала ломится на вашу ЭВМ и вы пытаетесь его без пропусков обработать или хотя бы записать на «винч». И тут начинается вторая часть Марлезонского балета, но это уже совсем другая история …

(с) 2015, Kluwert, (по-прежнему) имею право :)