[den_steppenwolf 0]

Добрый день! Стоит задача разработать аппаратную реализацию механизма сбора и выдачи ошибок, статусной и отладочной информации в ASIC'е в процессе его работы (специфические аппаратные ускорители).
Может быть, кто-то может посоветовать, какие типовые решения/подходы существуют?

(Основной опыт связан с разработкой под fpga, в разработке asic опыт гораздо меньше)

[Raven 9]

Зависит от того, что у вас там уже есть в SOC, и что это за аппаратные ускорители (на чем сделаны), какого рода статусную и отладочную инфу вы собираетесь собирать, какого объема будет трафик, каковы типовые модели применения этого механизма сбора инфы предполагаются и т.д., и т.п. Начать и кончить, одним словом. Дайте хоть какой-то слой детализации.

[Yaahoo 0]

Возьмите описалово от пары микроконтроллеров (к примеру stm32 и  tms320, для контраста) и почитайте как там регистры команды и статуса устроены, как в адресном пространстве располагаются. 

С точки зрения интерфейсов полезно будет почитать про тестовый интерфейс типа JTAG, как там теневой доступ к регистрам делается (BSR), и как это сделано у арма (swd). Хотя не понятно, нужен ли тестовый доступ, или обычный. Если обычный, то делайте как вам нравится, нет смысла что то копировать

 

Ну и по ключу post-silicon debug сразу приходит в голову DFT: scan, mbist и т.д. Это совсем другая тема, читать не перечитать

Так что непонятно, что именно нужно автору

Изменено 29 мая пользователем Yaahoo

[den_steppenwolf 0]

Спасибо за отклик!

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

Спасибо за подсказку, видится, что это не DFT или JTAG. bist используется всё-таки для проверки корректности чипа, а не мониторинга в процессе работы, как я понимаю.

[yes 5]

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

В общечеловеческих задачах подобное, например, запись операций по шине.

У АРМа это называется ETM ETB (embedded trace macrocel, embedded trace bufer), в опенсорсной GRLIB Gaisler называется AHB_TRACE (если не путаю).

В совсем запущеных случаях, можно вставить внутрь чипа логический анализатор типа альтеровского signaltap или ксайлинского chipscope, у гейслера есть и такое в опенсорсе (не помню как называется, поискать logic analyzer). Картинки можно в gtkwave смотреть. Я сам так не делал.

https://baical.net/up7.html  это софтверный проект, можно наверно, какие-то идеи, куски кода взять. Я когда-то над этим думал, но применить - не было проекта

[den_steppenwolf 0]

23 hours ago, yes said:

Так как поток гораздо больше...

Спасибо, полезная информация.

[one_eight_seven 6]

Если нужна трассировка, то посмотрите спецификацию на ATB.
Если нужно именно отслеживание статуса - посмотрите как в сетевых устройствах сделаны счётчики статистик в случае одиночного ускорителя или сервера статистик в случае множества ускорителей с централизованным управлением