Когда у меня всё заработало, я решил описать здесь свои мытарства.
Вдруг кто-то тоже "мучается" и этот "рассказ" может чем-то помочь. Короче, делюсь опытом.
Сори, если кому-то этот текст покажется "ничего такого" или будет "резать слух", я просто пишу так наверное от радости от успешного результата (ещё "не успокоился").

Было решено реализовать МАК-контроллер гигабитного эзернета на матрице логики в виду того, что согласно ТЗ плата д.б. работать на температуре от -40 градусов. В то время, когда это решение принималось, на рынке не было готовых МАКов на такую температуру с не-PCI интерфейсом (их и сейчас вроде нету), которые можно было бы использовать с быстрым процессором (ADSP TS201) в standalone варианте. Поэтому из готовых и доступных ядер МАК-контроллеров + матрица был выбран ксалинкс Спартан-3 (3s1000fg320-4) и ядро МАКа версии 8.1 того же ксалинкса.
Что касается физического уровня гигабитного эзернета, то на то время для температуры от -40 градусов вообще ничего из доступного не было, поэтому для опытного образца был выбран DP83865DVH (он работает от 0 градусов) с прицелом на последующую его замену на что-то другое (сейчас планируется 88E1011S).
Прошивка матрицы хранится в XCF08P. Там же хранится начальный загрузчик и программа процессора (это "лежит" за проектом матрицы). Загрузочный софт процессора (256 слов по 32 бита) хранится в ПЗУ, которая реализована в самой матрице (инициализация содержимого через файл .coe).
Итак, плата была разведена и изготовлена и я приступил к разработке проекта матрицы. Вообще это считаю порочной практикой, т.к. надо сначала сделать проект, а потом разводить матрицу на плате. Иначе могут быть труднопоправимые недочёты в разводке. Но мы, как известно, не ищем лёгких путей (начальство ведь этих тонкостей не понимает), нет таких проблем, которые мы не могли бы сами себе создать. Кое-какой опыт за плечами позволял предполагать удачный исход.

Коротко по проекту матрицы. Были взяты исходники ядра из ИСЕ 8.2 , которые "подключались" через немного подправленный файл gmac_block.v (он генерируется ИСЕ при создании проекта через генератор корок). Правка этого файла заключалась в добавлении "фиктивных" wire для configuration_vector и mac_unicast_address, а также переименовании (уже не помню почему, видимо тоже компилятор ругался) имени порта mdc в mdc_out и имени корки gmac в gmac_gen. К ядру было добавлено два фифо на приём и передачу (получены с помощью генератора корок), сделан интерфейс с процессором по параллельной шине (32 бита). Плюс были добавлены некоторые мелочи, которые не буду упоминать. Очень важный файл констрейнтов был взят и переработан тоже из стандартной генерации проекта (gmac_example_design.ucf) в части выкидывания "BU2/U0/" и правки некоторых названий связей. При разработке проекта выплыли первые две ошибки (результат порочности, описанной выше). Одна в том, что я лоханулся и забыл, что надо завести тактовую частоту приёмника (125 МГц) с физического уровня не на любой вход матрицы, а на тактовый вход. Тут спас опыт - я большинство незадействованных выводов матрицы (она же в корпусе BGA, так что к выводам не подберёшься) вывел на переходные отверстия. Так что это мне позволило кинуть перемычку и завести тактовую куда надо. Вторая ошибка - один из выходов шины данных в физический уровень компиллятор наотрез отказался разводить на ту ногу, что я ему задал (т.е. на ту ногу, что я развёл). Пришлось делать ещё одну перемычку.

