Здравствуйте!

У меня есть задача:
Организовать передачу данных по PCIe с ПЛИС на ПК (Win7 x64).

Имеется: отладочная плача Xilinx vc709 на Virtex-7, опыт работы с ПЛИС
Отсутствует: опыт работы на уровне драйверов, работы с PCIe

Подскажите, как правильно и оптимально организовать систему?

Вместе с PCIe IP-core идет пример, в котором реализован контроллер памяти. Взяв триальный WinDriver я смог записывать и считывать байты через тестовое же, но на этот раз виндрайверское приложение. Однако виндрайвер платный, да и функционал мне нужен не то, чтобы выдающийся. Решил подумать на тему написания драйвера.

Поставил VS, WDK, настроил удалённый запуск и отладку драйвера на тестовом компьютере. Теперь настало время решить, в каком направлении двигаться и как это сделать менее болезненно.

Как я понимаю, у меня есть два варианта:
1. Определиться, устройство какого типа я буду формировать на ПЛИС: контроллер памяти, мультимедийное утсройство, что-то ещё и под него писать свой драйвер.
2. Подумать насчёт того, может уже есть драйверы, которые решают мою задачу, останется только сформировать на ПЛИС соответствующую конфигурацию устройства.

Собственно, вопросы к уважаемой публике:
1. Есть ли какие-то стандартные решения или подходы к подобной задачи? И какие?
2. Какой из вариантов лучше?
3. Что почитать?

Буду благодарен за любой совет.

Самое главное - с точки зрения драйвера нет разницы, PCI это, или PCIe. Поэтому, если был опыт с PCI - то делайте все точно так же, с точки зрения софта. Если не было опыта, то... Смотрите как пример драйвер, который идет с WDK (7600), в src\general\pcidrv\wdm - там довольно сложный драйвер, сетевой карты (Intel 82557/82558 based PCI Ethernet Adapter). Но, главное, не сама работа с сетью, а базовые вещи - как получаются адреса ресурсов железки, как прицепиться к прерыванию, как писать/читать эти самые ресурсы платы. Вот на базе этого и делайте свой драйвер. На самом деле, это не сложно. Сначала отрезать от него почти все (включая обработку всех IOCTL и READ/WRITE), оставив только минимум, получение ресурсов, регистрацию девайса в системе, и пр. PnP. А затем, добавлять по чуть-чуть свое. Ну и научиться писать INF - файл.

Что касается каких-то "стандартностей", тут Вам не УСБ, нет стандартов. Да, если Вы сделаете, например, UART, совместимый по всем портам с 16550, то без проблем повесите на него микрософтовский serial.sys, но это UART. А что-то сложнее делать, уже не выйдет подделаться под какую-то чужую железяку.

В общем, сделайте сначала железяку, которая через порт в I/O Space умеет зажечь/погасить светодиод. И напишите драйвер к ней, который имеет один IOCTL, зажечь/погасить его. А дальше уже все как по маслу пойдет, когда это сделаете.

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


Для начала нужно четко понять что за систему Вы строите и что от нее хотите -
какие данные (непрерывный поток, пакеты, одиночные слова, ...), каков суммарный трафик, кто инициатор передачи, требования к задержке передачи, структура/интерфейс/параметры управления, наличие готовых IP корок, ....? .


Драйвер должен "знать" железо которое вы реализуете в FPGA с точностью до регистра/бита. Поэтому вариант у Вас один - сначала определитесь со структурой железа.


1a- все самому, 1b- заказать разработку, 1c-Купить подходящее готовое IP, 1d- найти похожее open source, 1e.., 1f.., ...
2. Нужно определить Ваши критерии "лучше"

Сомневаюсь что Вы найдете готовые драйвера под Win. Обычно сорцы драйверов только под linux. Можно посмотреть понять что и как нужно делать. Поищите реф дизайны с PCIe. Есть от Xilinx тот же TRD connectivity kit (c evaluated версией DMA контроллера или их appnote пример с PCIe master. Есть ряд open source проектов с PCIe и DMA на http://opencores.org ну или например тотже NetFPGA.

Успехов! Rob.

Спасибо за быстрый отклик :)

