[doom13 0]

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

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

 

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

 

Другой вопрос, что будет принимать такой поток и сумеет ли оно его обработать.

 

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

 

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

 

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

Edited June 15, 2013 by doom13

[doom13 0]

несколько соображений по теме.

во-первых нужен компонент, который будет складывать данные с АЦП в некоторый буфер. буфер желательно побольше, чтобы 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? Почему данный вариант плох и нереализуем?

 

[Konst_777 1]

...Почему данный вариант плох и нереализуем?

Этот вариант неплох и реализуем. Скорость обмена будет зависеть от процессора Nios II. Попробуйте.

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

[doom13 0]

Затестил два варианта работы. Пока для проверки использовал 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 - однопортовая.

[Golikov 0]

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

 

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

 

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

[doom13 0]

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

 

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

 

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

 

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

[Golikov 0]

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

 

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

[doom13 0]

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

 

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

 

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

[vadimuzzz 0]

Почитал ещё форум 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 0]

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

 

[gosu-art 0]

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

[Golikov 0]

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

 

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

 

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

 

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

[vadimuzzz 0]

Поясните пожалуйста, правильно ли всё понимаю:

1. Под программным формированием заголовка понимается то, что в область памяти необходимо положить сам заголовок и последовательно сформированные данные (две операции копирования памяти, или, как минимум, одна, если заголовок сформировали заранее)?

да

2. Или это не столь критично, в отличие от п.1?

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

3. Если данные в udp_tx_offload запихивать с помощью железного модуля с выходом Avalon ST Src (что-то типа prbs_packet_generator->udp_payload_inserter->tse), то можно получить скорость передачи выше, чем для п.2?

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

4. Реализация п.2, когда какой-то поток данных (в моём случае от АЦП) записывается в память (SDRAM, данные хранятся и будут передаваться, скажем, по N-байт), считывается из памяти при помощи SgDMA, далее всё загоняется на udp_tx_offload и TSE, сможет обеспечить скорость передачи порядка 600 Мбит/с? Не возникнет ли конфликт записи-чтения SDRAM со стороны SgDMA, Nios (программа исполняется из SDRAM), модуля приёма-записи в память данных от АЦП (нужно будет делить время обращения к памяти)?

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

5. Ну и самый важный вопрос, что выбираем:

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