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

у меня ситуация несколько другая. сделал пару иллюстраций.
итак, сначала на массив накладывает вот такая структура
eth_frame_t *frame = (void*) packet;

далее, на поле alt_u8 data[] накладывается новая структура ARP сообщения arp_message
arp_message_t *msg = (void*)(frame->data);
что должно быть и что получается я проиллюстрировал на рисунке


видно, что появляется сдвижка при наложении 32 битного числа, со всеми остальными типами все в порядке
может кто-нибудь подкинет идею почему так происходит?

а, понял. это из-за 6-байтного MAC-адреса. попробуйте объявить структуру с атрибутом packed

большое спасибо, все получилось

Подскажите пожалуйста - каким образом работает
Command_Config PROMIS_EN.
(Promiscuous enable. Set this bit to 1 to enable promiscuous mode. In this mode, the MAC function receives all frames
without address filtering.)
Если бит PROMIS_EN = 0, то мак не видит пакеты, которые начинаются с нуля (B0-LSB = 0), почему?

потому что не должен. в нормальном режиме MAC "видит" только пакеты с его адресом и broadcast'ы. в promiscuous "видит" все пакеты.

Насколькл я понял, при PROMIS_EN = 0, видит пакеты в которых младший бит destination MAC address = 1 и не видит те, в которых 0. Потом нашёл уже описание у Альтеры:

The MAC function can accept frames with the following address types:
■ Unicast address—bit 0 of the destination address is 0.
■ Multicast address—bit 0 of the destination address is 1.
■ Broadcast address—all 48 bits of the destination address are 1.
The MAC function always accepts broadcast frames. If promiscuous mode is enabled
(PROMIS_EN bit in the command_config register = 1), the MAC function omits
address filtering and accepts all unicast frames.

Ломал голову, думал что-то с времянкой, когда пакет с нуля начинается.




Ещё есть вопросик по осцилограммам rgmii: есть две платы, на одной - Marvell 88E1111, на другой Micrel KSZ9021RL, сигналы RX_CTL отличаются, хотя при этом всё работает нормально, MAC принимает-передаёт пакеты.

на дребезг похоже, как смотрели? резистор согласующий стоит?

резистор не стоит, но и в документации насчёт этого пока ничего не нашёл.

а насколько часто такие различия повторяются? если это не дребезг, то картинка от марвела показывает на наличие RX_ER

вот это-то и не понятно, RX_CTL у марвела такой всегда. Есть две платы с марвелом, одна - с Stratix 2 (marvell подключён напрямую к fpga), на второй просто marvell, через переходник подключается к tms320c6455 (надо на нём гигабит запустить), на обоих RX_CTL одинаковый, как на рисунке. Приём-передача на nios ii, работает нормально, но в процессе отладки была замечена данная "особенность" marvella, при подключении к тому же tse mac nios ii платы с phy micrel, RX_CTL нормальный и данные тоже принимаются. Так вот и вопрос - так надо, или всётаки что-то не так?

И если ошибка - каким образом тогда пакет принимается правильный?

не знаю, м.б. у марвела кодирование RX_ER настраивается? (стандарт менялся, но давно)

Господа, собирал ли кто-нибудь демку с веб-сервером?
Сколько памяти занимает футпринт и сколько ОЗУ требуется для выполнения?
Реально ли затолкать веб сервер в ончип мемори для например циклона 3 EP3C10?

я собирал, только не помню какую. что-то килобайт около 200 весила. скорее всего не влезет, надо внешнюю ставить

Жалко, на внешнюю лапок нету совсем, а на бга переходить не хочется..

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

посмотрите в сторону LwIP, порт для ниоса был на alteraforums.com (или на alterawiki). потом еще нужен драйвер TSE. это основные компоненты

вот пример http://www.alteraforum.com/forum/showthrea...93638#post93638