SM, насчет стандартов я имел в виду какой-то сценарий действий, который позволит быстрее прийти к решению, не изобретая велосипедов.
Опыта ни с PCI, ни с PCIe нет, так что, пожалуй, последую вашему совету насчет разбора примера сетевой карты и мигания диодом.

Не подскажете какой-нибудь ресурс или литературу (кроме msdn и спецификации PCIe), чтобы можно было проще разобраться и въехать в тему? Нашел много книг про WDM, а сейчас, как я понимаю, WDF -- есть ли принципиальная разница или можно для начала и то почитать?

RobFPGA,

В первом приближении: потоковая передача данных, единицы Гб/с. В остальном жёстких требований нет.
Самый простой из приемлемых вариантов: плата всегда молотит данные, компьютер принимает, когда готов. Или он сообщает устройству, что готов и плата начинает передачу. Но в настоящий момент в приоритете скорость реализации прототипа и приемлема любая система, позволяющая с адекватной скоростью передавать данные на ПК.

Из IP-корок есть Integrated block for PCIe от Xilinx. Правда, еще предстоит понять, как подружиться с AXI, но это отдельная тема.


Имеет ли значение то, как сконфигурить корку (какое base class value и проч.), или если я сам буду писать драйвер, то указанный класс устройства мне не важен, так как я сам буду знать, как он отображается в дереве устройств и как к нему обращаться?

Сценарий:
1) Сделайте железку с Slave I/O портом, который зажигает светодиод.
2) Сделайте простейший драйвер для нее.
3) Добавьте в железо, например, таймер с прерыванием.
4) Сделайте в драйвере мигалку в прерывании.
5) Сделайте простой мастер - передачу в DMA 4096 байт данных в комп.
6) Сделайте драйвер для этого.
7) ... Ну тут уже сами всем все советовать будете ...

Не изобретая велосипедов... Я забыл главное! В WDK 2600 - WinDDK\2600\src\kernel\serial - драйвер UART 16C550 и иже с ними... Эту микросхемы каждый школьник знает, как она работает, какие у нее порты, и т.п. Драйвер там прост как валенок. Вот его берите, и обрезайте сначала до минимума (убрав ВЕСЬ I/O - read, write, ioctl), и потом добавляя сначала свои IOCTL, а потом, может быть, и read/write, правда, последние часто не нужны. Так что сетевую карту - отставить! Вот с чего надо начинать.

Ресурс... Я ничем, кроме msdn, спецификаций, гугля и исходников (как и serial.sys, и сетевухи, так и верилог-исходников от китов), не пользовался, поэтому не знаю... Также не знаю, что такое WDF. Не лезьте в дебри, берите WDK 7600, берите serial.sys (из 2600!!! не из 7600!), и собирайте из него свой драйвер. Не пользуйтесь всякими WDF/UMDF/KMDF и прочими гнилыми соплями C++ными. Кстати, тот же serial в 7600 - уже WDF-ный, мне лично, даже лень вникать стало в эту мутоту... Поэтому за основу - именно serial из 2600 (он БУДЕТ работать и под win 8.1 - если соберете в Win 7 build environment, и будет и под XP).

Железо отлаживайте с виндрайвером. С ним и ДМА без проблем отлаживается (проходил). А потом уже на отлаженном железе - свой драйвер. Периода evaluation на это хватит, да и если что... В личке скажу



Имеет... Винда может начать обзывать Ваш девайс PCI-PCI мостом (когда там нули), каким угодно адаптером, и т.д., так что, задайте туда нечто, близкое к реальности. Ну и VID/PID такой, чтобы не попасть на готовый драйвер в недрах микрософта...

Спасибо за разъяснения!
7 пункт воодушевляет :)

А что не так с KMDF? Я, читая msdn, я увидел только два пути: UMDF и KMDF. Вот.

Или я чего-то не понимаю.

А насчёт виндрайвера, я пробовал то, о чем вы бы хотели мне сказать, но что-то там пошло не так. Не помню уже.

