[alexPec 6]

Всем доброго дня!
Накиньте пожалуйста идей по решению такой проблемы.
Есть аппаратный блок на zynq ultrascale+.

1. Перед запуском этого блока делаю большую паузу (чтобы завершились  всякие переходные процессы, длительность которых максимум 1мс. Но это на всякий случай, все равно анализирую флаги завершения процессов аппаратного блока), инициализирую память входными тестовыми данными. 

2. Затем пишу в пространство регистров через AXI Lite  в 3 разных регистра 3 константы. Всегда одни и те же. Эти регистры используются в работе блока, но никаких процессов не запускает

3. Запускаю аппаратный блок.

4. Жду окончания работы

5. Проверяю результат.

Делаю 5 этих шагов по циклу. На 13-м цикле процессор вылетает в error handler exception при записи третьего регистра в п.2. Повторюсь, регистр ничего не запускает, в блоке это реально просто регистр, значение которого используется после запуска блока, но до запуска я не дохожу - вылетаю в эксепшн.

Т.е. 12 раз одно и то же делаю - все ок, и всегда на 13й раз при записи в конкретный регистр - вылет. Что такое может быть? Что проверить?

[dxp 213]

А аппаратный блок что-то с этими регистрами делает? Ну, читает их? Как AXI транзакция происходит? Такое впечатление, что как будто очередь переполняется и отлуп прилетает.

[fpga_dev 11]

А ILA у вас в проекте есть? Что показывает? Подключите его на все AXI шины какими пользуетесь и смотрите как проходят транзакции.

Когда процессор вылетает в exception, покопавшисть с отладчиком можно извлечь точную причину где и почему это происходит. Деталей не помню, но это делается, там есть специальные регистры где эта инфа сохраняется. Где-то даже был код обработчика на замену того что там по умолчанию, который вываливал кучу информации на ком. порт при подобных проблемах.

Но это все конечно если процессор не виснет намертво. А такого эффекта при желании тоже можно добиться 🙂

[alexPec 6]

2 часа назад, dxp сказал:

А аппаратный блок что-то с этими регистрами делает? Ну, читает их?

Он их по сути не читает, а использует выходы этих регистров - там хранится в частности инкремент адреса, т.е. на сколько увеличивается адрес после транзакции. Но в том то и фишка, что вылет - при записи в регистр, а не при работе блока. Блок в это время остановлен и ничего не делает.

2 часа назад, dxp сказал:

Такое впечатление, что как будто очередь переполняется и отлуп прилетает.

Как я понимаю, там очереди нет. Просто запись происходит достаточно долго, порядка 50 тактов. Т.е. пока видимо число дойдет до другого конца + пока придет обратно подтверждение.  

51 минуту назад, fpga_dev сказал:

А ILA у вас в проекте есть? Что показывает?

ILA конечно могу встроить, но там этих транзакций очень много. Надо будет изобрести что-то чтобы отловить именно проблемную. До зависания блок с процессором без вылетов работает постоянно где-то 7 сек, за это время там проходит миллионы транзакций, и все в порядке, никаких вылетов

[fpga_dev 11]

Можно еще попробовать поставить AXI Protocol Checker на все шины которыми вы пользуетесь, выход завести на ILA. Просто чтобы убедиться что с этой стороны проблем нет.

Ну а вообще проц сам по себе в отказ не уходит, для этого должна быть причина. Сначала надо разобраться какое конкретно исключение у вас срабатывает. Если это именно Data Abort, то дальше надо смотреть на содержимое FAR (Fault Address Register) и ESR (Exception Syndrome Register) a.k.a DFSR (Data Fault Status Regisrer)

[dxp 213]

13 часов назад, alexPec сказал:

Он их по сути не читает, а использует выходы этих регистров - там хранится в частности инкремент адреса, т.е. на сколько увеличивается адрес после транзакции. Но в том то и фишка, что вылет - при записи в регистр, а не при работе блока. Блок в это время остановлен и ничего не делает.

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

13 часов назад, alexPec сказал:

Как я понимаю, там очереди нет. Просто запись происходит достаточно долго, порядка 50 тактов. Т.е. пока видимо число дойдет до другого конца + пока придет обратно подтверждение.  

Я не ведаю деталей, как сделано в MPSoC, но, например, про 7000 сказано про его AXI GP мост:

Цитата

Master port issuing capability: 8 reads, 8 writes

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

