[RobFPGA 27]

Приветствую!

26 minutes ago, AVR said:

хотя возможно я упустил какие-то фантастические преимущества этих IP-ядер (понять бы каких)

Основное преимущество этих корок то ... что они уже есть и хоть как-то работают   А заодно хоть как-то работают и драйвера к этим коркам. 
Когда  понимаешь  что то что есть не устраивает по каким либо причинам тогда можно и поупражняться в написании собственных драйверов, descriptor-контроллеров и движков PCie DMA. 

Удачи! Rob.

[new123 0]

12 hours ago, RobFPGA said:

что они уже есть и хоть как-то работают

просто к слову =) Я тут сверх свежую корку запускал, pcie x16 gen3. По статистике, example design ее скачали около 100 раз всего. Месяц вожусь, ну не идет и все. Переделанный example. Вообще ни в какую dma не цепляется. Ладно, принял решение разложить ее на косточки в моделсиме. Убил еще неделю. Нашел баг, начинаю гуглить ключевые слова по багу. И нахожу объявление двух дневной давности на сайте интела, описание бага и пути его устранения (в 20.1 квартусе уже исправлен).  Нашел еще в драйвере. Написал им.

А так да, старые корки вещь хорошая, к ним и мануала полно.

[1891ВМ12Я 0]

6 minutes ago, new123 said:

Месяц вожусь, ну не идет и все

В том то и дело, я и недели не потратил на Altera на DMA, сделав сам. А потом перешел на Lattice и Xilinx, и на обоих это же самое в DMA заработало с пол оборота. Но не настаиваю, кому как приятнее проще удобнее ;)

[new123 0]

4 minutes ago, AVR said:

В том то и дело, я и недели не потратил на Altera на DMA, сделав сам

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

[RobFPGA 27]

Приветствую!

On 8/7/2020 at 11:08 AM, AVR said:

В том то и дело, я и недели не потратил на Altera на DMA, сделав сам.

За неделю? PCIe TLP DMA движок c read packet reordering буфером?   Вы круты  

Удачи! Rob.

[1891ВМ12Я 0]

13 hours ago, RobFPGA said:

За неделю? PCIe TLP DMA движок c read packet reordering буфером?   Вы круты  

Это правда что неделю, но Вы меня переоценили. Никакого reordering не было, и возможно это моя фатальная ошибка, либо причина не максимальной производительности (хотя по расчетам почти максимальная). Шлю адрес буфера, туда серия пакетов от ПЛИС, и всё последовательно кладется без сбоев, затем MSI по завершении. Быть может тут есть скрытая угроза, которую я не вижу ни в направлении хост-плис ни плис-хост. Так что это моя пиррова победа. Зажора процессора тоже не увидел

[RobFPGA 27]

Приветствую!

1 hour ago, AVR said:

Шлю адрес буфера, туда серия пакетов от ПЛИС, и всё последовательно кладется без сбоев

То есть это в одном направлении, из FPGA  в хост?   Тогда да - там не сложный автомат получается.  А вот в обратном направлении, да еще и в многоканальном варианте, да с макс. производительностью, да с потрошками  вот тут "веселье" и начинается. 

Удачи! Rob.

[1891ВМ12Я 0]

30 minutes ago, RobFPGA said:

То есть это в одном направлении, из FPGA  в хост?   Тогда да - там не сложный автомат получается.  А вот в обратном направлении, да еще и в многоканальном варианте, да с макс. производительностью, да с потрошками  вот ту "веселье" и начинается. 

Когда-нибудь попробую в обратно направлении, попробую что там за очучения :)

[Doka 1]

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

вот в упрощенном виде чтение стрима из девайса (dma_from_device):
 

#define DEVICE_NAME_DEFAULT "/dev/xdma0_c2h_0"
#define SIZE_DEFAULT (4096)
#define COUNT_DEFAULT (1)

uint64_t address = 0;//RAM address on the AXI bus in bytes
uint64_t size  = SIZE_DEFAULT;//RAM size of a single transfer in bytes
uint64_t count = COUNT_DEFAULT;//number of transfers
char  *buffer  = NULL;
int    fpga_fd = open(DEVICE_NAME_DEFAULT, O_RDWR | O_NONBLOCK);