Какой тип устройства близок к реальности? Multimedia device подойдет?

Возможно, это личное, но я терпеть не могу C++, и вообще, в принципе категорически против использования в драйверах чего либо, кроме API операционной системы. Все эти ***F - это внешние либы, хрен знает как что делающие.

Вот в MSDN верный путь - http://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx и http://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx

В общем, я предложил - брать serial.sys из DDK версии 2600, как самое простое в понимании и быстрое - но можете идти и своим путем, через *MDF. Я же не настаиваю... Это лишь мой опыт.


Это вряд ли, что именно то. Там ничего "не так" пойти не может ни при каких условиях.


Я туда загнал 0x118000xx (там 24 бита, а младшие 8 - это ревизия девайса) - получилось как-то типа контроллера сбора данных, или что-то в этом смысле. В общем, от этого зависит только то, как система показывает это устройство, пока не него не установлены драйверы. Надо выбрать что-то адекватное, чтобы юзер не пугался.

Я просто не знал о том, что есть другие пути и msdn тщательно скрывает их от неофитов.

Ссылки завтра изучу, благодарю.


Тогда интересно, а в ЛС я почему-то не могу писать.


То есть, это не более чем формальность, вроде разрешения файла в ОС?

Ну, в общем, загляните в реестр в HKLM\Софтварь\Микрософт\Виндовоз NT\КаррентВершн\Network - там три явно лишних, очень характерных значения есть. Вот их удалить, и время тикает с нуля...

Вы мало еще тут натусовали сообщений, чтобы ЛС открылись...


Да. Потом оно все равно попадет в класс, GUID которого вписан в INF-файле от драйвера. Но, пока драйвера нету, оно будет числится соответственно указанному в configuration space классу.

PS.
А в MSDN что либо найти без поллитры практически невозможно. Поэтому, ставьте WDK 7600, и открывайте его хелп - через меню "Пуск" - Windows Driver Kits->WDK...->Help->... - там все это есть, куда я Вас в MSDN отправил.

Ну хоть направление движения стало чуть яснее, еще раз спасибо.


Придется пофлудить тогда, а то очень надо одному пользователю написать, да всё никак.

Я правильно понимаю, что на данный момент есть три варианта написания драйверов под win:

1. WDF. Продвигаемый и развивающийся МС фреймворк. Более гибко и универсально.
2. WDM. То что было до WDF, не поддерживается и не развивается, но работает.
3. Legacy. То, что вы предлагаете, с использованием функций API ядра, тогда как WDF/WDM используют более высокоуровневые обертки?


Вы имеете в виду, брать из примеров для WDK 2600? А где их взять, MS подсовывает 8.1, максимум, 7600.

И этот драйвер ком-порта, похоже, не совсем то, что вы имели в виду. Тут С++ исходники для сборки KMDF драйвера.

WDM == Legacy - это одно и то же. Оно и поддерживается, и развивается, это же API ядра! Оно не может не развиваться, все происходит из него! Вот его и предлагаю. В доказательство, что оно развивается, приведу ссылку на MSDN:
http://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx
вот Вам функция нативного API, которая "Available starting with Windows 8"

WDF же - это некое извращение-надстройка над WDM, которая делает вот что:
a) Увеличивает код драйвера в размере на порядок из-за линковки этой самой WDF
б) Уменьшает скорость/производительность драйвера.
в) Усложняет жизнь программисту тем, что еще и WDF изучать надо.
г) Делает невозможным работу драйвера под XP и 2000.
д) Возможно, делает еще что-то, о чем мне неизвестно

Поэтому, я не понимаю, зачем это нужно. Видимо, чтобы подсадить людей на самые последние винды, ибо под более старым все перестанет работать. А по сути - это WDF вызывает все те же WDM функции, представляя тупую прослойку неясного назначения. В общем, это мой принцип - драйвер и железка должен работать если не на 2000, то хотя бы на XP, и везде выше. (хотя бы потому, что сам работаю только под XP, ибо, к сожалению, все остальное, что старше, совершенно непотребно для работы (не бухгалтером и не секретуткой) сделано). WDK 7600, кстати, под XP все собирает как надо... WDK 8.1 почти не нужен, нужен только signtool от него.




