ADC -> FPGA -> Ethernet Опции

[doom13]

Имеется: ADC (100 МГц, 4 канала), FPGA, Ethrnet PHY. Необходимо осуществить приём данных от АЦП и передачу их по Ethernet.
Для приёма-передачи по Ethernet используется Nios + SgDMA_MEMtoST + SgDMA_STtoMEM + TSE. Вопрос - каким образом лучше организовать приём данных с АЦП с максимальной скоростью и передать их по Ethernet. Видится вариант решения задачи следующим образом:
1. Создать собственный модуль для приёма данных с АЦП и их преобразования в Avolon ST (ADC_to_AvalonST)
2. Далее забираем данные с помощью SgDMA Stream->Memory (SgDMA_STtoMEM) и записываем в память
3. При помощи SgDMA Memory->Stream (SgDMA_MEMtoST) передаём данные из памяти на TSE

ADC_to_AvalonST => SgDMA_STtoMEM => Memory => SgDMA_MEMtoST => TSE

[vadimuzzz]

несколько соображений по теме.
во-первых нужен компонент, который будет складывать данные с АЦП в некоторый буфер. буфер желательно побольше, чтобы payload максимизировать. во-вторых нужен некий планировщик (скорее всего в составе первого компонента), который будет распределять память между каналами. а вот дальше надо определиться, сливать данные большими пачками, либо изобразить некий риалтайм (с соотв. понижением частот АЦП). почему имеет смысл использовать udp_tx_offload: он позволяет располагать в памяти данные для передачи в "сыром" виде, без заголовков и прочей шелухи. причем непрерывным куском в памяти. фактически, дескриптор для этого компонента - это указатель + длина пакета, причем пишется через регистры. копирование из памяти в память процессором (а именно это и происходит в основном при формировании заголовков) - это одно из узких мест ниоса. т.о. при использовании аппаратного ускорения задача сведется к передаче буфера по его заполнении (вариант с передачей большими пачками), либо по прерыванию от компонента-планировщика (если выберете вариант с риалтаймом). на правах ИМХО

вдогонку: при использовании udp_tx_offload можно оставить программную реализацию протоколов, потом всегда можно переделать.

[doom13]

несколько соображений по теме.
во-первых нужен компонент, который будет складывать данные с АЦП в некоторый буфер. буфер желательно побольше, чтобы payload максимизировать. во-вторых нужен некий планировщик (скорее всего в составе первого компонента), который будет распределять память между каналами. а вот дальше надо определиться, сливать данные большими пачками, либо изобразить некий риалтайм (с соотв. понижением частот АЦП). почему имеет смысл использовать udp_tx_offload: он позволяет располагать в памяти данные для передачи в "сыром" виде, без заголовков и прочей шелухи. причем непрерывным куском в памяти. фактически, дескриптор для этого компонента - это указатель + длина пакета, причем пишется через регистры. копирование из памяти в память процессором (а именно это и происходит в основном при формировании заголовков) - это одно из узких мест ниоса. т.о. при использовании аппаратного ускорения задача сведется к передаче буфера по его заполнении (вариант с передачей большими пачками), либо по прерыванию от компонента-планировщика (если выберете вариант с риалтаймом). на правах ИМХО

вдогонку: при использовании udp_tx_offload можно оставить программную реализацию протоколов, потом всегда можно переделать.

Почитал ещё форум Gigabit Ethernet IP, где Вы даёте ссылку, и, как понимаю, систему необходимо строить таким образом (второй вариант):

Просто когда смотрел Ваш проект, на который указал Konst_777, понял, что у Вас udp_tx_offload используется именно для формирования на железе отправляемых пакетов (может что-то не досмотрел), вроде как у Вас через него должен был прогоняться поток от ASI. Хочу пока оставить уже работающую реализацию ARP, ICMP на программном уровне и получается для TSE необходимо реализовать переключение потоков от Niosa и от железного ускорителя UDP. UDP ускоритель формирует заголовки для пакетов UDP и соединяет заголовок с потоком (буфером) данных, далее всё выдаёт на TSE.

Ещё, если можно, вопрос: для первого варианта решения, если какой-то компонент будет выдавать данные в формате ST Avalon на SgDMA ST to Memory, далее другой SgDMA Memory to ST запихивать их в TSE, что в этом случае будет грузить сам процессор, его задача сводится к составлению списка дескрипторов их обработке, копирование памяти осуществляет SgDMA, который, насколько я понимаю, работает независимо от Nios? Почему данный вариант плох и нереализуем?

[vadimuzzz]

Почитал ещё форум Gigabit Ethernet IP, где Вы даёте ссылку, и, как понимаю, систему необходимо строить таким образом (второй вариант):

