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

Итак , начнём с такого интересного момента, как пауза между пакетами.
Дело в том, что если вы хотите выжать из сетки всё на что она только способна, то вас, понятно дело, будет интересовать, а какова же минимально допустимая пауза между пакетами. Вообще говоря, стандарт не запрещает (ну, по-крайней мере мы не нашли никакой инфы) слать пакеты хоть подряд друг за другом с однобайтовой паузой (что бы определить, где последний байт КС расположен, передача-то всё-таки пакетная :)). Т.е., вроде «шмаркнул» 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, (по-прежнему) имею право :)
- +10
- 02 сентября 2015, 15:23
- Kluwert
- 2
Файлы в топике:
Matlab_udp.jpg, Upload.jpg
Вопрос к коду в первой части.Смотрю сюда:
И никак не пойму зачем повторение одного и тогоже кода?
if (SPEED == `FAST)
if ((clk_bytes >= 9'h0) && (clk_bytes < 9'd72))
TX_EN <= 1'b1; // Transmission is enabled
else
TX_EN <= 1'b0;
else
if ((clk_bytes >= 9'h0) && (clk_bytes < 9'd72))
TX_EN <= 1'b1; // Transmission is enabled
else
TX_EN <= 1'b0;
И никак не пойму зачем повторение одного и тогоже кода?
Еще вопросик ALTDDIO вроде как нужен для работы с DDR памятью. Но в ПЛИСах обычно есть 1,2(и более) выделенных блока пинов специально для DDR. Собственно вопрос модуль ALTDDIO можно прилепить к пину из вышеуказанных множеств или к любому пину ПЛИС, который поддерживает соответствующий стандарт.
ЗЫ Ну и если уж про Ethernet интересно было бы почитать про HW реализацию МАС уровня. Типа вот есть у меня мегаацп, хочу переслать его данные на комп.
ЗЫ Ну и если уж про Ethernet интересно было бы почитать про HW реализацию МАС уровня. Типа вот есть у меня мегаацп, хочу переслать его данные на комп.
По DDR ничего особо сообщить не могу, т.к. обычно их цепляют к прошиваемым процам типа NIOS или MicroBlaze, но я их ярый противник и никогда не использую, а цеплять внешние ДОЗУхи к логике как-то последние 10 надобности не возникало.
А блок altddio можно прилепить к любому выводу, на котором он, соответственно, физически есть. Это лучше всего выяснить либо в описании соотв. камня, или опытным путём.
А про MAC не очень понял: я ж, собственно, и описал его реализацию? Или я вопроса не понял?
А блок altddio можно прилепить к любому выводу, на котором он, соответственно, физически есть. Это лучше всего выяснить либо в описании соотв. камня, или опытным путём.
А про MAC не очень понял: я ж, собственно, и описал его реализацию? Или я вопроса не понял?
Ну вы описали, проблемы при работе с мас, плюс не много «выходного блока» на плис. А интересно было бы посмотреть на реализацию всего остального. Хотя бы из чего состоит конвеер от источника данных до крайнего пина плис.
Просто я пока работал с Ethernet только посредством процессора из SoC, на котором Линукс со всеми вытекающими. А вот как выглядит передача по Ethernet чисто на логике, интересно было бы посмотреть.
Просто я пока работал с Ethernet только посредством процессора из SoC, на котором Линукс со всеми вытекающими. А вот как выглядит передача по Ethernet чисто на логике, интересно было бы посмотреть.
Выглядит как мрак и смерть, если конечно не raw-интерфейс. Покупается или готовая корка, которая и работает с этернетом, или же софткорный проц, на котором можно хоть lwIP поднять. На Виртексе 6 ставил микроблейз и ПДП и гонялись данные на 1 Гбит- залюбуешься.
Потом потратил 3 дня жизни пытаясь понять почему не работают джамбо пакеты… чтобы открыть что в 7 винде по дефолту они выключены. Как я материл майкрософт…
Потом потратил 3 дня жизни пытаясь понять почему не работают джамбо пакеты… чтобы открыть что в 7 винде по дефолту они выключены. Как я материл майкрософт…
- count_enable
- 02 сентября 2015, 20:13
- ↑
- ↓
чтобы открыть что в 7 винде по дефолту они выключены. Как я материл майкрософт…Мда Jumbo-кадры тот еще гемор. На моей памяти только за последний год было несколько тикетов по не стандартным MTU (предоставляем аренду), хорошо что проблема в конечном итоге оказалась на стороне абонента. Похоже куча производителей всяких железок до сих пор уверена что 1500 байт хватит всем.
1500 это стандартный минимум, и его действительно хватает в 99%. От клиентов, в общем случае, провайдеры принимают пакеты с максимальным размером 1500, а все что больше фрагментируется или дропается, если установлен бит DF.
- vbolshakov
- 05 сентября 2015, 11:28
- ↑
- ↓
Т.е. около 40 строчек кода на Верилоге — это мрак и смерть? А програмить убогенький «Микроблайз» в не менее убогом «Эклипсе», так что бы он успевал в ПДП-шный поток подпихивать заголовки, а потом ещё геморроится с отладчиком, который постоянно отваливается (уж не знаю как у вас, у меня, что в Виртексе 4 с «Микроблейзом», что в альтеровсикх чипах с «Ниосом» — это стандартная фича) — это не мрак и смерть? Ну-ну…
Что именно убогого в обыкновенном риске?
Если у вас что-то отваливается — это ваши проблемы.
Поделитесь пожалуйста «40 строчками на верилоге», которые могут например передавать и принимать поток данных по UDP.
Если у вас что-то отваливается — это ваши проблемы.
Поделитесь пожалуйста «40 строчками на верилоге», которые могут например передавать и принимать поток данных по UDP.
- count_enable
- 03 сентября 2015, 12:24
- ↑
- ↓
В первой части статьи эти строчки. Приём — ещё проще (ибо можно crc32 не проверять).
И очень бы интересно было посмотреть, как вы почти 112Мбайт/сек будете перекидывать на ЦАП, например (реальная задача), используя «Микроблейз» с ПДП?
И очень бы интересно было посмотреть, как вы почти 112Мбайт/сек будете перекидывать на ЦАП, например (реальная задача), используя «Микроблейз» с ПДП?
В первой части генератор фиксированного пакета. Без обработки состояния марвелла, без никакой упаковки данных в пакет(хотя бы счётчика примитивного). Это всё равно что генератор цветных полос на VGA назвать видеокартой. А даже простейший сервер на UDP/TCP это уже совсем другой уровень.
Что касается проброса потока данных, то это делается AXI-Stream/ DataMover напрямую из корки в корку, а Микроблейзом просто удобно сконфигурировать этернет, поднять дхцп, прогнать диагностику сети и прочие плюшки.
Что касается проброса потока данных, то это делается AXI-Stream/ DataMover напрямую из корки в корку, а Микроблейзом просто удобно сконфигурировать этернет, поднять дхцп, прогнать диагностику сети и прочие плюшки.
- count_enable
- 03 сентября 2015, 14:59
- ↑
- ↓
О! Ну вот я вас и поймал на том, на чём и ожидал! Что такое «напрямую из корки в корку»? Правильно, вы опять же, аппаратно, гоните поток. При этом вы ещё сбоку навешиваете Микроблейз, который висит и съедает ресурсы только ради «для конфигурации» пары AXI'шных блоков. Кроме того, вы имеете исходные коды этих блоков? Нет. А теперь учтём, что 90% разработчиков в РФ (да и не только в РФ :)) используют криво-коряво сломанные САПР и, плюс, 90% проектов в РФ делается под военных — извольте выложить все исходные коды и обеспечьте безотказность.
На самом деле, мы с вами спорим на тему «о вкусе и цвете». Я просто хотел выразить не согласие с фразой про «кошмар и мрак». Написание руками UDP/IP-приёмопередатчика — совершенно не смертельная тема.
А по коду, см. мой ответ Signaller'у выше. Я, есс-но, выложил для поста сильно урезанную версию. В нормальной версии есть, например, вычислитель crc32 на лету
Это позволяет уже накладывать поверх UDP всё, что вам нужно и, в т.ч. данные из буфера и, конечно, счётчик пакетов. Честно могу сказать, это, конечно, не 40 строчек, а 260, при распечатке помещается на две странички. Один раз отлаженный, использовался уже минимум в 6 проектах. Собс-нно, всё что я имел сказать по этому поводу.
На самом деле, мы с вами спорим на тему «о вкусе и цвете». Я просто хотел выразить не согласие с фразой про «кошмар и мрак». Написание руками UDP/IP-приёмопередатчика — совершенно не смертельная тема.
А по коду, см. мой ответ Signaller'у выше. Я, есс-но, выложил для поста сильно урезанную версию. В нормальной версии есть, например, вычислитель crc32 на лету
CRC32_byte_stream CRC32_inst
(
.i_clk(i_clk),
.i_rst(i_rst),
.i_start_frame(start_calculate_crc),
.i_crc_shiftout(start_output_crc),
.i8_byte(byte),
.o8_byte(crc_byte)
);
Это позволяет уже накладывать поверх UDP всё, что вам нужно и, в т.ч. данные из буфера и, конечно, счётчик пакетов. Честно могу сказать, это, конечно, не 40 строчек, а 260, при распечатке помещается на две странички. Один раз отлаженный, использовался уже минимум в 6 проектах. Собс-нно, всё что я имел сказать по этому поводу.
Что именно поймали?
Описанная мной система собирается из готовых блоков за час работы, и будет работать из коробки. Если припрёт то можно вместо микроблейза подцепить голую машину состояний для конфигурации.
Написать просто приёмопередатчик и приёмопередатчик согласно технического стандарта это разные вещи. Чтобы работал в любой сети, программно перенастраивался — без перепрошивки, корректно обрабатывал ошибки и состояния. 260 строчек, да? И конечно же RFC-compliant, или хотя бы полностью покрывает конфигурацию марвелловского контроллера? Вы бы хотя бы приложили код для настройки марвелла, что ли… или он работает как MAX232 — что влетело, то и вылетело? Или простейшую проверку состояния линка, чтобы понять, слушает ли нас кто-то, или кабель из гнезда выпал.
Я не спорю что вручную можно написать и GbE, и SATA, и даже небо с Аллахом, но утверждать что собственные «40 строчек» заменяют полноценную корку — очень самонадеянно. Тем более что даже в корках от Хилинха есть стандартный интерфейс куда можно сразу пихать данные. Грубо говоря, хилые дают автобус куда можно посадить детей, а у вас — рама с мотором, и руль приколочен в одном положении. Это позволяет уже накладывать поверхUDPавтобуса всё, что вам нужно, и в т.ч руль, кресла и бензобак.
Что касается бедных разработчиков из РФ и злых вояк — проблемы негров шерифа не копулируют. Это не имеет никакого отношения к разработке быстрых интерфейсов в ПЛИС.
Описанная мной система собирается из готовых блоков за час работы, и будет работать из коробки. Если припрёт то можно вместо микроблейза подцепить голую машину состояний для конфигурации.
Написать просто приёмопередатчик и приёмопередатчик согласно технического стандарта это разные вещи. Чтобы работал в любой сети, программно перенастраивался — без перепрошивки, корректно обрабатывал ошибки и состояния. 260 строчек, да? И конечно же RFC-compliant, или хотя бы полностью покрывает конфигурацию марвелловского контроллера? Вы бы хотя бы приложили код для настройки марвелла, что ли… или он работает как MAX232 — что влетело, то и вылетело? Или простейшую проверку состояния линка, чтобы понять, слушает ли нас кто-то, или кабель из гнезда выпал.
Я не спорю что вручную можно написать и GbE, и SATA, и даже небо с Аллахом, но утверждать что собственные «40 строчек» заменяют полноценную корку — очень самонадеянно. Тем более что даже в корках от Хилинха есть стандартный интерфейс куда можно сразу пихать данные. Грубо говоря, хилые дают автобус куда можно посадить детей, а у вас — рама с мотором, и руль приколочен в одном положении. Это позволяет уже накладывать поверх
Что касается бедных разработчиков из РФ и злых вояк — проблемы негров шерифа не копулируют. Это не имеет никакого отношения к разработке быстрых интерфейсов в ПЛИС.
- count_enable
- 03 сентября 2015, 16:04
- ↑
- ↓
ни разу. Просто кто то не умеет принимать негативный отзыв как должное и намерен настаивать что его вариант есть свет и мраком быть не может.
ЗЫЖ на альтеровском семинаре поднимал аналогичный вопрос, но по usb интерфейсу. Вынесли вердикт что сделать конечно можно, но разумнее купить ибо разрабатывать дороже.
ЗЫЖ на альтеровском семинаре поднимал аналогичный вопрос, но по usb интерфейсу. Вынесли вердикт что сделать конечно можно, но разумнее купить ибо разрабатывать дороже.
ломаный софт это вообще незаконно, если что. А денег у вояк всегда хоть жопой дуй. Так что если вы работаете на войну, а начальство жалуется на недостаток финансирования и заставляет работать на ломаном софте — задавайте вопросы начальству. Далее. Купить готовую корку ДЕШЕВЛЕ чем делать ее самим. Если получается что нет — вам мало платят.
Слушайте, уже немного задолбало сравнение мягко и солёного в этой дискуссии. Поэтому не надо проталкивать своё мнение как единственно верное и тем более пытаться тут всех учить. А за мою зп не переживайте: я и когда в оборонке работал, получал — вам не снилось, а сейчас в славных Европах работаю и получаю даже по местным меркам нехило. Так вот вы удивитесь: в оборонке у нас как раз были лицензии на тот же Квартус, а вот тут мы работаем на ломаном софте! Так что, если что сказать по сути постов — говорите, а учить меня кому и какие вопросы задавать не надо!
ПК в общем, и с установленной Windows в частности, это не коммутатор, поэтому MTU у него по умолчанию 1500.
99% узлов в сети Интернет работают с IP MTU = 1500.
99% узлов в сети Интернет работают с IP MTU = 1500.
- vbolshakov
- 05 сентября 2015, 11:25
- ↑
- ↓
Ох, блин… И в личке такие вопросы задают. Понимаете, тот код-шаблон, что я выложил — это мегасильно урезанная версия универсального достаточно вылизанного модуля (с внешним буфером данных, расчётом crc32 на лету и т.д.), который я использую в нескольких больших проектах. Но за эти проекты я, в своё время, денег получил и выкладывать их не очень корректно. А, с другой стороны, вопросов много. Я подумаю, может сделаю ещё один пост, где выложу более осмысленный проект-выжимку.
Спасибо за статью.
Не забывайте также, что адреса передатчика и приёмника лучше всего выбирать из одной подсети. Особенно, если ваш девайс не отвечает на ARP-запросы (или вообще работает в режиме монолога и чихать на всех хотел :).Я бы даже сказал не просто в одной подсети, а адреса должны быть согласованна с прописанными подсетями вышестоящего роутера. Я когда-то вырвал много волос на голове, из-за того что не учел, что есть такая вещь как Proxy ARP, и в роутерах от CISCO эта штука включена по умолчанию.
А что вы в первой части наехали на USB? Там есть замечательный изохронный режим. Не сталкивался с 3.0 пока, но в 2.0 отлично работает. Понятно, что в USB 2.0 гигабит не запихнёшь, но если надо в 4 раза меньше, то всё отлично работает.
USB — это шина а не порт. В этом ее сильное — и одновременно слабое место. Дело в том, что у USB имеется пауза длиной в 1 микросекунду, и все устройства, подключенные к шине, должны соблюдать микросекунду молчания. Кто не соблюл — расстрел. Иначе говоря, отключается порт с этим устройством НАВСЕГДА. Пока не переткнёшь. А ведь в этот момент может прийти элементарная помеха. На производствах часто так бывает, что подходишь к компу, к кторому месяц не подходили — а мышка не фурычит. Вырубилась в кокой-то момент. А USB-принтеры это вообще сказка. Ethernet лишен этих недостатков, потому что Ethernet — это порт.
USB — это шина а не порт.
Вот здесь я с Вами не согласен.
Хотя в аббревиатуре USB и присутствует «шина» — на физическом уровне USB имеет топологию «звезда» – вы не можете на одни порт USB повесить несколько устройств просто соединив их последовательно (соединив параллельно D+ D-), вы можете это сделать только через хаб. А вот Ethernet поддерживает разную топологию, и «звезду» и «шину» (старый добрый 10BASE-2, когда один глючащий комп может положить всю сеть). И идеология обмена разная – в случае USB есть ведущий и ведомый, в случае Ethernet все равны и коллизии – это нормальное явление. Да и сами стандарты описывают разные уровни протоколов (от физического до …). Это слишком разные стандарты чтобы их так просто сравнивать.
топологию «звезда» используют практически повсеместно, однако протокол задумывался и работает как шина. Повторюсь. Имеется микросекунда тишины. Это ее сильное в том смысле, если кривое устройство подсунули — шина не накрывается (по сути — это рудимент) и одновременно слабое, в том смысле что помеха может выбить работающее устройство, место. По поводу хабов. видал я хаб, который представлял из себя тупо разъемы usb и светодиод. Без чипов. Кстати, даже работал. Мышка и программатор на нем висели. Часто глючил, потому как «звезда» настоящая получалась со всеми переотражениями. Вот.
По поводу хабов. видал я хаб, который представлял из себя тупо разъемы usb и светодиод. Без чипов. Кстати, даже работал
Но как?!
USB хаб физически не может быть пассивным устройством. И дело не в переотражениях а в том, что он принимает активное участие в инициализации устройств. Он, как минимум, сообщает хосту о изменении статуса своего порта, потом под управлением хоста индивидуально ресетит устройства, чтобы вычитать дескрипторы и, главное, присвоить устройствам адреса.
USB хаб физически не может быть пассивным устройством.Вполне может быть, но с некоторыми ограничениями — не более 1 порта.
- coredumped
- 05 сентября 2015, 13:08
- ↑
- ↓
Наехал уже хотя бы потому, что USB, извините, вы можете просто прийти и воткнуть где вам хочется? Нет! Извольте драйверы сначала поставить, причём строго от той чипухи, что вы используете (FTDI, например), строго под ту ось, на которой вы работаете и то с почти обязательными «танцами с бубном» (что я не помню как дрова ставили для популярных FTDI'ных мостов?). А в Матлаб как? Правильно, приходит Вася-программист, пишет в Дельфях, или на Visual C++ какую-то кривую прогу, которая работает только на одном компе, при это надо выполнить кучу шаманских действий, что бы получить бинарник с отсчётами, которые… А с Ethernet'ом пришёл, воткнулся и — работай прямо из Матлаба.
Ну, простите, претензии к драйверам — это претензии к криворукости, не более того. Можно, например, реализовать стандартный класс аудио (как раз для которого и создавался изохронный режим) и любая современная OS отлично увидит всё без драйверов. Для АЦП (пусть и не звукового) это очень разумное решение. И, нет, вы не будете ограничены 44100 или чем-то ещё, там можно вписывать любые свои числа (винда это понимает, по крайней мере, остальных не проверял на нестандартных частотах дискретизации). А можно просто пользоваться libusb, который есть под все OS и реализовать нужный вам драйвер 100% кроссплатформенно в userland (как это делает RTL-SDR). Выбирайте :) Ясно, что всё это надёжно и стабильно будет работать до примерно 240 мегабит (в случае USB2.0), если повезёт то выше, но 480 не получить никак. Если надо быстрее, то да, гигабитный езернет — следующий разумный выбор, я не спорю.
При этом у езернета есть свои минусы — например, многие ноуты до сих пор имеют или 100-мегабитный порт или формальный гигабит, но полное говно (младшие Реалтеки). Во-вторых, у большинства компов езернет один. Гонять поток которому нужна практически синхронность (если мы всё ещё о АЦП) через тот же порт, через который винда апдейты качает (и через свитч) мне не кажется хорошей идеей. И нужен очень приличный свитч, потому что, например, младшие Д-Линки впадают в 3-4 секундный ступор под полной нагрузкой регулярно, я их доводил до такого поведения не то что сплошным потоком пакетов от трафик-генератора, а до предела оптимизированным файловым сервером всего с двумя клиентами. Явно там что-то перегружалось раз в несколько минут внутри (пробовал 2 или 3 модели совсем младших, управляемые таким, к счастью, не страдают, а из неуправляемых лучше всего себя ведёт HP ProCurve).
В общем, езернет это полезно, но USB тоже не надо списывать со счетов.
При этом у езернета есть свои минусы — например, многие ноуты до сих пор имеют или 100-мегабитный порт или формальный гигабит, но полное говно (младшие Реалтеки). Во-вторых, у большинства компов езернет один. Гонять поток которому нужна практически синхронность (если мы всё ещё о АЦП) через тот же порт, через который винда апдейты качает (и через свитч) мне не кажется хорошей идеей. И нужен очень приличный свитч, потому что, например, младшие Д-Линки впадают в 3-4 секундный ступор под полной нагрузкой регулярно, я их доводил до такого поведения не то что сплошным потоком пакетов от трафик-генератора, а до предела оптимизированным файловым сервером всего с двумя клиентами. Явно там что-то перегружалось раз в несколько минут внутри (пробовал 2 или 3 модели совсем младших, управляемые таким, к счастью, не страдают, а из неуправляемых лучше всего себя ведёт HP ProCurve).
В общем, езернет это полезно, но USB тоже не надо списывать со счетов.
Дело в том, что если вы хотите выжать из сетки всё на что она только способна, то вас, понятно дело, будет интересовать, а какова же минимально допустимая пауза между пакетами.
Мин. пауза – 96 бит (Interpacket gap)
Комментарии (43)
RSS свернуть / развернуть