posix_memalign((void **)&allocated, 4096 /*alignment*/ , size + 4096);

buffer = allocated + offset;

for (i = 0; i < count; i++) {
  rc = read(fpga_fd, buffer, size);
}

1. т.е. тупо делается read() в цикле по одному и тому же адресу, причём, как я понял, размер данных внутри карточки (который нарезаю с помощью TLAST) очень желательно делать таким же как SIZE в программе в user_space, так? даёт ли увеличение перформанса, если буфер выделять на хосте размера N x size (по TLAST)?

2. Непонятно почему память выделяется не запроценного размера, а size + 4096 ?

3. В принципе с IRQ работать еще рановато, и чтобы read() не зависал на пустом буфере придумал такой workaround: перед запуском чтения из девайса через AXI Lite Master вычитывать сколько буферов "готово" к вычитке. Как такой способ?

4. то что в read() надо передавать указать на буфер типа *char не очень удобно - у меня на тестах dma_from_device иногда вылазиет непонятная сдвижка в 16бит: на хост в тестовой прошивке отправляется 32битный счётчик, который инкрементируется каждое новое значение. нет ли функций чтения, работающих с буфером uint32_t? (наверное нету, но стоит убедиться).

5. Начал почитывать по программированию статейки, такой вопрос, всё-таки /dev/xdma0_c2h_0 - block device или char device?

 

 

 

 

 

[1891ВМ12Я 0]

12 minutes ago, Doka said:

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

1. Нужно измерять. Я например, не большой знаток, кто-то пытается до глубины понять, я не из таких. Надо драйвер смотреть, какими порциями он получает от устройства и по достижении какого объема он получает прерывание. У меня была задача такова, что я выделял буфер в программе на несколько мегабайт и в драйвере копил тоже кучу буферов. А потом в одном вызове read всё выдавал большим куском, в цикле вызывая copy_to_user

2. Может предосторожность или костыль, сам так иногда делаю

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

5. Можно ссылку на исходник драйвера? Судя по всему char, по крайне мере не видно смысла его блочным делать

[Doka 1]

 

1 hour ago, AVR said:

5. Можно ссылку на исходник драйвера? Судя по всему char, по крайне мере не видно смысла его блочным делать

https://github.com/Xilinx/dma_ip_drivers/tree/master/XDMA/linux-kernel/xdma

1 hour ago, AVR said:

4. Точно не ошибка схемы?

я этот момент спецом отмоделировал на срезе AXI stream

[new123 0]

10 hours ago, Doka said:

нет ли функций чтения, работающих с буфером uint32_t?

можно сделать финт ушами. Переопределение указателей. altera_bar0_device это я у себя проверил, подставил свои девайсы

	uint32_t buffer;
	uint8_t rc = read (altera_bar0_device, (char*)(&buffer), sizeof(uint32_t));

Или в c++ стиле через reinterpret_cast

	uint32_t buffer;
	uint8_t rc = read(altera_bar0_device, reinterpret_cast<char*>(&buffer), sizeof(uint32_t));

 

10 hours ago, Doka said:

такой вопрос, всё-таки /dev/xdma0_c2h_0 - block device или char device?

это надо посмотреть скрипт его создания, если девайс создается из скрипта. Или код создания, если девайс создается из драйвера

Изменено 13 августа, 2020 пользователем new123

[gosha-z 2]

Я же говорил, алгоритм другой:

1. Открываем chardev

2. Через ioctl запрашиваем максимальный размер блока памяти, который драйвер уже распределил

3. Делаем mmap без предварительного malloc, получаем адрес этого блока в userspace

4. Встаем в epoll-цикл, ждем, когда драйвер нам скажет "Готово, забирай"

read подразумевает под собой копирование данных kernel space -> user space, что есть накладные расходы

[1891ВМ12Я 0]

4 minutes ago, gosha-z said:

read подразумевает под собой копирование данных kernel space -> user space, что есть накладные расходы

т.е. пока user работает с mmap-ленными данными, драйвер в них писать не может? Значит нужно иметь второй буфер?

[gosha-z 2]

1 minute ago, AVR said:

т.е. пока user работает с mmap-ленными данными, драйвер в них писать не может?

Разумеется. Либо буфер на несколько транзакций сразу.