Имеется: 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

Пусть данные АЦП 8-битные.
Тогда: 100МГц х 4канала х 8 = 3,2 ГБит/сек.
Нет-ли ошибки?
Или передаются накопленные за ограниченный период данные?

И какую же скорость передачи нужно обеспечить? И что будет принимать такой поток?


Лучше так: ADC_to_AvalonST => udp_tx_offload => TSE. Это упрощенная схема, более полная выглядит так:

Компонент "udp_tx_offload" находится в папке "IP" проекта "sdr400cpu_ng". vadimuzzz, автор проекта, выложил его в этой теме.

На данном этапе это не принципиально, будут ещё DDC-конверторы стоять, задача запихнуть данные в TSE которым рулит Nios, чтобы не сильно грузить процессор при использовании максимально возможной частоты АЦП.



Скорость до 1Gb/s, передаваться будут не все данные, пока расчёт идёт на максимально возможную скорость.



Спасибо, буду пробовать.

Все-таки, Ваш вариант решения надежнее.

Здравствуйте. Посмотрел проект и ip-core udp_tx_offload от автора vadimuzzz. Прикрутил по-быстрому к своему проекту, что-то заработало, данные передаются, но со всеми особенностями udp_tx_offload пока не разбирался. Насколько понимаю - непосредственно udp_tx_offload - немного не то, что имелось в виду. Фактически udp_tx_offload - реализация UDP на уровне железа. В моём случае UDP, ARP, ICMP уже реализованы на программном уровне, возможно, тут есть свои преимущества, но пока вопрос не в этом.
Ethernet уже есть, вопрос - каким образом прокачать максимально возможный поток данных от источника (в моём случае АЦП) извне SOPC-системы, чтобы не сильно грузить Nios, и чтобы оставалиль рабочими UDP, ARP, ICMP.
Ваш вариант с использованием Avalon-ST Multiplexer видится приемлемым, но пока не использовал данное ядро. Как понимаю, Nios должен будет выбирать - какой поток выдать на TSE (либо например ответ на ARP запрос, который формируется софтом, либо udp-пакет с данными от АЦП, который формируется на уровне железа). При использовании второго варианта видятся сложности с длинной udp пакета (может это и не так).

Варианты реализации:
Нажмите для просмотра прикрепленного файла

Если можно, то ответьте на мой вопрос: зачем Вам в данном случае нужна именно ПЛИС? Ведь задача получения данных от АЦП вполне тривиальна и ДМА есть в любом микроконтроллере. Стык с Ethrnet - гигабитный МАС - тоже не проблема. А уж обработка данных для Ethrnet в быстром процессоре всяко будет быстрее и дешевле, чем в ПЛИС...
Так зачем же идти по дорогому и трудному пути?

Если я правильно Вас понимаю, Вы имели в виду использование FPGA + DSP. FPGA принимает данные от АЦП, далее процессор выплёвывает их в Ethernet (АЦП –100 МГц, 4 канала, 16 бит, DDR LVDS интерфейс по 2 линии на канал, общий frame clock и bit clock). Но на плате не предусматривается использование DSP. Вообще разрабатывается прототип платы с 4-мя такими АЦП, и, при использовании максимально возможной частоты АЦП, Ethernet не сможет прокачать такой поток данных:

16 * 4 * 4 * 50MHz = 12.8 Gb/s

Предусматриваются ещё оптоволоконные трансиверы для использования АЦП на максимальной частоте.
Ethernet ставится с целью возможности замены старой системы с расчётом на максимальный поток данных:

16 * 4 * 4 * 1,28 MHz = 327.68 Mb/s

Или

(16 * 2) * 4 * 4 * 1.28 MHz = 655.36 Mb/s (комплексные данные)

..на каком микроконтроллере 1G не проблема ?

Тексосовские DSP или фрискейловские imx

Это у которых в ерате указано про ограничение в 400 Мбит/с?

Пока мне этого будет достаточно. Вопрос каким образом проще и правильнее запихнуть данные в TSE, которым управляет NIOS. Пока попробовал использовать Avalon ST multiplexer, чтобы разобраться с предложенным Konst_777 способом решения моей задачи. Передача пошла, но только с одного входа (in0) Avalon ST multiplexer. На один вход mux подаётся TSE RX (получился своеобразный loopback), на другой - SgDMA Memory to Stream. В итоге работает передача только от одного источника, если их поменять местами - то начинает работать от другого.

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

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

Все таки, какой тип задачи Вы решаете:

1. Регистрация данных с последующей их обработкой в нереальном времени.
2. Обработка данных в реальном времени.

Анализируя эту тему можно предположить, что Ваш проект относится к типу 2. Но, может быть, Вы пытаетесь решать задачу 1, как задачу 2? В этом случае, скорее всего, Вы совершаете ошибку.


