Это конечно прозвучит весьма странно, однако даже сегодня не у всех тулов есть поддержка IP-XACT & SystemRDL.

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

Более того в некоторых метаописаниях предусматривается несколько полей доступа, например у SystemRDL их два: для HW и SW доступа, что лишь плодлливает масла в огонь.

Есть определенная категория тулов, которая поддерживает RTL-вывод только в VHDL. Однако большая часть тулов поддерживает RTL-вывод в SystemVerilog и VHDL. Pure Verilog в пролёте.

Т.е. я понимаю что систем-верилог - это модно, стильно, молодёжно, но такая оголтелая ориентация на SV как на основной RTL deliverables, а не на Verilog.. Сириусли?

Т.е. по замыслу разработчиков опен-сорс тулов для генерации карты регистров у вас нет денег на покупку коммерческого тула для генерации карты регистров, но есть деньги на покупку синтезатора и симулятора от $SNPS/$CDNS ??? Смехотворно!

Довольно распространённый сценарий, но я почему-то не смог найти поддержку его реализации у текущих тулов. Имею в виду кейс, когда ширина регистра/поля регистра превосходит ширину внутренней шины данных.

Вот допустим есть переменная value7[19:0], а доступ к шине данных - восьмибитный, т.о. надо переменную расположить в трёх соседних ячейках:

Т.е. гипотетический workaround понятен: можно описать регистр как три отдельных регистра с идентичным именем, но разными диапазонами бит, но в этом случае атрибуты и описание регистра надо будет продублировать дважды, что как-то не особо методологически правильно.

Другой пример: [записать|прочитать] [ключ|результат] шифрования размером 128 или 256 бит по шине 32-битного процессора.

Такое ощущение, что генераторы полей регистров ориентированы на всё что угодно, но не на автоматическое формирование документации следуя концепции единого источника.

Основные претензии:

Ну и на десерт самое экзотичное.

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

Вот, допустим, есть универсальный IP-блок: USB. И этот блок можно сконфигурировать как Host или как Device. Т.е. помимо значений по сбросу для полей регистров, метаописание будет иметь еще два значения на каждое поле: сценарий#1 (Host) и сценарий#2 (Device). В каких-то случаях (там где это необходимо) необходимо помимо самих значениях полей для сценария указывать еще и последовательность инициализации полей регистров: порядковым номером (если каждое поле должно быть проинициализировано в строгом порядке) или указанием зависимостей after и before от проинициализированных полей.

Помимо автоматической генерации документации с описанием сценариев работы и конфигурации, можно теже сценарии использовать для верификаци для быстрой настройки на определенный режим работы и для генерации Си-кода с последовательностью инициализации (для системных тестов или end user сценариев применения).