Подозреваю, что у MPSoC тоже сделано похожим образом, отличия количественные. А может и тоже такие же. А 12 получается вместо 8 потому, что там на интерконнектах тоже есть буферизация -- путь длинный, с переходами через несколько тактовых доменов, без локальных буферов не обойтись. Вот и получается 8 в мосте и 4 по дороге до него.

Сделайте чтение из моста на стороне PL, если этого там нет.

 

[fpga_dev 11]

7 hours ago, dxp said:

Когда эта небольшая очередь заполняется, проц при очередной попытке получает отлуп и аппаратное исключение.

Вообще то нет, процессор в этом случае просто стоит и ждет. В AXI нет такого понятия как таймаут. Есть понятие "своевременная доставка" что означает что данные рано или поздно д.б.  доставлены но никаких временных ограничений нет и нет соответствующего кода ошибки. Есть только DECERR при обращении к пустому месту и SLVERR когда девайс выдаёт ошибку напр. проверки четности. Но при этом все транзакции должны быть корректно завершены, респонсы должны быть выданы в правильных количествах.

А таймаута нет потому что в AXI не предусмотрено вообще никакого механизма восстановления после ошибок протокола.Подразумевается что их нет и все всегда работает правильно. Кроме того нужно быть очень осторожным с ресетом, если у вашего девайса свой собственный ресет то нужно принять меры чтобы уже начатые транзакции были завершены. И к сожалению у Цинка  нет возможности сделать AXI reset на одной отдельно взятой шине, только полный сброс процессора.

Что касается Data Abort то там есть коды для вышеупомянутых DECERR и SLVRRR и множество ошибок прав доступа и пр. проблем с TLB но в общем то и все.

Но ещё не факт что там именно Data Abort и именно из за девайса а не банальный NULL pointer. Или вообще девайс пишет куда не надо. Вариантов масса.

[dxp 213]

2 часа назад, fpga_dev сказал:

Вообще то нет, процессор в этом случае просто стоит и ждет. В AXI нет такого понятия как таймаут.

Где вы про таймаут увидели хоть слово?

2 часа назад, fpga_dev сказал:

 и SLVERR когда девайс выдаёт ошибку напр. проверки четности.

Или если транзакцию нужно запихнуть в очередь, а она полная, и операция не может быть выполнена, поэтому транзакция, например, дропается, а в ответ летит Slave Error. А чтобы процессор не висел в ожидании вечность, контроллер интерконнекта генерирует исключение. Но это всё зависит от реализации, спека AXI, насколько помню, не оговаривает протокол выхода из ошибочных ситуаций.

UPD. Скорее всего там где-то есть что-то типа блока QoS, который следит за порядком на интерконнекте, и когда возникает подобное, генерит исключение. Наверняка, если покопаться, можно найти и какой-нить код, из которого можно понять, что конкретно является источником исключения.

[fpga_dev 11]

Если транзакцию нужно запихнуть в очередь а она полная то очередь просто держит соответствующий ready на нуле. И все.

То что вы описываете может быть реализовано только в конечном  девайсе и автору девайса для этого придётся напрягаться и делать все самому. И главное -зачем? Чтобы всем на другом конце гарантировано проблемы создать?  Если кому-то что-то от тебя надо - подождут. Если девайс не готов - axready убрал и все, пусть сидят курят, когда закончил поставил обратно и все дела. У AXI слава богу железобетонный сквозной flow control. И процессор сидит и ждёт и может ждать долго если вдруг напр. приоритетный трафик пошёл.

Интерконнект здесь тоже совершенно не при чем. Он никаких исключений сам не генерирует, единственно что он может это отфутболить транзакцию с кодом DECERR в rresp/bresp если такого адреса нет, но он должен все равно выдать правильное количество rvalid/rlast или bvalid.  QoS это тоже о другом, это когда у вас несколько очередей с разными приоритетами. QoS никаких исключений не генерит. 

Исключения генерятся  процессором в тя.ч исходя из битов rrsep/bresp. И ошибка шины это серьёзная проблема обычно требующая перезагрузки системы.

А по теме: exception скорее всего означает ошибку в программе (пойнтер в никуда)  или конфигурации (банально стек слишком мал) или в адресах железа или в инициализации регионов памяти или в кривом обработчике прерываний или железо пишет не туда или.  Не помню чтобы именно проблемы с AXI  вызывали исключения, обычно все просто виснет.