Zynq. Передача данных между процессорным модулем и программируемой логикой

Например, в программируемой логике реализован какой-то алгоритм обработки данных, который обрабатывает наиболее часто встречающиеся случаи. Если пришли данные, которые нуждаются в особой обработке (редкий случай) то их проще обработать на процессорном модуле. Чем быстрее они туда попадут, тем быстрее обработаются. Когда есть запас по скорости это всегда хорошо.
И в случае с работой с DDR. Можно организовать обмен данными (в случае большого объема) между разными каналами в программируемой логике через DDR, подключенную к процессорному модулю. Дескрипторы удобнее на процессорном модуле заполнять, а в обмене он непосредственно не участвует.

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

Так может в вашем конкретном случае и вовсе без проца можно обойтись, глядишь, ещё и денег сэкономите на железе?
Фишка Zynq и прочих подобных SoC с ПЛИС на борту в том, что на проц можно накатить ОС, линукс какой-нибудь, а логику ПЛИС использовать как акселератор тяжёлых вычислений и дёргать драйверами. При этом с одной стороны у вас будет очень сложный софт в проце, а с другой возможность делать наиболее тяжёлые операции на ПЛИС в реалтайме.
Сейчас не очень слежу за Zynq, но судя по статьям Xilinx, они очень интересуются 5G и Zynq туда хорошо вписывается. Также наблюдаю её у тех, кто обрабатывает видео с камер наблюдения в реальном времени (crowd control) и кто делает примочки для авто (всякие ADAS). Раньше у Xilinx был журнал Xcell, например в номерах 88 и 93 можно глянуть некоторые реальные кейсы, где, почему и как она использовалась.

Вот Вам кейс из реальной жизни. Zynq US+, на ЦП крутится линух с ftp и несколько SSD на SATA, а на PL многоканальный контроллер оптического интерфейса а ля FC. Вот тут DMA и прочая дичь очень кстати.

Всё зависит от задач. У меня несколько раз были такие задачи, которые прямо требовали участия процессора с программой. Конечно, можно реализовать конечный автомат для реализации алгоритма. Но это выльется в незабываемое приключение с багами и поиска случаев, когда они работают не в той фазе или случайно перепутал сигнальные линии. А если ещё управляете с компьютера, одновременно гоняя данные туда-сюда (могут участвовать высокоскоростные приёмопередатчики), то бывает ещё веселее.

У нас например одна из задач отрисовывать графики, полученные путем обработки данных с АЦП разными алгоритмами в реальном времени. FPGA данные через DMA в драйвер отправляет, драйвер через mmap в userspace, оттуда сервер через вебсокеты на фронтенд. Кнопочку нажал и в web-интерфейсе получил по 7 графиков для каждого из 4-5 каналов на несколько тысяч точек.