OpenSource DMA for Virtex 5, проект на www.ds-dev.ru Опции

[dsmv]

Всем доброго времени суток.

Я открыл исходный код для проекта контроллера PCI Express на ПЛИС Virtex 5;
Проект доступен по адресу: http://www.ds-dev.ru

Проект ещё не завершён. Сейчас мне пришлось опять его отложить. Но ознакомится с ним уже можно.
Работает полная модель системы.

В железе есть недостатки:
1. Не работает прерывание.
2. Есть сбои при частых обращениях к регистрам BAR1
3. Есть сбой при одновременной работе двух каналов DMA

Это всё исправимо.
Меня интересует критический разбор проекта.

[SFx]

спасибо, на недельке погляжу.

[dsmv]

Контроллер работает всё лучше и лучше.

Работает ввод и вывод данных. Есть сбои при одновременной работе двух каналов DMA.

[Bad0512]

Контроллер работает всё лучше и лучше.

Работает ввод и вывод данных. Есть сбои при одновременной работе двух каналов DMA.

Под двумя каналами ДМА понимается два потока в противоположных направлениях (один - на запись и один - на чтение), или два канала - это два логических устройства, шарящих шину и работающих в произвольных (возможно совпадающих) направлениях) ?

[dsmv]

Под двумя каналами ДМА понимается два потока в противоположных направлениях (один - на запись и один - на чтение), или два канала - это два логических устройства, шарящих шину и работающих в произвольных (возможно совпадающих) направлениях) ?

Реализовано два независимых двунаправленных канала DMA.
Они могут работать оба в одну сторону или в разные стороны.
Естественно, они разделяют шину.
Контроллер заканчивается 64-х разрядной параллельной шиной. С сигналами запроса DMA.

[Bad0512]

Реализовано два независимых двунаправленных канала DMA.
Они могут работать оба в одну сторону или в разные стороны.
Естественно, они разделяют шину.
Контроллер заканчивается 64-х разрядной параллельной шиной. С сигналами запроса DMA.

Никогда не понимал смысла в построении многоканальных контроллеров. Если контроллер построен правильно, то он утилизирует шину почти на 100%.
Соответственно когда один из каналов загружает шину, второй в любом случае ждёт пока шина освободится. Есть смысл распараллеливать лишь те операции,
которые могут в одно и то же время независимо работать не мешая друг другу. Например, чтение и запись. В остальных случаях вместо многоканальных движков
логичнее будет навернуть сверху над движком управляющий автомат, а не дублировать логику движка.

Есть хорошие новости:
прошло успешное тестирование одновременной работы двух каналов DMA.

1. Два канала на приём. Время тестирования 6 часов. Средняя скорость по каждому каналу 809.1 Мбайт/с
2. Один канал на приём, второй на передачу. Время тестирования 6 часов. Средняя скорость по каждому каналу 574.2 Мбайт/с

На сайте выложил описание управляющих регистров.

Поглядите документы на IP для бриджа GN4121/GN4124. Там есть некоторые интересные идеи, часть из них я реализовал в своём контроллере.
А кое-что наоборот убрал. В общем, довольно интересно наблюдать как одну и ту же задачу решают разные люди.
Бридж геннумовский в общем и целом не сильно от коры Ксайлинкса отличается - также торчат в обе стороны две шины данных (в данном случае они 16 бит ДДР, но это
не важно). К ним кое-какие сигналы управления. Всё очень похоже.
Кстати, всё забываю спросить... Откуда ваш контроллер берёт данные на плате и куда их складывает? Наиболее часто ДМА машины цепляют к ДДР контроллеру. На этом стыке,
кстати тоже есть возможность потерять производительность.

Прикрепленные файлы

 GN412x_FlexDMA_sequencer_design_guide_52179_Doc3.pdf ( 447.97 килобайт ) Кол-во скачиваний: 164
 GN412x_FPGA_IP_hardware_design_guide_51860_Doc2.pdf ( 2.89 мегабайт ) Кол-во скачиваний: 1465

 

[dsmv]

Никогда не понимал смысла в построении многоканальных контроллеров. Если контроллер построен правильно, то он утилизирует шину почти на 100%.
Соответственно когда один из каналов загружает шину, второй в любом случае ждёт пока шина освободится. Есть смысл распараллеливать лишь те операции,
которые могут в одно и то же время независимо работать не мешая друг другу. Например, чтение и запись. В остальных случаях вместо многоканальных движков
логичнее будет навернуть сверху над движком управляющий автомат, а не дублировать логику движка.

Смысл есть. Контроллер разрабатывается под специфику нашей компании - а именно подключение АЦП и ЦАП. Двухканальный и двунаправленный контроллер позволяет закрыть большинство задач. В частности одновременный ввод из АЦП и вывод в ЦАП, или ввод двух независимых потоков от АЦП.