Он, тогда, не WDK, а DDK назывался... Да, из него. Собственно, мне не жалко, цепляю его сода.... Да и ссылка, где взять DDK целиком, гуглится на раз, например, https://winworldpc.com/download/3D08C50C-18...E5-7054D21A8599

Драйвер собирается и в DDK 2600, и в WDK 7600 в любом из его build environment командой build. Но, чтобы он работал и в винXP, и в 7 и 8 - его надо собирать в WDK 7600.

Вот здесь в комментариях к статье наткнулся на фразу:
"Вижу стандартный legacy драйвер, а вот ни одного признака WDM не вижу."

Я не хочу, да и не в том положении, чтобы спорить и что-то доказывать, наоборот, хочу разобраться в терминологии и собрать всё в ясную картину мира.
Там же советуют WDF, но это я как понял дело вкуса и ваше мнение я услышал :)

Главное, что, как я понял, WDM ничем не хуже WDF и с помощью WDM можно сделать то же самое, только WDF -- фреймворк над WDM? Тогда получается, что в WDF проекте можно и не использовать WDF плюшки. Так?


Для этого надо знать что именно гуглить :) С ходу сложно уловить тонкости платформы, особенно если она менялась, переназывалась и вообще. Тем более ожидал увидеть его все-таки на официальном сайте. В общем, спасибо за помощь.




Кстати, вот что пишет Википедия:
"KMDF также доступен для скачивания для Windows XP и даже Windows 2000, в то время, как UMDF доступен начиная только с Windows XP."

Не хочу вникать особо, но, возможно, у кого-то Legacy ассоциируется с до-PnP эпохой (Windows NT 3.5, 4.0). Там, да, совсем все было Legacy. В общем, на самом деле, если драйвер обслуживает IRP_MJ_PNP, то это и есть признак того, что это WDM-драйвер.


Ну да, возможно, и вкуса. Возможно, кому-то нравится прицепить к своему автомобилю сзади связку из всякого хлама весом в пять машин, и так вот с грохотом и медленно ездить.



С помощью WDM можно сделать вообще все, что в виндовс можно. WDF - это да, фреймворк над WDM, но ничего не упрощающий, и убивающий совместимость со старыми ОС. Там (наверное) можно использовать и WDM-функции напрямую. Взять тот же serial.sys, но из WDK 7600 - там WDF - а используется налево и направо и WDM. В результате точно та же функциональность. Так что, совершенно неадекватно сравнивать "WDM хуже или нет WDF" - WDM драйвер можно просто написать, а можно написать сложно, используя WDF. Но драйвер все равно будет WDM (Windows Driver MODEL - это модель, и она не менялась с win2000, когда появилась).


Насчет KMDF и пр. - Ну да, возможно он и доступен и для XP. Но нафига это все надо, когда можно сделать драйвер размером 14336 байт (это реальный размер моего драйвера PCI/PCIe железяки со scatter-gather DMA), и он, ОДИН файл, будет работать везде, от win2000, и до win8.1 32-bit. Ну и отдельно собрать 64-битную версию (ее размер у меня 19456 байт, из того же исходника, естественно, без каких либо правок/добавок).

UPD:
Вот импорты из WDF-версии драйвера serial.sys


Это на 2000 гарантировано работать не будет. Там нет WDFLDR.SYS!

Сейчас почитал в разных местах, везде пишут, мол, до PnP разработка драйверов была сущим адом, когда появилась WDM стало лучше, но всё еще "a challenging task". А вот WDF -- манна небесная, из WDM делает конфетку и вообще "easier to learn and easier to implement robust Windows drivers".

Подозреваю, конечно, и влияние маркетологов на эти утверждения :)

Теперь картина мира в общих чертах нарисовалась, ушёл в чтение книг и документации.


А у KMDF как получается?

