Jump to content

    

Doka

СуперМодераторы
  • Content Count

    2465
  • Joined

Community Reputation

0 Обычный

About Doka

  • Rank
    Electrical Engineer

Старые поля

  • Vkontakte
    Array
  • LinkedIn
    Array
  • Twitter
    Array

Контакты

  • Сайт
    Array
  • ICQ
    Array
  • Jabber
    Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Добрый день!

    Помогите, пожалуйста, с такой проблемой. Я осваиваю "камни" Xilinx и сейчас вышел на интересный вариант с ZYNQ 7. Приобрел инженерный набор MIZAR и получил массу примеров проектов на Vivado 2018.3. Пробовал использовать версию Vivado 2019.1, но примеры компилируются с ошибками, которые я еще не понимаю как исправить. Помогите с ссылкой на пакет Vivado 2018.3. Заранее благодарен. С уважением, Владимир, vvdolin@gmail.com

  2. да этих чипов вагон и маленькая тележка
  3. спасибо, это ценная информация. уточню: нить исполнения - это те функции, что описаны в threads.h так? вот тут как раз интересен практический опыт в разрезе выбора размера пакета для транзакций по PCI-E:выберешь маленький - перегруз процессора по утилизации ресурсов (поллинг), либо вообще пропажа пакетов, а выберешь большой - увеличивается latency всей цепочки (отправить на ускоритель, обработать, принять с ускорителя), что тоже нехорошо. В реальном кейсе надо принять (и передать at the same time) порядка 1 ГБайт/с, размер пакета 4КБ наверное будет маловать для "безбедной жизни" на среднем процессоре, но как научиться выбирать такие вещи не ставя множество натурных экспериментов, а эмпирически?!
  4. что это означает?.. не использовать read или альтернатив read всёже нет?! (примеров epoll без read|write в сети найти не удалось) тут есть варианты: минимальное время 1мс - как мне кажется, это ОЧЕНЬ много, выходит либо использовать "0" и нанослип() либо вообще ставить "-1"
  5. Дошёл я до этой стадии поэтому доп.вопросы: 1. Какой таймаут при вызове epoll_wait задавать?.. милиссикунды - слишком много, либо задавать 0 и использовать нанослип()? 2. не могу уловить в моём кейсе правильнее будет использовать epoll с событиями по уровню или по фронту. интуитивно кажется, что надо по фронту, но хотелось бы проверить себя 3. достаточно ли epoll_wait или надо использовать вариант функции epoll_pwait ? 4. ну и конечно самый концептуальный вопрос: как соотнести выбор таймаута (для epoll_wait), размера пакета и требуемой пропускной способности?! Мне надо принять (и передать at the same time) порядка 1 ГБайт/с, выбрал размер пакета 4КБ, но чувствуется его придётся поднимать (агреггировать пакеты в ПЛИС, складывая в один большой), чтобы добиться такой прорускной способности. (знаю что у ксая есть соотвествующее видео и презентации с обзором связи размера пакета и его влияением на пропускную способность канала, но хотелось бы мнения практиков).
  6. про коллизии всё верно, но в данном кейсе хеши использовать небюджетно и расточительно: получаем хеш из 32бит (перед этим "добив" нулями и длиной сообщения до 512бит) длиною 128 бит: и получим что при равномерном распределении одиночных ошибок 80% сообщений с неповреждённым 32битным "телом" будут отбрасываться как повреждённые из-за md5. т.о. хеши больше для случаев где сообщения не искажаются, но на приёмной стороне необходимо проверить подлинность (обычно подписываются не сами данные а хеш от них)
  7. в статье автор классифицирует стойкость CRC в зависимости от битности, что не совсем корректно, вот тут постарался раскрыть почему это не так: http://idoka.ru/who-is-better-than-crc32/ тут надо бы знать статистические свойства канала - начиная от вероятности появляения ошибки при заданной энергетике до распределения ошибок - для этого кстати, совместно с с помехозащищенным кодированием применяют перемежение данных (уже после наложения кодирования), вероятно , что в вашем случае (передача 32бит на адекватной скорости) перемежать уже "нечего", и более првильный подход - повторение передачи после таймаута + номинальная проверка целостности с CRC. посмотрите что-то типа СС1101 TI - там в даташите хорошо расписано как сделана встроенная защита при передаче "коротких" пакетов
  8. https://github.com/Xilinx/dma_ip_drivers/tree/master/XDMA/linux-kernel/xdma я этот момент спецом отмоделировал на срезе AXI stream
  9. потихоньку пишу логику ответных частей под 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?
  10. так там анализаторы протоколов идут в виде плагинов опенсорсные от сигрока, емнип, на питоне - так что при должной мотивации не проблема доработать аналогично. мне по юзабилити ПО тоже салеае нравится больше (либо я к нему ранбше привык), интересно можно ли в DSLogic залить "совместимое" с Saleae firmware & gateware?
  11. ага. это как раз есть в примерах комплекта поставки xdma.ko а есть может какая книжуля где об этом подробнее почитать, а то чувствую мне матчасти не хватает, что бы что-то стабильно работающее в user space соорудить. Я так понимаю Linux Device Driver не подойдёт? да там полная чехарда с дескрипторами ( или не там, а у меня в голове ): есть для AXI MM, есть свой формат для AXI Stream, а помимо этого есть ДМАшные (которые как раз делают SG) - вот последние-то точно драйвер разбирает, а для AXI Stream уже засомневался, да и примера нету в поставке для xdma.ko чтобы посмотреть "как правильно", придётся в исходники xdma.ko лезть, смотреть где там этот magic number пришивается/отрезается. вот конкретно по AXI Stream в доке написано The length of a C2H Stream descriptor (the size of the destination buffer) must always be a multiple of 64 bytes. но в таблице дескриптор занимает 64 бита:
  12. пытаюсь это увязать с хостовой стороной (в кишки драйвера не лезем), вот к чему я могу обращаться из user space: ll /dev/xdma* xdma0_bypass xdma0_bypass_c2h_0 xdma0_bypass_h2c_0 xdma0_c2h_0 xdma0_h2c_0 xdma0_control xdma0_events_0 xdma0_events_1 xdma0_events_2 xdma0_events_3 xdma0_events_4 xdma0_events_5 xdma0_events_6 xdma0_events_7 xdma0_events_8 xdma0_events_9 xdma0_events_10 xdma0_events_11 xdma0_events_12 xdma0_events_13 xdma0_events_14 xdma0_events_15 xdma0_user xdma0_xvc xdma0_user = AXI Lite Master xdma0_c2h_0 & xdma0_h2c_0 == DMA а вот как работать с прерываниями примеров нет правильно ли понимаю, что этот дескриптор (64бита, но на скрине 64байта - кажется опечатка) на стороне хоста должно формировать user app?
  13. US/US+ да, видел, но это прям задание со звёздочкой, уж больно он монстроузный как по утилизации ресурсов не карточке, так и по хостовой части (поддержка DPDK например) его точно с наскока вот так не взять может у меня вообще на хостовой стороне лажа, надо код показать какому-нить знакомому линуксоиду