Непонимание работы ядра Ethernet, c opencores, поясните пжл. Опции

[alexPec]

Сконфигурировал ядро (то, которое с авалон-мм) для работы с одним дескриптором на передачу и одним на прием. Ставлю брейкпоинт на обработку прерывания по приему. Посылаю пинг с компа. Срабатывает брейк, жду. Проходят 4 пинга, при этом программа висит на брейке. Дальше нажимаю run - и тут же выскакивает (после обработки первого пинга) брейк от второго (затем от 3-го и 4-го), а пинги то уже прошли!

Вопросы такие, поясните кто с этим дело имел:

1. Один дескриптор обрабатывает 1 фрейм эзернета или несколько?
2. Почему срабатывают прерывания по приему, когда пинги уже прошли? И именно столько раз, сколько было пингов?
3. Если дескриптор обрабатывает 1 фрейм - непонятно, где копятся остальные пинги пока программа висит в брейке?
4. Если дескриптор обрабатывает скольугодно фреймов (пишет все что приходит с эзернета подряд) - как ограничить железяке место, куда она может писать? Ато ведь кончится отведенное ей место - залезет на область данных или программы и будет ситуация ж..па.

PS даже если 4. верно, непонятно почему срабатывают прерывания после того как пинги прошли.

Буду рад любым пояснениям.

[vadimuzzz]

хм, хороший вопрос! в документации на корку говорится, что для предотвращения переполнения fifo используется флаг almost_full (конфигурируется через соответствующий регистр). если во время приема фрейма обнаружится, что пакет в буфер не влезает (т.е. сработал флаг almost_full), то фрейм обрезается и его дескриптор соответствующим образом помечается. в статусе дескриптора принятого пакета за переполнение отвечает третий бит

Truncated receive frame. Asserted when the receive frame is truncated due to an overflow in the receive FIFO buffer.

а вот что происходит дальше - непонятно, в доках об этом не говорится. сброс корки, пожалуй, самое правильное решение. но я бы посмотрел в сигналтапе сигналы fifo (можно синзронизироваться по almost_full) и как себя ведет корка. есть еще вариант, что неверно настроен регистр rx_almost_full. PAUSE-фреймы тоже нормальный вариант.

[alexPec]

хм, хороший вопрос! в документации на корку говорится, что для предотвращения переполнения fifo используется флаг almost_full (конфигурируется через соответствующий регистр). если во время приема фрейма обнаружится, что пакет в буфер не влезает (т.е. сработал флаг almost_full), то фрейм обрезается и его дескриптор соответствующим образом помечается. в статусе дескриптора принятого пакета за переполнение отвечает третий бит

а вот что происходит дальше - непонятно, в доках об этом не говорится. сброс корки, пожалуй, самое правильное решение. но я бы посмотрел в сигналтапе сигналы fifo (можно синзронизироваться по almost_full) и как себя ведет корка. есть еще вариант, что неверно настроен регистр rx_almost_full. PAUSE-фреймы тоже нормальный вариант.

Спасибо, поле деятельности есть. Буду пробовать.