На самом деле, для несъемных устройств толком ничего не поменялось. Я писал кое что для NT4.0 - конкретно, делал драйвер, который прикидывался Altera ByteBlaster, но работал через совсем другой JTAG. API было в общем, все то же, просто добавился геморрой по обслуживанию PnP-запросов. А вот для съемных устройств, например USB, да, пришла манна небесная Куда потом WDF подлил немного дегтя... Да даже не подлил... Ведь и без него живется хорошо (я хорошо знаю WDM, и смотрел на WDF - ну ничего там нету полезного вообще!). Но кто-то зачем-то его сделал, скорее всего, как Вы заметили, вопросы маркетинга, убить старые ОС, заставить пересесть на новые, и заапгрейдить и купить железо, чтобы это так же быстро заработало, как и раньше.

Они обещают более простой интерфейс в WDF. Может, и не врут? Надо попробовать.

Мне кажется, тут ситуация как Python-ом и Си. Если я знаю Си, мне не надо изучать Пайтон , если всё то же я могу сделать более быстрым и за меньшее время на Си. Однако, тому, кто в первый раз слышит фразу "язык программирования", очевидно, работать с Пайтоном будет намного приятнее. И не думаю, что здесь стоит искать никакого другого заговора, кроме как нацеленного на снижение порога входа. А скорость работы и размеры, это плата за плюшки.

К тому же, как я понял, разделение драйвера на работающие в режиме ядра (KMDF) и в пользовательском (UMDF) тоже не на пустом месте получилось, а направлено на то, чтобы по возможности максимально отнести программиста от ядра, чтобы и драйвер работал, но в случае чего система не крашилась.

В общем, эти мысли -- результат моего чтения выходного дня пропагандистской литературы от M$ :)

IMHO, попробовать, конечно, можно, но после того, как будете докой в WDM вообще, и в API ядра, в частности, чтобы понимать, что, где, как, и почему.

Потому, что драйвер, и вообще, ядро, это не то место, где можно разбрасываться ресурсами налево-направо.

PS
А что такое user mode driver, я к сожалению вообще не в курсе... И зачем они нужны.

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

Даже если это и так, то доступ к I/O должен быть через средства виртуализации, не говоря уже о тормознутости реакции на прерывание с переключением контекста в пользовательский режим. Поэтому, я не думаю, что в юзер моде можно реализовать сколько нибудь эффективный драйвер. Как я предполагаю (но, не знаю), это, видимо, только для какого-то очень ограниченного списка подвидов драйверов годится.

А запускать драйвер на той же системе, где он и компилируется, так это всегда без проблем. Кстати, для такой отладки есть жутко удобная утилитка - http://technet.microsoft.com/en-us/sysinte...s/bb896647.aspx

Вообще UMDF ругают. Мол, первая версия убога, а последняя только для 8.1 годится и то не для всех целей. А так KMDF для всего.




Хм, интересная утилитка

И весьма полезная!
С вашего позволения, господа, добавлю свои пять копеек. Во-первых, полностью солидарен с многоуважаемым SM: пользуйтесь WDK или хотя бы попытайтесь. У меня весьма скромный опыт работы с DDK (ныне WDK) - создавал простой драйвер для работы с USB-устройством в режиме Bulk, но впечатлений осталось на всю жизнь. Как Вам предложили ранее, возьмите примеры Microsoft, которые наличиствуют в установленном пакете WDK. Я брал bulkusb, убрал сначала все лишнее, а потом добавил нужное.

Функции драйвера, в том числе и процедуры передачи данных, реализуются посредством так называемых IOCTL-кодов. Обращение к драйверу осуществляется при помощи всего одной функции - DeviceIoControl(), входящей в API Windows, куда засылается IOCTL-код, однозначно определяющий какую процедуру драйверу нужно вызвать и как интерпретировать другие параметры, передаваемые в DeviceIoControl().
Почему-то мне думается, что с программированием PCIe ситуация аналогичная. В любом случае, "вьезжать" в WDK стоит времени и сил, которые на это потребуются (WDF никогда не пользовал).

