88E1111 MAC Loopback, GMII, непонятности с настройкой Опции

[dxp]

Всем привет!

Есть плата с PHY Marvell 88E1111 и FPGA Cyclone IVE, в последней реализуется уровень МАС, связь между ПЛИС и трансивером осуществляется посредством GMII. Для проверки целостности аппаратных интерфейсов используется включение петель. Auto-Negotiation проходит, вроде, успешно, Loopback в сторону линии (хоста) работает.

Столкнулся с проблемой при включении loopback со стороны MAC уровня. Этот режим включается битом 0.14, читаю регистр 0, там значение 0x1140, что означает:

Auto-Negotiation: Enable
Copper Duplex Mode: Full-duplex
Speed Selection: 10 = 1000 Mbps

Вроде, всё чинно, скорость правильная (и флаг в статусном регистре тоже соответствует ей), остаётся только включить loopback. Если включить 14-й бит, то значение регистра должно быть: 0x5140. Прописываю это значение, сразу заметно изменение - трансивер, как и положено, теряет линк и энергопотребление заметно снижается. Теперь передаю тестовый паттерн, ожидая его возврата. И вот тут-то возникает затык: от трансивера ничего не приходит. Далее долгий и безрезультатный поиск нюансов (вдруг что-то забыл включить или какой-то важный момент упущен), но нет, вроде, просто всё - включаешь один бит и всё должно работать, если скорость установлена правильно (а она, вроде, правильно - при включенном режиме Auto-Negotiation биты 20.6:4 в 110).

Уже перепробовав всё что можно, почти случайно прописал в регистр 0 значение 0x6140, и, о чудо, loopback заработал. Эксперименты показали, что работает именно 6 в старшей тетраде, остальные биты на работоспособность данного режима не влияют. И вот всё это повергает в недоумение.

По факту получается, что эта 6 означает:

Loopback: Enable
Speed Selection (LSB): 1
Auto-Negotiation: Disable

Пробовал варианты 0x4 и 0x7 в старшую тетраду, оба не работают. В общем, не ясны два момента:

1. Как и почему влияют "левые" биты на работоспособность loopback?
2. Прописывание значений в указанные биты, согласно документации, не приводит к активации связанной с ними функциональности - для того, чтобы они повлияли нужно либо произвести Software Reset, либо войти и выйти в Power Down, ничего этого не делается, так почему же это влияет?

В общем, кто в курсе вопроса, просветите, пожалуйста?

[krux]

сделайте хотя-бы "fast output register" на выводах, и про вывод тактового сигнала через ALTDDIO подумайте

и вообще про source-synchronous interface почитайте

[dxp]

сделайте хотя-бы "fast output register" на выводах, и про вывод тактового сигнала через ALTDDIO подумайте

и вообще про source-synchronous interface почитайте

Докладываю. Все сигналы наружу, кроме GTX_CLK, размещены в выходных триггерах I/O элементов, GTX_CLK выведен через упомянутую вами ATLDDIO_OUTPUT со сдвигом в полпериода (4 нс). Входной клок RX_CLK заведён на dedicated CLK pin ПЛИС, с него на отдельную PLL, включенную в souce-synchronous compensation mode, с которой берётся клок для тактирования приёмной части. Все входные сигналы (кроме входного клока, разумеется) защёлкиваются во входных триггерах I/O элеменов по вышеупомянутому клоку. Все сигналы обконстрейнены в TimeQuest'е,

Всё это тщательно контролировалось разными способами, начиная от анализа предупреждений синтезатора и просмотром размещения через ChipPlanner, и заканчивая наблюдением выходных сигналов, в частности, TX_EN относительно GTX_CLK, хорошим осциллографом на плате, там всё хорошо.

Что-то вы уж совсем меня за безграмотного лоха держите. Либо невнимательно читали стартовый пост - там описана проблема совсем иного рода, нежели та, которая могла бы возникнуть из-за неграмотного проектирования приёмо-передающей логики внутри ПЛИС.