? по альтеровскому блоку Triple Speed Ethernet, Касательно поддержки Jumbo кадров Опции

[Koluchiy]

Здравствуйте, уважаемые гуру.

Разбираюсь тут с альтеровским IP-блоком "Triple Speed Ethernet".

Ну, в симуляторе он в общем работает, на маленьких длиннах кадров...
А надо, чтобы работал на больших(до 12КБайт), и не в симуляторе, а в железе...

Ну так вот.
Юзаю я Quartus 9.1.

Открываю я описание этого IP-блока к версии 9.1, то вижу в нем только 2 ограничения на длину кадра:
-----------------------------
- Programmable maximum frame length up to 64 Kbytes, including jumbo frames.
...
- Configurations with PCS and embedded PMA can only support frame lengths longer
than 16 Kbytes if the difference between the input reference clock and recovered clock
is zero ppm.
-----------------------------

Ну то есть, 12К должно работать во всех вариациях.

Открываю я описание того же самого IP-блока к версии 11.0.
И в нем немного по-другому:
-----------------------------
- Frame length—in MAC only variation, up to 64 Kbytes including jumbo
frames. In all variants containing 1000BASE-X/SGMII PCS, the frame length is
up to 10 Kbytes.
...
- Configurations with PCS and embedded PMA can only support frame lengths longer
than 16 Kbytes if the difference between the input reference clock and recovered clock
is zero ppm.
-----------------------------

Ну то есть, в описании к версии 9.1 всё вроде бы непротиворечиво.
А к 11.0 в одном месте написано, что если использовать PCS, то только до 10К.
А в другом написано, что при определенных условиях можно и >16K.

Вот и думаю я, как так может получиться.
При переходе на версию 11 убрали поддержку больших фреймов?
Или поймали баг, и вместо того, чтобы править, ограничили поддержку длинных кадров в даташите.

Кто-нибудь юзал это дело?
Чего там вообще на самом деле, работает, нет?

Всем заранее спасибо за ответы.

[almost_valid]

Что то мне подсказывает что тут дело в основном в договоренностях с производителями PHY чипов. Какая разница какую длину закодировать 10к, 16к или 64к?

[Koluchiy]

Вот и мне интересно.
PHY-чипа нету - всё передается через GXB, SFP и оптику.

Что касается
- Configurations with PCS and embedded PMA can only support frame lengths longer
than 16 Kbytes if the difference between the input reference clock and recovered clock
is zero ppm

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

[almost_valid]

Вот и мне интересно.
PHY-чипа нету - всё передается через GXB, SFP и оптику.

Что касается
- Configurations with PCS and embedded PMA can only support frame lengths longer
than 16 Kbytes if the difference between the input reference clock and recovered clock
is zero ppm

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

Требование к когерентности, не кисло.
P.S. Опробовал ядро, все так вкусно и на тарелочке, и тест бенч тебе готовый и авалон стандартный. Правда я без PCS и PMA.

[almost_valid]

Чтобы не плодить темы, спрошу здесь:
Не могу понять почему на передачу, в тестбенче, тактовый сигнал сдвинут на 90 градусов по фазе относительно всего остального? Так ли это надо делать и для чего?

[Koluchiy]

Я бы настоятельно посоветовал плодить темы...

==================================

Чем дальше в лес, тем интереснее.
В описании на IP-Блок написано:

-----------------------------------------------------------------------------------------
If the length/type field represents the frame type, the MAC function validates the
type and duly processes each type. Frames with invalid types are discarded.
-----------------------------------------------------------------------------------------

Ну то есть, в моем понимании, это означает, что если передавать/принимать фреймы с типом, отличным от перечисленных в даташите, то MAC их передавать не будет.
Тем не менее, при попытке передавать фреймы со всякими типами типа 0x801, 0xABAC и т.п., фреймы прекрасно передаются.
Кто-нибудь может помочь в понимании происходящего?

[almost]

Я бы настоятельно посоветовал плодить темы...

Сорри.