В качестве документации я пользовался только MSDN, ибо там наличиствует вся необходимая информация. Только в моем случае это была локальная копия именуемая "MSDN 2000" (или 2002, не помню), которая тогда шла на трёх CD, ей было удобнее пользоваться, чем он-лайн версией. Возможно, сейчас существует обновленный вариант.

Эта часть MSDN локально идет внутри WDK - в меню "Пуск": Windows Driver Kits -> WDK 7600.16385.1 -> Help -> WDK Documentation

Тем лучше, на мой взгляд. Он-лайн у меня всегда медленно работает. Эх, надо бы какую-нибудь задачу придумать, чтоб с WDK попрактиковаться.

Менее, чем наполовину. Отличие от USB кардинальное - если для USB все делает драйвер, которые под Вашим в стеке, то с PCI/PCIe все делаешь сам - сначала, в обработчике IRP_MJ_PNP/IRP_MN_START_DEVICE, драйвер получает информацию о ресурсах устройства (физические адреса его регионов I/O портов, памяти, и прерывание), а затем работает непосредственно с портами устройства при помощи всяких там WRITE_PORT_UCHAR и иже с ними, а также может производить DMA-операции (режим PCI BusMaster), когда устройство само передает данные в память компьютера - для этого производится блокирование страниц памяти, получение физических адресов этих страниц на шине PCI (PCIe), передача этих адресов в устройство и запуск передачи. Всего этого в USB нету.
То есть, USB, это совсем просто. А PCI, особенно мастер, это уже следующий уровень.

Я только рад, что к теме присоединяются новые люди . Спасибо за ваши пять копеек.
Теперь 2:0 в пользу WDM.



Что характерно, WDK 8.1 устанавливается уже без офлайновой справки (или же я не нашел её). А у 7600 всё на месте, чудеса.

Я тоже столкнулся с проблемой создания своего драйвера под PCIe.
Делал опираясь на toaster (WinDDK\7600.16385.1\src\general\toaster\wdm\func\).
В нем даже херить ничего не пришлось. Правда в нем нет обращений к реальному железу. Но это можно стянуть с упомянутого SM драйвера UART.

Здравствуйте.
Так же столкнулся с задачей реализации PCI Express на плате Xilinx.
Как понимаю вы так же запускали пример контроллера памяти на основе Integrated Block for PCI Express. Разбирались ли вы что там к чему? Уже какой день не могу понять как и что в нем работает...
Как я понимаю на сам ip возлагается задача инициализации в системе, фильтрация запросов (пропускает только то, что относится к нашей плате, и не пропускает то, что относиться к другим устройствам подключеным по PCIe), а так же преобразование в пользовательский AXI-интерфейс. Так ли это?
Просто я запустил тестбенч от этого примера и вижу следующую картину:
1) сперва появляются данные на дифпарах pci_exp_rx и pci_exp_tx. На AXI - тишина. Предполагаю что в этот момент как раз и идет инициализация платы.
2) затем появляются данные на axis_rx_tdata, такого вида:

но при этом сигнал валидности axis_rx_tvalid в нуле.
3) вместе с данными появляется сигнал валидности:


Вот и не могу понять что за данные передаются без сигнала валидности, что за данные [15:0] во-втором DW и что за данные в третьем DW на axis_tx_tdata...
Если разбирать по полям правильно ли я понимаю на примере:
01a0_0a0f_0000_0001
de03_7320_0000_0010

01a0 - Requester ID
0a - Tag
0f - BE
0000_0001 - атрибуты и порядковый номер
de03_7320 - данные
0000_0010 - адрес
?

Попробовали ли вы действовать по этому сценарию? Получилось ли что то?

Добрый вечер, добро пожаловать в наше уютное обсуждение:)

Во-первых, да, именно этот проект я и зашил.

Сперва я запустил тестовый драйвер от виндрайвера, убедился, что устройство определяется в системе, что в память можно записывать и считывать. То есть, работающая болванка есть. На этом этапе я решил отложить часть ПЛИС и заняться драйвером.