Поглядите документы на IP для бриджа GN4121/GN4124. Там есть некоторые интересные идеи, часть из них я реализовал в своём контроллере.
А кое-что наоборот убрал. В общем, довольно интересно наблюдать как одну и ту же задачу решают разные люди.
Бридж геннумовский в общем и целом не сильно от коры Ксайлинкса отличается - также торчат в обе стороны две шины данных (в данном случае они 16 бит ДДР, но это
не важно). К ним кое-какие сигналы управления. Всё очень похоже.

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

Кстати, всё забываю спросить... Откуда ваш контроллер берёт данные на плате и куда их складывает? Наиболее часто ДМА машины цепляют к ДДР контроллеру. На этом стыке,
кстати тоже есть возможность потерять производительность.

Потерять производительность можно везде.
По поводу подключения, есть компонент
pcie_core64_m1 -http://src.ds-dev.ru/projects/ds_dma/core/...core64__m1.html
Это собственно контроллер, он имеет пакетную шину PB_BUS, которая реализована на двух сигналах pb_master и pb_slave;

Выше по иерархии компонент pcie_core64_m2 - http://src.ds-dev.ru/projects/ds_dma/core/...core64__m2.html
Он уже имеет нормальную 64-х разрядную синхронную параллельную шину.

Тестовый проект выполнен как проект ADMPRO. В нём реализован узел подключения к тетрадам cl_ambpex5_m2 - http://src.ds-dev.ru/projects/ds_dma/ambpe...mbpex5__m5.html
и собственно тетрады:
TRD_MAIN
TRD_DIO64_IN
TRD_DIO64_OUT
TRD_TEST_CTRL

Подробнее о интерфейсе ADMPRO можно прочитать на сайте "ИнСиС" - http://insys.ru/doc

В тетраде TRD_TEST_CTRL реализован узел формирования тестовой последовательности- cl_test_generate
и узел проверки тестовой последовательности - cl_test_check

В итоге cl_test_generate формирует тестовую последовательность, программа на компьютере её проверяет. Или наоборот, программа формирует тестовую последовательность, а узел cl_test_check её проверяет.
В тетраде MAIN также есть узел формирования псевдослучайной последовательности. В тесте двух каналов на приём используется два источника - тетрада MAIN и тетрада TEST_CTRL

[Bad0512]

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

Если Вы имеете ввиду со стороны памяти хоста, то там - честный scatter-gather, с листами страничек и размером одного ДМА пакета до 4 мегабайт (как раз размер HD картинки).
Если речь идёт о непрерывности со стороны интерфейса в локальную память, то в родном геннумовском интерфейсе всё даже хуже - там не то что адрес менять нельзя, его просто нет, интерфейс заточен на ФИФО. Кстати для ЦАП-АЦП вполне подходит такой вариант. Именно потому, что при обращении к локальной памяти нельзя выставить, а потом на ходу и поменять адрес, я и взялся этот дизайн переписывать. Приделал небольшой списочек дескрипторов для локальной памяти, в моём случае было важно за одну операцию забирать до 8 разных кусков видео-аудио, которые уже лежат в локальной памяти, но имеют разный размер (от 0 до 4 мегабайт) и естественно расположены по почти случайным адресам.

[dsmv]

Если Вы имеете ввиду со стороны памяти хоста, то там - честный scatter-gather, с листами страничек и размером одного ДМА пакета до 4 мегабайт (как раз размер HD картинки).

Я хочу обратить внимание как раз на честный scatter-gather. Во всех известных мне IP Core, а именно Xilinx, PLDA, Northwest Logic, Synopsys, Intensys, а также в микросхемах PLX используются одиночные дескрипторы.
Т.е. для одного блока памяти используется один дескриптор. Алгоритм работы: DMA читает один дескриптор и производит обмен с одним блоком. Если размер блока большой, например 1 Мбайт, то всё замечательно.
Но проблема в том, что выделить 1.5 Гбайта можно только в USER MEMORY. А там память выделяется страницами по 4 килобайта. И получаются большие потери, так как дескриптор читается для блока в 4 килобайта.

В моём контроллере дескрипторы объеденены в блок, за одну операцию происходит чтение блока в котором 63 дескриптора. Потери производительности на чтение дескрипторов минимальны. А если дескрипторов меньше 63 - то всё работает из памяти и потерь нет.

Интересное решение в DMA от Intensys. Там дескрипторы расположены в локальной памяти ПЛИС. Потерь на чтение нет, но большой блок в фрагментированной памяти разместить нельзя - не хватит памяти ПЛИС.


Со стороны локальной шины у меня DMA работает по фиксированному адресу, предполагается что там расположено FIFO.

[dsmv]

Добавлен проект ML605_LX240T_CORE для платы ML605. Там реализован PCI Express v2.0 x4; Работает. Скорости таки же, как и на AMBPEX5.

[dsmv]

Всем доброго времени суток.

Несколько слов по поводу развития проекта:

1. Разработка документации. Файлы скачивают, но вопросов пока никто не задаёт. Наверное всё понятно ?
2. Ядро для Spartan-6 x1; Есть ли у кого-нибуть какая либо плата для проверки ?
3. Размещение на opencores.org; Для этого необходимо сделать подключение к шине Wishbone, пример проекта для этой шины и документация на английском языке.

Какие есть ещё предложения ?