Наконец всё готово к включению. Включаю...
Ничего не работает, даже нет автонегоциации физического уровня. Регистры физического уровня не читаются и не пишутся. Тут и начались основные мытарства...
Долгие размышления почему не работает физический уровень ни к чему не привели. Почитал по форумам (и тут тоже), что не один я мучался с этим DP83865. Это меня даже дезориентировало (как потом выяснилось) и мы купили ещё несколько штук DP83865 в другой конторе. Но после перепайки ничего ровным счётом не изменилось. Обратился в поддержку National через дистрибьютера. Они прислали доку пошагового поиска неисправностей (которая у меня уже была, но я ей не воспользовался - мы же не любим читать матчасть). Делать было нечего и я решил твёрдо пройтись по этой доке от начала до конца. И это помогло! Снова выплыли две ошибки. Первая - я неправильно развёл разъём эзернета, у меня получилась обратная нумерация контактов (поэтому не мог найти импульс автонегоциации). А всё из-за неадекватного восприятия забугорного чертежа этого разъёма (от Молекса). Пришлось слепить нестандартный кабель эзернета с переставленными наоборот контактами на одном из концов. Вторая ошибка - я забывал при чтении/записи регистров физического уровня выставлять его физический адрес. В результате я посылал адрес 0, а у меня на плате он выставлен в 1 (страп - резисторами). Ясное дело, из-за этого он и не отзывался, ведь не с ним обмениваются. После исправления программы и с переделанным кабелем физический уровень пошёл работать как надо!

Однако обмена по эзернету всё равно не было. А это означало, что ядро МАК-контроллера не работает. Настало время разбираться с ним. Но в службу поддержки, понятное дело, уже не обратишься, вся надежда только на себя. Снова долгие раздумья ни к чему не привели. Но я вдруг вспомнил не очень мне понятный (тогда) небольшой кусок тескста в самом конце руководства по ядру МАКа (читал же!) о подборе зачем-то какой-то фазы. Перечитал, вроде понял для чего и решил "покрутить", всё равно никаких идей больше не было. "Крутил" значение фазы PLL приёмника прямо в FPGA editor без перекомпилляции проекта. И чудо! При определённом диапазоне значения фазы заработал приём! Я выставил фазу в "среднее" положение (уже в .ucf файле). Но передачи так и не было. Причём странность была в том, что лампочка активности физического уровня при передаче моргала, но компьютер ничего не принимал (смотрел программой ethereal). Пришлось взять осциллограф и смотреть сигналы. Выяснилось, что с матрицы все сигналы при передаче выходят правильные. Это меня повергло в уныние, т.к. означало что ядро работает, физический уровень вроде работает, а передачи нету уже по каким-то мистическим причинам. Однако оказалось никакой мистики нет. Я снова вспомнил, что ранее при чтении даташита на DP8З865 обнаружил непонятность для себя о том что есть два варианта интерфейса с МАКом - один 3COM, второй HP. Я снова заглянул в даташит, увидел, что они отличаются какими-то временными характеристиками (в даташите как-то было туманно про это написано). По умолчанию (выбирается страп-резисторами) у меня стоял интерфейс 3COM. Я решил попробовать поменять на HP, всё равно других идей не было никаких. Для этого надо было программно прописать в регистр AUX_CTRL физического уровня значение 0xA000 (было 0xB000). И снова чудо! Началась передача по эзернету!

Вот так закончились мои мытарства по доведения железа до работающего состояния. Теперь перехожу непосредственно к embedded программированию, т.е. написанию программы по обмену через эзернет (стек tcp/ip) и пр.

Удачи всем.

Поздравления!

Поделитесь пожалуйста упомянутой докой пошагового поиска неисправностей или ее номером AN.

Вопросы про кручение фазы: зависит от разводки платы или констрейнов на матрицу? планируете каждый экземпляр устройства подкручивать или разовая отладка?

2 id_gene:

Спасибо!
Дока такая: AN-1329.

Фаза, как я думаю, зависит от применённого PHY, от того как "ляжет" проект в матрицу и ещё от каких-нибудь конструктивных особенностей, сказывающихся на задержках сигналов. Короче говоря, крутить фазу надо только для конкретной реализации, а дальше все платы по этому проекту "шьются" с одной фазой. Так что каждый экземпляр "крутить" не надо.

я так понимаю речь всёже идёт о PHY DP83865DVH ?

PS: ради интереса - а сколько ресурсов занимает в 3s1000 причёсанный GigaMAC (без учёта фифо)

Прочитал, как "Остров сокровищ" и "Граф Монте-Кристо". Большое спасибо
Вот пример, когда КПД форума равен 101%.

Doka

Да. Сори, маханул в торопях. Топик поправил.


Сколько занимает ресурсов само ядро точно не скажу.
У меня помимо ядра ещё два фифо по 8КБ, ПЗУ 1КБ, пару мелких схем для преобразования параллельного кода в последовательный и наоборот (чтение по SPI датчика температуры и чтение/запись регистров внешней платы) и организовано 8 шт регистров для записи значений параметров. Ну, ещё немножко ушло на организацию интерфейса с процессором.
Само ядро настроено с такими параметрами:

