Имеется самописный компонент MAC. Имеется его аппаратная реализация. Функционал его проверял простым драйвером, который отправлял данные через него и получал (их же). Вроде всё работает. Сейчас задача, протестировать его на реальной задаче.
Из вариантов которые приходят на ум - это запустить exmaple Web server. Но в этот вариант не совсем хочется, так как нужно реализовывать поддержку NicheStack TCP/IP, а глядя на драйвер lan911c или Avalon OpenCores MAC не очень хочется (в этих дровах сам черт ногу сломит), да и некоторые у меня апаратно реализованы не так как у них.
В дальнейшем как таковая поддержка TCP/IP в проекте где будет использоваться мой MAC не требуется, так что не особо хочется делать лишнюю работу(
Какие будут варианты?

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

В смысле? Какие косяки могут возникнуть при этом?

А дальше какие варианты?

Ну самое простое - это асинхронный поток данных на приеме. Если у Вас MII. Где-то должен быть сделан переход к системной частоте. Конечно, при RMII все дело подвязано к 50 Мгц, там проще. А вот для MII все данные по приему и соответственно все флаги, обозначающие начало приема пакетов и т.д будут выставляться не под системную частоту, а под приемную. И где-то должна бысть сделана CDC...

CDC это собственно что имеется ввиду? Что подразумеваетяс под системной частотой?

Есть проект. В нем есть:
системная частота - это та, на которой работает основная часть проекта. Например 200Мгц
Есть частота передачи по MII - это ТхС, 25Мгц. Она может быть связана с системной...
И есть частота приема по MII - это RxC, это тоже 25Мгц, но по отношению к ТхС она может "плыть" в соответствии с требованиями к генераторам для PHY в 50ррм.
СDС - это пересечение клоковых доменов...

Насколько я понимаю для CDC нужно реалтзовывать cross-domain логику. Её я учитываю (это необходимо когда идет взаимодействие с шиной Avalon). При тестирвании это учитывалось (давался фазовый сдвиг на неск временных единиц между ETH_CLK и CLK в симуляторе). И при тестирвании на плате тоже было корректно всё (там я как понимаю тактирование TxC и RxC идет от PHY чипа и фазовый сдвиг там имеется)

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

TxC идет из МАСа, а вот RxC -действительно из PHY.

Да ладно из MAC? если мне память не изменяет, то в стандарте и TxC и RxC это входные сигналы MII. MAC clock (от pll) используется для avalon интерфейса компонента. Логику с флагами тоже учитывал (при передаче флага из домена с высокой частотой в домен с низкой - удлиняю его до длительности > чем длительность одного clock'a в другом домене).Сейчас проверяю его на отладочной плате (пока с RJ-45 заглушкой, потом попробую воткнуть host-компьютер).
Это всё понятно. Вопрос как дальше отлаживать, чтобы определить реальную работоспособность?

выйти через нее в сеть и прокачать пару терабайт снимая логи.
потом нагреть до +85 и еще прокачать,
потом остудить до -40 и еще раз

И еще покачать питание в разные стороны...
кабель подвесить в 100 метров... Угостить помехой... Хотя последние два испытания относятся к PHY, но все же...

По поводу TxC память Вам действительно изменяет... Я же об этом все писал многократно. Посмотрите статьи у меня на сайте...

Ладно. С TxC это не суть. Память у меня не идеальная, всякое бывает. Статьи читал (не все) - интересные очень, много полезного.
По поводу питаний и перепада температур - думаю это не критично.
Вот насчёт выйти в сеть - возвращаемся к началу вопроса.
Нужно предельно простое приложение, которое протестировало бы аппаратную часть? Нужен вариант альтернативный webServer'у не требующий писать поддержку TCP/IP NicheStack'a. Или без этого не обойтись? Просто если не обойтись, то нужен хороший пример драйвера (вышеупомянутые мною драйверы дико наворочены местами)

Еще для MAC по-хорошему надо коллизии проверить.

Поддержка Ethernet 10Mb и half-duplex не требуется. Зачем тогда на коллизию проверять?
Хочется услышать рекомендации и советы по вопросу обозначенному мною выше.

to iosifkr
Дома глянул в документы, так же в статьи насчет TxC и не понял одного. Цитирую вашу статью из Chip News "Трасивер Fast Ethernet. Интерфейс MII"

для RxC

Процитировал слово в слово из статьи, разницы не заметил, да и в стандарте IEEE802.3 порты TX_CLK и RX_CLK - input. Но это не суть темы, а так между делом. Больше инетересно как малой кровью, не мучаясь пределыванием драйверов lan911 или аналогичного ему сделать работоспособный пример для аппаратного MAC'a
В дальнейшем банный блок предполагается использовать в транспортных сетях, где TCP/IP стек не поднимается, а идет пересылка Ethernet-кадров через другие интерфейсы (радиоканал или еще как-то).

Что же, Вы совсем его в сеть втыкать не будете? Странно... Зачем тогда было его делать? По радио будете передавать 100 мегабит в езренетовских кадрах?
Я просто хотел сказать, что для проверки MAC надо проверить все его фишки для работы с сетями, в т.ч. коллизи. Можно еще jumbo-фреймы попроверять, VLAN-ы и т.п.

Написание такого компонента как МАС-контроллер ответственное дело) Сам разрабатывал МАС с аппаратной поддержкой промышленных протоколов. Тестирование как уже было написано проводят перекачкой больших объёмов данных и собиранием логов. Посмотрите также работу ситемы при заполнении внутренних буферов контроллера. Также интересно посмотреть поведение(реальное) при работе с не стандартизованным трафиком (короткие кадры, поток с уменьшенным меж кадровым интервалом), практика показывает, что иногда компоненты зависают)
И соответственно испытание на пропускную способность тоже не следует забывать. Очень интересно увидеть используемую вами архитектуру и полученную производительность.
Кстати вопрос у меня не по теме: примерчик бы файла временных ограничений системы с НИОСом и самописными компонентами?

