Endpoint Block Plus v1.9 for PCI Express (xilinx), Неправильное поведение cfg_interrupt_rdy_n Опции

[disel]

Добрый день коллеги!

Возникла следующая проблема:
Моделирую endpoint_blk_plus_v1_9 вместе с BMD из xapp1052 с целью дальнейшей переработки. Тестовое окружение из примеров к ядру с некоторой доработкой.
Цикл DMA запускается, выполняется и должен формировать прерывание. Его то и нет. Ядро endpoint_blk_plus_v1_9 держит сигнал cfg_interrupt_rdy_n в единице и не хочет устанавливать в 0. При конфигурации ядра указано использовать 4 вектора MSI. Прерывания в контрольном регистре разрешены, MSI тоже. Да и без них тоже не получается.
Поведение сигнала cfg_interrupt_msienable тоже не ясно. Он в нуле даже после того как разрешил MSI. Обязательно ли записывать адрес и данные MSI чтобы разрешить этот сигнал?

Сталкивался ли кто с такой проблемой? И какое состояние сигнала cfg_interrupt_rdy_n после сброса должно быть? Судя по схема BMD он должен стоять в нуле.

[disel]

Разобрался, чтение документации помогло
В даташите на ядро указано что сначала пользователь устанавливет сигнал cfg_interrupt_n и номер прерывания на cfg_interrupt_di[7:0] . В ответ ядро устанавливает cfg_interrupt_rdy_n для поддтвеждения.

В примере из XAPP1052 наоборот. Пользовательское ждет cfg_interrupt_rdy_n и после этого устанавливпет cfg_interrupt_n. Косяк. Не ясно только как господа из ксалинкса этот пример тестировали.

[disel]

Поведение сигнала cfg_interrupt_msienable тоже не ясно. Он в нуле даже после того как разрешил MSI. Обязательно ли записывать адрес и данные MSI чтобы разрешить этот сигнал?

С разрешением MSI тоже понятно. В BMD msienable берется не из ядра, а из контроллера конфигурации BMD_CFG_CTRL. Он запускается при включении бита bus master. Нужно разрешать bus master после того как разрешен msi. Не ясно насколько это корректно, в стандарте ничего про это не видел.