та схема просто для иллюстрации, из нее достаточно блока INS. просто в исходном виде тот компонент требует обвязки (мультиплексор, адаптер). поэтому я его слегка модифицировал (см. приложение), чтобы лишних движений поменьше было. теперь его достаточно воткнуть в разрыв tx_sgdma -> tse, а использовать его фичи или нет - дело уже программиста.

Просто когда смотрел Ваш проект, на который указал Konst_777, понял, что у Вас udp_tx_offload используется именно для формирования на железе отправляемых пакетов (может что-то не досмотрел), вроде как у Вас через него должен был прогоняться поток от ASI. Хочу пока оставить уже работающую реализацию ARP, ICMP на программном уровне и получается для TSE необходимо реализовать переключение потоков от Niosa и от железного ускорителя UDP. UDP ускоритель формирует заголовки для пакетов UDP и соединяет заголовок с потоком (буфером) данных, далее всё выдаёт на TSE.

udp_tx_offload формирует только заголовки. если заголовки делать программно, это будет одним из узких мест. как уже писали при подключении нескольких мастеров к одному контроллеру памяти скорость неизбежно упадет и программных операций mem_to_mem в критичных по скорости местах следует избегать. в принципе, есть вариант располагать буферы в памяти с разрывами, а заголовки формировать заранее, но это усложнит логику компонента, который пишет данные с АЦП

Ещё, если можно, вопрос: для первого варианта решения, если какой-то компонент будет выдавать данные в формате ST Avalon на SgDMA ST to Memory, далее другой SgDMA Memory to ST запихивать их в TSE, что в этом случае будет грузить сам процессор, его задача сводится к составлению списка дескрипторов их обработке, копирование памяти осуществляет SgDMA, который, насколько я понимаю, работает независимо от Nios? Почему данный вариант плох и нереализуем?

драйвер TSE не поддерживает цепочки дескрипторов

[doom13]

udp_tx_offload формирует только заголовки. если заголовки делать программно, это будет одним из узких мест. как уже писали при подключении нескольких мастеров к одному контроллеру памяти скорость неизбежно упадет и программных операций mem_to_mem в критичных по скорости местах следует избегать. в принципе, есть вариант располагать буферы в памяти с разрывами, а заголовки формировать заранее, но это усложнит логику компонента, который пишет данные с АЦП

Поясните пожалуйста, правильно ли всё понимаю:
1. Под программным формированием заголовка понимается то, что в область памяти необходимо положить сам заголовок и последовательно сформированные данные (две операции копирования памяти, или, как минимум, одна, если заголовок сформировали заранее)?
2. Для ядра udp_tx_offload с помощью Avalon MM записываем необходимую шапку пакета, на вход Avalon ST Snk подаём поток (пакет) данных для передачи, но этот пакет поступает от SgDMA Memory To Stream, которое должно прочитать какой-то кусок памяти (в Вашем случае - SDRAM). Программа Nios также исполняется из SDRAM. Это ведь тоже накладывает определённые ограничения по скорости, два мастера будут обращаться к одному слейву. Или это не столь критично, в отличие от п.1?
3. Если данные в udp_tx_offload запихивать с помощью железного модуля с выходом Avalon ST Src (что-то типа prbs_packet_generator->udp_payload_inserter->tse), то можно получить скорость передачи выше, чем для п.2?
4. Реализация п.2, когда какой-то поток данных (в моём случае от АЦП) записывается в память (SDRAM, данные хранятся и будут передаваться, скажем, по N-байт), считывается из памяти при помощи SgDMA, далее всё загоняется на udp_tx_offload и TSE, сможет обеспечить скорость передачи порядка 600 Мбит/с? Не возникнет ли конфликт записи-чтения SDRAM со стороны SgDMA, Nios (программа исполняется из SDRAM), модуля приёма-записи в память данных от АЦП (нужно будет делить время обращения к памяти)?
5. Ну и самый важный вопрос, что выбираем:

5.1 Железный блок упаковывает данные от АЦП и формате Avalon ST выдаёт на udp_payload_inserter, далее мультиплексор и TSE (можно выжать максимальную скорость).
5.2 Железный блок упаковывает данные от АЦП и кладёт в память (как мне кажется SDRAM не подойдёт, будет накладывать ограничения по скорости, т.е. нужна полностью независимая память к которой будет иметь доступ только упаковщик(на запись) и SgDMA (на чтение)), SgDMA считывает и выдаёт на udp_tx_offload, далее TSE (тут получаем если SgDMA при чтении не делит данную память с др. устройствами, то и ограничения, связанные с доступом к памяти, снимаются, остаётся только вопрос - хватит ли памяти на чипе).