Т.е. интерфейс с PHY типа RGMII, а таблицы дополнительных МАК-адресов для фильтра нету, но есть фильтрация на "свой" МАК юникаст-адрес. Настройка параметров ядра через хост-интерфейс.
Так что могу привести сводку PAR всего проекта. Я так думаю, что в ней на 95% это ядро GMAC. Фифо и ПЗУ лежат в памяти, так что слайсов не занимают. Вот сводка:



Konst_777

Хочу добавить некоторую инфу по поводу необходимости настройки фазы приёмника.
Новая инфа возникла после того, как я решил переделать приёмное ФИФО.
Ноги этой переделки растут из того, что один ФИФО не позволяет сделать простой операцию разделения принятых пакетов друг от друга. Т.к. пакеты попадали в один и тот же ФИФО, то было не ясно при чтении из ФИФО где конец очередного пакета и начало следующего. Можно было, конечно, сделать разделение анализом в программе, но это муторно, нет 100% гарантии. Но главное - ядро МАКа ведь само разделяет пакеты и терять эту фичу было бы глупо.
Короче я решил сделать два приёмных ФИФО вместо одного. Алгоритм простой: когда пакет принят в один ФИФО (причём принят только успешно), то два ФИФО "переключаются" между собой, так что следующий пакет будет приниматься в другой ФИФО, а тем временем первый ФИФО будет вычитан процессором (по выставленному прерыванию). В результате, если процессор будет каждый раз успевать вычитывать заполненный одним пакетом ФИФО (т.е. до переключения снова на этот ФИФО и приёма в него), то разделение пакетов будет автоматом обеспечено. В случае неудачного приёма пакета (например, контрольная сумма не сошлась) переключения на другой ФИФО и генерация прерывания не происходят, а происходит сброс "неудачной" инфы в том же ФИФО, тем самым делается подготовка этого ФИФО для нового приёма (уже, возможно, удачного).
После правки (добавления ещё одного приёмного ФИФО на 8 КБ, коммутации обоих ФИФО по отношению к МАКу и процессорной шине) и компилляции проекта начал его проверять. Оказалось, что приёма нету. Сначала подумал, что напортачил при переделке. Посмотрел - вроде ничего не заметил. Решил "покрутить" фазу частоты 125 МГц приёмника. Оказалось, что фаза "уехала" относительно старого значения, поэтому и приём пропал.
Потом пришли в голову ещё кое-какие идеи и я снова совсем немного поправил проект. На этот раз после компилляции приём не пропал. Но! Я решил уже для надёжности снова крутануть фазу и посмотреть в какие ворота она теперь попадает. Оказалось, что фаза немного ушла!
Для примера привожу значения фазы в процессе двух правок/компилляций: 150 (после получения первого успешного проекта), 230 (после добавления второго ФИФО), 205 (после небольших правок обращения к ФИФО по шине процессора).
Так что вывод такой: после каждой новой компилляции проекта надо снова подбирать фазу, даже если приём не прекратился (для надёжности).
Лучше это делать в FPGA editor, т.к. это не требует перекомпилляции проекта, дальше только генерация файла программирования и Impact.
Фаза, при которой работает приём, лежит в диапазоне примерно 90 единиц. Так что найдя первое значение фазы, при котором начался приём, можно смело добавить к нему 90 (с учётом того, что фаза меняется циклически в диапазоне 0-255), проверить и потом понемногу добавлять (скажем, по 10) пока приём не прекратится. Ну а потом взять среднее.

Берем и увеличиваем шину FIFO на один бит, этот бит делаем равным единице в начале и конце езернет пакета. Дальнейшая логика без особых проблем может разобраться первый это байт пакета или нет. Если совсем немного помудрить и сделать приемную шину хотя бы x16 то тогда на шару можно получить целых два лишних бита, и тогда вообще никакой неоднозначности не возникнет. Такая доделка займет совсем немного ресурсов, а позволит увеличить глубину FIFO в два раза и использовать его более эффективно.

