Играюсь с контроллером MII на VHDL, прием работает без проблем, а с передачей что-то странное - на 972 идут нормальные сигналы TX_DATA и TX_EN, она клокает TX_CLK, TX_ERR запаян на землю - а на передачу ничего не идет. Осциллограф у меня по полосе до честных 100MHz не дотягивает, но видно, что на выходах TP+ и TP- постоянно бегут импульсы, но сниффер не показывает наличия пакетов, лампочки приема и передачи не моргают. Намекните - в какую сторону копать? Микросхему менял - симптомы те же.

вот чуть позже буду сам с подобными глюками возиться.
а пока только к этому готовлюсь.

обысчно в таких случаях помогает прочтение повторное датащита и еще
прочтения датащита на девелопмент боард.

Вчера запустил девайс на 972-й. Трансивер как трансивер, никаких глюков. Даже MDIO работает Схема включения из даташита.
Если линк на 100, на TXOP+- всегда должна быть характерная трехуровневая последовательность амплитудой 0.5В примерно, вне зависимости от TXEN.
Если не так - ошибки в выходной трансформаторной секции или кз по выходу.

Могу посоветовать замкнуть вход на выход и принимать то что передаёте (Это можно сделать как програмно через MII так и просто физически)

Показывает ли ваш сниффер неправильные пакеты? Может у вас ошибка в пакете и сниффер его не понимает. (программа типа ethreal - показывает всё)

Проверьте качество RX TX clock. У меня был случай подобного глюка (работало но со сбоями) из-за некачественного кварца.

Вопрос в тему:
Судя по ДЩ - для передачи кадра ethernet не надо самому генерить CRC.
Однако эксперименты показывают другое: при передаче заранее записанного кадра с CRC - сниффер его ловит, а при передаче этого же кадра без CRC - не ловит.
Кто-нибудь может дать точный ответ: генерит ли микросхема CRC сама - или нужно гемороиться и делать это самому?

Даю ответ совершенно точный: трансивер ничего не знает о том, что он передает. Его дело договориться с дальним концом и гнать данные. Если ему договариваться не разрешено, то гонит так, как задано. А когда договаривается гонит в линию импульсы.
CRC и остальное - это дело МАС.
А сниффер делит пакеты на правильные, неправильные по структуре и пакеты со сбоями. Если нет Ethernet-кадра - это пакеты со ссбоями.
А что нужно делать самому - примерно есть в статье на www.iosifk.narod.ru - статьи - Ethernet.
Сначала заглушку - сам на себя. чтобы заранее было известно на какой скорости.
Потом только на отдельную машину. Иначе раз в секунду будете ловить широковещательные пакеты.
Удачи!

И еще в догонку.
Если разработка новая, то лучше трансивер ставить KS8792 от micrel.
На передаче все ли правильно - преамбула, стартовый байт, данные и CRC ?
Может ошибка в стартовом байте? Проверьте по моей статье. Я помню, что в доке на 972 об этом было криво написано!
А, кстати, есть KS8842 и KS8695. Может они Вам лучше подойдут?
Удачи!

Спасибо за ответ, а чем в 2-х словах, отличается KS8842, KS8695 и KS8792 от Интела?

Не KS8792, а KS8721 - это я ошибся. Он имеет режим переключения входов прямой - перекрестный. Все кабели становятся одинаковыми. Можно включать в хаб или напрямую - они сами разбирутся. Ему на смену скоро станем поставлять pin-to-pin KS8001. А он еще умеет проверять импеданс линии связи. И если импеданс уполз или кз или обрыв, то можно получить эту информацию. Есть много типов корпусов. Индустриальные темп.
KS8842 - двухканальный контроллер - коммутатор. 41 - одноканальный.
Где-то здесь я уже выкладывал сравнительные характеристики.
KS8695 - ARM922 ядро + 4+1 коммутатор пакетов + PCI(до 3-х шин) и линукс
Если есть вопросы - пишите.
Удачи!

использовал 972 проблем не было попробуйте замкнуть вход
на выход внутри чипа раздел 5.6.7 Loopback, page 42 Document number 302875-004
и еще держитесь подалше от Micrel у них большие проблемы с поставками
и AVNET не рекомендует их использование к тому же интел дешевле

удачи

А линк 972-ая поднимает?
Как параметры линк устанавливаете - принудительно или Autonegotiation?
Если линк в автонегошиэйш (после сброса по умолчанию один из светодиодов 972-ой индицирует наличие линка, ну или битик в регистре статуса глянуть) есть - то 95% где-то баг в посылаемых данных - неверный формат хидера или CRC.
А чем посылаете? У меня был Intel IXP420-ый - геморрой с его NPE еще тот был :-(

да поднимает, устанавливаю автонигшиайшен, посылал Cold FIre, POwer PC ни каких проблем или нареканий

Теперь вопрос возник по CRC32 (FCS).

Использовал генератор исходников CRC - CRCTool (http://www.easics.com/webtools/crctool) но до сих пор не получил CRC, совпадающий с правильным (правильный - беру из принятого пакета).

В доке IEEE 802.3-2002 по поводу расчета CRC сказано следующее:

A cyclic redundancy check (CRC) is used by the transmit and receive algorithms to generate a CRC value
for the FCS field. The frame check sequence (FCS) field contains a 4-octet (32-bit) cyclic redundancy check
(CRC) value. This value is computed as a function of the contents of the source address, destination address,
length, LLC data and pad (that is, all fields except the preamble, SFD, FCS, and extension). The encoding is
defined by the following generating polynomial.
G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
Mathematically, the CRC value corresponding to a given frame is defined by the following procedure:
a) The first 32 bits of the frame are complemented.
b) The n bits of the frame are then considered to be the coefficients of a polynomial M(x) of degree n–1.
(The first bit of the Destination Address field corresponds to the x(n–1) term and the last bit of the
data field corresponds to the x0 term.)
c) M(x) is multiplied by x32 and divided by G(x), producing a remainder R(x) of degree ≤31.
d) The coefficients of R(x) are considered to be a 32-bit sequence.
e) The bit sequence is complemented and the result is the CRC.
The 32 bits of the CRC value are placed in the frame check sequence field so that the x31 term is the leftmost
bit of the first octet, and the x0 term is the right most bit of the last octet. (The bits of the CRC are thus
transmitted in the order x31, x30,…, x1, x0.) See reference [B37].


Что это за пункт такой -
a) The first 32 bits of the frame are complemented

Дополнение..., инверсия бит или еще что? Может в этом проблема?

Все, проблема решена. Кому еще понадобится - обращайтесь