Как можно заметить по другим моим топикам на этом форуме, я пошел против системы и SM-а :) и соблазнился на рекламируемые прелести WDF. На данный момент это закончилось тем, что отладчик подключается к рабочему компьютеру только когда моё устройство не подключено, что странно и бесполезно. На этой ноте я отчаялся и решил посмотреть и вовсе в сторону Виндрайвера и разобраться в том, что же такого удобного и классного у них есть.

Судя по описанию API действительно, всё радужно и хорошо. Тем более, что пример собирается и работает, а код его не выглядит пугающе. Как я понимаю работу дальше, необходимо научиться создавать на плате прерывания и тут мы погружаемся в пучину корки.

Тестбенч, о котором вы говорите, как-то не попадался мне на глаза, так что ничего прокомментировать не могу. Пока с трудом понимаю, как можно использовать готовый пример для создания собственного проекта. Однако обрабатывать и генерить все сигналы вручную представляется ещё большим мраком и я немного в растерянности. Еще хотелось бы отойти от AXI, а то разбираться ещё и в нём надо.

Вообще, мне достаточно научиться выкидывать прерывания, по которым драйвер читал бы определенную область памяти и всё. А переход от PIO к DMA, видимо, возможен не скоро, так как вообще не понимаю, как сейчас его реализовать.

Если вернетесь на рельсы WDM - то смогу объяснить все пошагово, как и что. Так как у меня реализованы и прерывания, и бусмастер.

Спасибо
Надо будет, все-таки собраться духом. Сейчас я вообще временно на другую задачу переключился.

Но, я так понимаю, что вы говорите об обработке прерываний драйвером. А это меньшая из зол, как создавать эти прерывания - вот где проблема.

Данный тестбенч находится в проекте примера. По сути просто выбираете "Run Behavioral Simulation" и ждете результата.

Я вот как раз и хотел взять какой то готовый пример, и посмотреть как и что в нем реализовано, а за тем уже прикинуть что нужно заменить. А то уже чем больше нахожу информации, тем больше погружаюсь в мрак - все таки одной теорией сыт не будешь, нужно что то железячное (по моему данный пример от xilinx подходящий для этой цели).

А в какую сторону вы хотели бы отойти от AXI? Он же вроде довольно прост - шина даных (tdata), сигнал валидности данных (tvalid), сигнал готовности принимать данные (tready). Остальные сигналы "расширяют возможности". Это касательно AXI-Stream, а он как раз у нас и используется. С остальными типами AXI сложнее. Или вы имеете в виду вообще какой то другой интерфейс, более заточеный под определенный круг задач (как в этой статье http://habrahabr.ru/post/244997/ интерфейс target)?

И все же - кто-нибудь может подсказать, что за активность идет, в мною описаном примере?
Да и помочь разобраться с самой структурой транзакций... А то если взять примеры и сравнить, что то не складывается:



01a0 - ID отправителя (почему совпадает для обоих случаев?).
0а - Tag. Что то вобще не понял его назначние "Tag[7:0] is an 8-bit field generated by each Requester, and it must be unique for all outstanding Requests that require a Completion for that Requester" - вроде как уникальное поле для каждого запроса. В данном случае, насколько я понял, выбрали порядковый номер. Но тогда не понятно как он распределяется (его изменения: 0, 0, 1, 2, ..., d, 0, 1, 2, ..., a).
0f (для axis_rx_tdata) / 04 (для axis_tx_tdata) - на сколько я понял это Byte Enable (Last/First). Про Last и First для axis_rx_tdata вроде понятно "If the Length field for this Request indicates a length of 1 DW, then the value for the 1st DW Byte Enables is implied to be 1111b and the value for the Last DW Byte Enables is implied to be 0000b.", а вот First для axis_tx_tdata - не понятно.
Следующее DW вроде понятно - тип транзакции и длина.
Следующее DW вроде тоже понятно - данные.
0000_0010 - адрес и PH (кстаи так и не понял про это PH). Для axis_rx_tdata вроде без вопросов, а вот для axis_tx_tdata опять в ступоре...