Написал об исправлении. Виноват...Проглядел, хотя и перечитывал текст...

Ну не совсем так. С одной стороны в плату втыкается провод от Ethernet из сети, к другому разьему поключается радиомодуль. И плата работает в режиме моста, передавая пакеты через себя

Тогда можно ли задать такой вопрос: А зачем здесь нужна ПЛИС?
Ведь можно применить микроконтроллер с MAC и PHY... Они теперь у TI или у Фрискейла есть...
Или вот, к примеру Ethernet-контроллер. С параллельной или с SPI шиной.
Ведь без процессора сеть не будет работать. А процессор в ПЛИС - дорогой и слабый. Да и МАС должен куда-то класть пакеты, а в ПЛИС памяти мало. И внешняя память у ПЛИС будет задействована процессором.
Вот смотрите, если поток данных по сети не большой то KSZ8851SNL с SPI шиной стоит всего примерно 7 долл (Микрел). Но в нем и память и устройство контроля за приемом, за переполнением, счетчики событий, и PHY... Ну и по каналу передачи тоже все есть... Так стоит ли дело того, чтобы наворачивать МАС в ПЛИС? Вот Вы же писали об LAN911. Это же тоже контроллер, а не просто PHY...

Ага! Значит, надо проверять сетевые функции. В первую очередь, конечно, передачу данных большими объемами. Ну и остальное не забыть. Задача, конечно, та еще...
Действительно, почему не взять готовый контролллер?

Ну MAC - это только часть проекта. Там будет еще огромная система с самописным физическим радиоинтерфейсом. Которая сначала макетируется на ПЛИС, а потом отправляется всё вместе на фабрику, чтобы отпечатать чип. (Ну MAC не в этом виде будет использоваться. Требуется Gigabit Ethernet с поддержкой Fast Ethernet'a - но надо же с чего то начинать)

У-у-у.. Это Вы потом и гигабитный MAC будете проверять аналогично? Конечно, нет другого выхода, если надо сделать новый чип. Но, если делается чип, то имхо надо делать нормальную поддержку езернета, в т.ч. и с полудуплексом. Разве такой узкоспециализированный езернет в чипе не станет проблемой?

А как же RMII и SMII... Их тоже будете делать?
По крайней мере, сильно рекомендую сразу же начать с RMII. Там же все дело значительно проще. И только одна тактовая... Да, и такой режим можно будет сразу же использовать как ретранслятор... А если предусмотрите РОЕ, то можно Вашу железку будет подвешивать на 100 м провод до крыши, а там получится переходник с сети на радио...