Битов "в ширину" можно сделать больше - не проблема, но не уверен, что логика переключения этих битов займёт меньше ресурсов чем сейчас у меня занимает логика переключения между двумя ФИФО. И мне такая идея не нравится с точки зрения реализации программного обеспечения. Она означает, что я для разделения пакетов должен делать программный анализ этих дополнительных битов, причём просматривая всё содержимое ФИФО, на что уйдёт время. И потом это не надёжно, т.к. есть асинхронные операции по отношению к ФИФО, например, сброс ФИФО, что может вызвать нарушение "целостности маркировки" (например, когда я сбросил ФИФО во время приёма пакета).
С другой стороны, моя идея позволяет ни с чем не заморачиваться: я просто при обработке прерывания "заряжаю" ДМА на высасывание из ФИФО очередного пакета, а в обработке прерывания ДМА "передаю" этот пакет на обработку. Так что по сути программно ничего для отделения пакетов друг от друга не делаю.
И ещё. Два ФИФО позволяют легко реализовать обработку (отбрасывание) ошибочно принятого пакета. Ведь МАК не знает о том успешно принят пакет или нет до тех пор, пока не примет его целиком и не проверит контрольную сумму. А данные при этом всё равно записываются в ФИФО и никаким другим путём кроме как стереть ФИФО или считать процессором, эти данные не выкинуть. Если считывать процессором пакет с признаком ошибки приёма (допустим я такой бит добавил) - то это просто лишняя работа для процессора. Если сбрасывать ФИФО, то это подходит только если не стираешь что-нибудь лишнее. А вот тут как раз два ФИФО и помогут - я сбрасываю только тот ФИФО, который принимал "ошибочный" пакет, в то время как нормальный пакет, принятый ранее, у меня будет находиться в другом ФИФО. При этом никакой доп загрузки процессора на отбраковку пакетов - ошибочные пакеты будут автоматом выбрасываться внутри матрицы.

Dimonira
Все это оч круто, до тех пор, пока не надо заботиться о пиковой пропускной способности самого канала. Размер Ethernet пакета может варьироваться в очень широких пределах, сейчас точно не вспомню, но минимальная длинна была порядка 64 байта, а максимальная зависела от текущего режима работы сети и составляла от ~1500 байт до 16кБ. Ну и как при таком разнообразии входных параметров будет работать ваша система с двумя FIFO? И это с учетом того, что память в Спартане побита блоками по 4кБ Т.е. в идеале в два блока памяти пометилось бы почти 4.5 1500 байтных пакета, а в вашем случае аж два

Еще момент. В дуплексной сети ошибок в пакетах я не встречал. Практически все современное оборудование работает в дуплексе - о каких ошибках приема мы говорим? Да, они возможны, но как исключение из правил, а не как постоянная практика. По этой причине затачивать тракт под эффективное удавливание ошибочных пакетов в минимуме, IMHO, избыточно. Хотя мож вы собираетесь связываться по Ethernet в условиях жесточайших электро-магнитных помех

Основным источником ошибок в полудуплексной сети служат коллизии. А по стандарту они считаются невозможными начиная с определенного байта пакета. По этой причине проще забакапить голову пакета на SRL, а потом уже при отсутствии коллизий начать записывать в основное FIFO.

Все эти моменты я знаю из собственного опыта написания и отладки собственного TriSpeed Gigabit Ethernet MAC. BTW, полнофункциональный TriSpeed Gigabit Ethernet MAC требует для своей реализации немногим больше 1000 альтеровских ячеек или 500 хилых слайсов. То, что генерит кореген, IMHO, слегка избыточно.

P.S. Мы на гигабите разгоняли медиум до ~123MB/s - остались только самые положительные впечатления от Ethernet как от интерфейса

