Ситуация такая есть процессор, который через GMII подключен к ПЛИС. ПЛИС к внешнему миру подключена через SGMII. Проц с внешним миром общается через ПЛИС.
Нужно организовать доступ на чтение/запись к регистрам ПЛИС, а так же предавать приходящие пакеты на различные модули обработки в ПЛИС. Мак и IP-уровни используются для доступа к ПЛИС и CPU. ПЛИС- Cyclone 4 GX.

Первое о чем подумал: После IP-заголовка выделить поле под свой заголовок и у же нему все разруливать.

Может быть есть другой способ?
Был бы очень признателен если кто-нибудь подсказал как лучше это дело организовать.

Конечным пунктом приходящих извне IP-пакеты является CPU? Или FPGA? Или и то и другое?
А пакеты на передачу формируются только в CPU или нет?

И то и другое являются конечными пунктами. К CPU обращение по IP-адресу, к ПЛИС по Мак-адресу.

Пакеты будут формироваться и в CPU и в ПЛИС. CPU пакеты будет формировать периодически. Основную работу будет делать ПЛИС. ПЛИС принимает пакет от внешнего мира, сравнивает Маки, если совпадают, то проверяет IP-адрес, если IP-адрес = IP-адресу CPU, то пакет передается процу, если IP-адрес не равен IP-адресу CPU, то отдает на внутренние модули. Причем нужно как-то определить по какому признаку нужно отдавать на тот или иной модуль. После обработки пакет возвращается во внешний мир.

При этом с CPU могут лететь пакеты как во внешний мир, так и для контроля/управления ПЛИС-ой.

Т.е. в ПЛИС 3 итерфейса: 1 GMII для связи с CPU и 2 SGMII для связи с внешним миром.

А в CPU формирование пакетов как происходит? Все вручную?

Не совсем понимаю, что такое формировать в ручную.
Изначально предполагалось, что на CPU будет жить Линукс.

Имелось в виду - насколько низко по протоколам у Вас есть доступ к формирование пакетов.


Просто, если другого интерфейса между FPGA и CPU нет - то, естественно, придется чтение/записть регистров делать через GMII.

Но вот формировать настойщий IP-пакет для этого - излишество, только лишний оверхед. Если есть доступ к GMII непосредственно, то я бы лучше сделал для команд от CPU к FPGA другой формат, отличный от Ethernet-кадра. Но или, хотя бы, не использовал IP-уровень.

Если же такой возможности нет, то тогда вставить какую-либо метку поверх IP (или, например, в поле Protocol указывать неиспользуемое значение), наверное, единственный вариант.

Другими словами, Вы реализовали в ПЛИС обычный Ethernet Switch? Да, согласен с des333, тут вопрос: вы использовали готовые корки MAC подуровня или писали всё сами с нуля? Если второе, то влезть в структуру пакета вполне возможно так, как Вы задумывали в первом сообщении. Можно и другими способами. Но если MAC готовый - то всё сложнее.

ПЛИС может общаться с внешним миром и CPU посредством UDP пакетов. Во первых, это сильно упрощает жизнь как CPU так и внешнему миру - не надо никаких вмешательств в TCP/IP стек. А во вторых, это не сильно накладно для самой ПЛИС - UDP пакет довольно простой и отсутствуют какие либо протоколы вокруг него, т.е. достаточно уметь принять/отправить один Ethernet кадр (с IP/UDP уровнями).

NB. При такой схеме фрагментация UDP конечно не поддерживается.

Мак свой, т.к. делаю не совсем обычный свич.


К сожалению не может, основная работа с ip-пакетами. Нужно из ip-пакета извлечь данные, отдать их на один из модулей обработки, затем снова собрать пакет и отдать в сеть. Либо принять пакет, проанализировать ip-заголовок и отдать пакет на CPU без всякой обработки.


Понял, в CPU ip-уровень для внешнего мира, для общения с ПЛИС думаю можно и любой другой уровень использовать.


Тогда, наверное, лучше теги VLAN использовать для работы с ПЛИС.

Так UDP это тоже IP пакет
Принимаете пакет, смотрите формат - если UDP и ваш (т.е. ПЛИСины) адрес (IP+Порт), то тело пакета отправляете на обработку внутрь ПЛИСины. Если нет, то отправляете пакет дальше (в CPU или внешний мир)
Пакеты с ответами формируются аналогично.

Или у вас ПЛИС занимается фильтрацией всех пакетов на IP уровне?

все пакеты на ip-уровне.