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

Было решено реализовать МАК-контроллер гигабитного эзернета на матрице логики в виду того, что согласно ТЗ плата д.б. работать на температуре от -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) и пр.

Удачи всем.