Вы правильно написали, что при большом потоке надо делать оптимальнее. Именно с этой точки зрения зачем делать лишнюю работу по разбору пакетов?
И какая разница сколько занимает пакет в ФИФО? Да мне на это положить. Какая разница будет ФИФО заполнено на 90% или на 10%, если процессор будет не успевать обрабатывать принимаемую инфу? Если пакет занимает мало - так я его бысрее вычитаю и тем самым быстрее освобожу для приёма другого. В принципе можно сделать не два, а больше ФИФО, это же не проблема. С другой тороны, это я хочу успевать вычитывать по одному пакету, а если не буду успевать, то страшного то ничего нету! Просто в ФИФО будут попадать по нескольку пакетов. Тогда уж придётся разделять программно, чего бы не хотелось. Размер ФИФО я, кстати, выбирал исходя из нестандартных пакетов, больше чем 1.5 кБ, а вовсе не из того, чтобы совать в них по несколько пакетов. Стандартный Ethernet пакет имеет размер до ~1.5 кБ, а всё что больше - это Jumbo-фреймы с размером до 64КБ, с которыми не всегда может работать железо Ethernet. Но это разнообразие, как Вы говорите, настраивается при организационных работах по настройке сети. Так что неожиданности должны быть исключены, тем более что у меня пока подразумевается соединение точка-точка. Хотя я сам собираюсь пользоваться Jumbo на передачу именно с целью увеличения производительности.
Кстати, если мне не изменяет память, когда мы делали Фаст-Эзернет на готовых микросхемах МАК-ов (Макроникс), то там память для пакетов организовывалась похоже - её можно было разбивать на блоки, каждый из которых принимал один пакет. Так что я ничего нового не придумал.
Самое смешное то, что у меня приёмный канал будет с мизерной загрузкой, т.к. по нему будет вяло идти только управление девайсом. А вот передача будет где-то 90 МБ/с. Эти мнимые, как пока кажется, недостатки системы с двумя ФИФО обойдутся мне гораздо меньшей кровью, чем программное разделение пакетов. Это уж точно.

Поскольку ваш входной поток предполагается мизерным по отношению к выходному потоку, то тратить слишком много усилий на приемную сторону действительно не стоит. Просто вы уж очень круто и расточительно обходитесь с ресурсами чипа - в любом случае - ваш проект, вам и принимать решение. Я делал по другому.

Для работы с Jumbo пакетами необходимо писать свой драйвер. Сама система, если не ошибаюсь, не предоставляет сервисов доступа к столь низкоуровневм функциям.

Еще, берут легкие сомнения в способности виндового TCP/IP стека прокачать с одного сетевого интерфейса 90MB/s Еще, из моего опыта, хостовую сетевуху лучше брать серверную. Она несколько дороже, но гораздо меньше грузит процессор хоста на приеме за счет аппаратных ускорителей предварительного разбора Ethernet фреймов.

А что мне с этими ресурсами делать? Я же не могу лишние ресурсы выкинуть! Ну, есть они и всё тут. Нету у меня мотивации их экономить! Зачем? Я вот думаю, может ещё увеличить размер ФИФО, чтобы зря память не пропадала. Или количество ФИФО увеличить. А может увеличу размер ОЗУ (сейчас 256х32) в матрице, которое используется начальным загрузчиком (я тут про него не писал, забыл), может для других целей пригодится.


Зря берут. Я делал тест на пне-4 3ГГц и достиг где-то 97МБ/с. Мама компьютера была на 915 чипсете с двумя гигабитниками на борту. Тут есть тема про пропускную способность, я там про это писал.
Но вообще у нас принимать будет сервер на 4-х двухядерных АМД. Ведь ещё обработка нужна.

вопрос к Dimonira по поводу разьема для GigabitEthernet: у вас все-таки настольное/офисное устройство или приборный блок для работы на улице?
Если последнее - то какой тип разьема вместо RJ45 вы для себя выбрали? Мне на глаза пока ничего подходящего не попадается: нужны круглые металлические блочные/кабельные разьемы для вывода из блока GigabitEthernet, со степенью защиты IP67(IP68) (по механике/климатике). Я вообще пока не увидел разьема с импедансом, который был бы с согласован со 100-омным кабелем, или хотя бы с приемлемой (до 200МГц/600МГц для кабелей Cat5/Cat7) полосой пропускания.
Пока смотрю в сторону:
1. Amphenol с его серией "Subminiature Cylindrical Connectors Commercial 38999 Serias III Type Connectors". Там есть разьемы с 6-ю парами твинаксиальных контактов (через 4 таких контакта можно пропустить 4 Ethernet-ые витые пары) Но опять же, характеристик на них - никаких нет...
2. Lemo, например, К-series....

