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



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



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


Сообщение отредактировал doom13 - Jun 15 2013, 22:34

Почитал ещё форум 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. потом в погоне за скоростью можно постепенно переносить программные куски на железо.