Имеется самописный компонент 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-ы и т.п.