У меня обычный разъём на плату от Молекса. А плата внутри девайса, в корпус которого кабели входят через гланды.
В своё время я тоже обыскался разъёмов на стенку корпуса, но, так ничего и не найдя, остановился именно на таком построении: кабель внутрь корпуса через гланды, а разъём прямо на плате.
Может, конечно, это не всегда приемлемо, спору нет.

а можно чуть подробнее? Я не понял что есть "гланды" Т.е. если плата находится внутри переносного герметизированного блока, то как обеспечивается разьемое соединение "блок-кабель"???

У нас нет требования полной герметичности, т.е. девайс не будет подвержен осадкам, лежать в воде и пр.
Гланды (по англицки так: gland) - это ввод/вывод в/из корпуса для кабелей, представляет из себя что-то типа "болта" со сквозной дыркой по оси, через которую проходит кабель. Этот "болт" крепится через отверстие в корпусе "гайкой" и уплотнительными резиновыми шайбами. Внутри него тоже уплотнительная резина (кольцом). На его наружном конце что-то типа цанги. После продевания кабеля сквозь "болт" и резинку что внутри, на него накручивается зажимная "гайка", которая сжимает цангу вместе с резинкой и кабелем. Резинка зажимается и закрывает пустоты между кабелем и внутренней дыркой "болта", обеспечивая некую герметичность.
Понятно объяснил?
Этих гланд большое количество вариантов как по размерам отверстия, так и по прочим параметрам. Например, есть пластмассовые, есть с металлическим корпусом. Цанга может быть сразу на "болте", а может вставляться внутрь отдельно. Короче, вариантов масса.
Если разделанный кабель не протощить сквозь гланду (например, на кабеле разъёмы, как в моём случае с эзернетом), то кабель сначала протаскивается, а потом на месте разделывается. Т.е. это делается на этапе пуско-наладочных работ.

Для примера: я применял на похожем девайсе такие гланды - "Perfect" brass cable gland от Hylec Components, ордер код 50.009. Их я покупал через Farnell, код 236573. Стоили они тогда около 2.45$ за штуку.

Гермоввод

Предельно!
Но мне, увы, это не подходит, кабель мне необходимо подключать именно к блоку. Буду дальше искать и думать.

IP67 RJ45 connectors:
http://194.2.77.62/ged/amphenol/download.asp?id=1519

да, блогодарю за ссылку, но это я уже видел. Как-то стремно все-таки пластнассовую фитюльку RJ45, пусть даже и в железном корпусе, ставить на ответственный блок.
Есть у Амфенола еще один разьем, но он специфицирован только до 100Мбит:



да, блогодарю за ссылку, но это я уже видел. Как-то стремно все-таки пластнассовую фитюльку RJ45, пусть даже и в железном корпусе, ставить на ответственный блок.
Есть у Амфенола еще один разьем, но он специфицирован только до 100Мбит:

А чем он не подходит? Ведь гигабитные сети делались на "базе" стомегабитных.
Т.е. железо (кабели/разъёмы) те же самые. Ведь частоты практически те же - 125 МГц.
Имхо вполне будет работать.
Я тоже сначала искал разъём, для которого указывался параметр на 1Гб.
А теперь считаю, что только зря время терял.

А разве не 250МГц?

Есть еще один интересный путь, навеяный последним номером журнала "Компоненты и технологии". Там речь идет о применении ИМС National Semiconductor (CLC001 и CLC012) для построения скоросной (до 622Мбит/с) линии связи на дальность 100..200м по витой паре или по коаксиалу.
Мне, собственно, от GigabitEthernet надо: линия связи "точка-точка" со скоростью до 1Гбит/с, на дальность до 100..200м, со стандартным форматом передачи данных. Желательно использование дешевых и доступных разьемов и кабелей связи. Тогда получается связка:
" ПЛИС (MAC GigabitEthernet) -> TLK1221 (PHY) от Texas Instruments -> DS15BA101 (драйвер физической линии) от NS -> коаксиальный разьем 50Ом -> коакс. кабель 50Ом -> приемник DS15EA101 от NS -> TLK1221 -> ПЛИС.
И все бы было бы хорошо, но вот DS15EA101 пока только в виде не образцов, а предварительной информации. И замены им я пока никакой не нашел.

Может, кто-нибудь что видел? Или примерно похожие решения?

Дополнение.
Небольшая 3-х дневная победоносная война с перестановкой байт в передающем ФИФО описывается в отдельной теме тут.