Как Вам уже объяснил vadimuzzz, программное формирование UDP пакетов с данными АЦП не позволит получить скорость обмена 40 Мбайт/сек. В то время как аппаратное способно обеспечить и 100 Мбайт/сек. Другой вопрос, что будет принимать такой поток и сумеет ли оно его обработать.


Поскольку vadimuzzz сейчас посещает этот форум, то вместо фразы "проект в студию!" рекомендую Вам пригласить Вадима для участия в Вашем проекте. Это позволит Вам сэкономить деньги и время, обеспечить высокое качество и сохранить приватность Вашей разработки.

Обработка данных в реальном времени. Пока плата с ацп ещё только разрабатывается. До момента её появления нужно поднять Ethernet. Как и говорил, ARP, ICMP, UDP счас реализованы на Nios программно. Возник вопрос, что будет и как быть при большом потоке данных.



Данные будет принимать комп (пока).



Как понимаю, нужно останавливаться на втором варианте:
Нажмите для просмотра прикрепленного файла

Почитал ещё форум 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? Почему данный вариант плох и нереализуем?

Этот вариант неплох и реализуем. Скорость обмена будет зависеть от процессора Nios II. Попробуйте.
Только, Вам еще нужно добавить SgDMA_Memory_to_Memory. А лучше, заменить ADC_to_AvalonST на ADC_to_AvalonMM и вместо SgDMA_ST_to_Memory использовать SgDMA_Memory_to_Memory. Если скорость обмена окажется низкой, то потребуется разработать сопроцессор дескрипторов для SgDMA_Memory_to_Memory.

Затестил два варианта работы. Пока для проверки использовал prbs_packet_generator и udp_payload_inserter из примера. Для первого варианта - один генератор загрузил сеть примерно на 23% 230 Mb/s, для второго - 1 генератор загрузил сеть на 27% 273 Mb/s, 4 генератора на пакетах 1024 байт показали скорость 384 Mb/s, но как-то плохо стал работать ethernet_packet_multiplexer и ping перестал проходить. Оставил два генератора с длинной пакета 1450 - получил загрузку сети 57-60% 558Mb/s и ARP запрос-ответ работает.

Возник вопрос по поводу DMA (SgDMA), что будет происходить если программа исполняется из sdram, в sdram созданы буферы для данных, и сказать DMA скопировать данные из одной области sdram в другую? Для работы DMA необходима своя шина, которая вроде бы и показывается в Qsys, если добавить в систему блок DMA, но память sdram - однопортовая.

обычно контроллер памяти многопортовый.

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

и еще надо помнить про кеши. То есть те сегменты что обслуживаются ДМА, должны учитывать что в кеше другие данные...

Если обычно контроллер памяти многопортовый, то получается что к памяти одновременно могут обращаться несколько устройств и что тогда есть dual-port access memory. Что значит "ДМА будет под себя забирать часть шины, деля ее с другими устройствами" - одновременно к памяти будет иметь доступ одно устройство: либо ДМА, либо Ниос? Т.е. получается, для независимой работы Дма память должна быть dual-port access?

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

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

Спасибо, счас всё понятно, мне казалось что у ДМА должна быть своя полностью независимая шина.

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

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

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

Поясните пожалуйста, правильно ли всё понимаю:
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 при чтении не делит данную память с др. устройствами, то и ограничения, связанные с доступом к памяти, снимаются, остаётся только вопрос - хватит ли памяти на чипе).

Многие, для таких задач, ставят по 2 независимых контроллера памяти (SDR, DDR, on-chip и.т.д. ). Ну и 3й для Nios можно, если есть другие дела. В один блок памяти данные накапливаются с другого отправляются, ну а потом наоборот.

Програма из ДДР и данные в ДДР - конечно это все притормозит. Но на этот случай в процах придумали кэш данных и инструкций. Теоритически 90% времени если не больше программа выполняется по закешированным частям кода и ДДР не трогает вообще.

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

Максимальный пакет данных езернета вроде бы около 1500 байт. Если вы планируете слать данные быстрее чем они приходят, то есть смысл сделать ФИФО на элементах ПЛИС. В ксалинксах допустимый размер до 16 КБайт, у вас думаю не меньше. Это модуль который позволяет с одного конца писать в него, а с другого читать, делать это одновременно без какого либо дележа шины и участия процессора.

В целом систему сбора и отправки данных по УДП можно собрать вообще без управляющего процессорного модуля. Так просто настраивать удобнее...

да

лучше отдельный контроллер. программу ниоса вполне можно утоптать в on-chip. DDR оставить под данные

да, я делал такой модуль. он копировал пакеты пачками из sdram и кидал их на udp_tx_offload. задержки минимальные, ограничиваются inter packet gap + пара тактов шины. можно еще джамбо-фремы использовать

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

я бы делал вариант с процессорным модулем, программа в on-chip или внешней ssram и sdram для АЦП и sgdma. потом в погоне за скоростью можно постепенно переносить программные куски на железо.