Сборка и установка
Устанавливаем зависимости:
sudo yum install -y qt-devel qt5-qttools-devel qt5-qhelpgenerator
Скачиваем и собираем:
$ wget https://netcologne.dl.sourceforge.net/project/kactus2/kactus2-3.4.0.tar.gz $ tar xzf kactus2-3.4.0.tar.gz $ cd kactus2-3.4.0 $ ./configure Configuring Kactus2... Generating compressed help files... ./configure: line 21: qhelpgenerator: command not found ./configure: line 22: qcollectiongenerator: command not found Qmake not found. Please set variable QTBIN_PATH to Qt binary files.
Долго не мог понять в чём же дело, прописал все переменные:
export QTDIR=/usr/lib64/qt5 export QTINC=/usr/lib64/qt5/include export QTLIB=/usr/lib64/qt5/lib export QTBIN_PATH=/usr/lib64/qt5/bin
Однако по-прежнему не собиралось с тем же анамнезом, дело оказалось в том, что configure — простой баш-скрипт и там надо (для CentOS7) прописать вместо QTBIN_PATH=»» → QTBIN_PATH=»/usr/lib64/qt5/bin/» (последний слэш обязателен!). Теперь собираем еще раз:
./configure make sudo make install sudo ldconfig
Запускаем из CLI:
Kactus2
либо из меню Applications → Programming:
Использование
Основное использование Kactus2 мной — это набивка такой вот регистровой карты в xml:
Ниже некоторые рецепты и гайдлайны по заполнению регистровой карты согласно IEEE1685:
Для заполнения регистров полезно использовать следующие поля:
- Name — имя регистра
- Description — описание регистра
- Size — размерность регистра
- Offset — фактический адрес регистра в адресном пространстве СФ-блока
- Access — способ доступа к регистру
- Volatile — модифицируемость регистра со стороны СФ-блока (смысл схож с квалификатором volatile в эмбеддед-Си)
Note: даже если у регистра всего одно поле — оно должно быть заведено как поле
Для заполнения полей регистров полезно использовать следующие ключи:
- Name — имя поля
- Description — описание поля
- Width — размер поля
- Offset — значение младшего разряда поля по отношению к регистру (LSB поля)
- ! Access — способ доступа к полю: чтение/запись/чтение+запись (RW по умолчанию)
- ! Volatile — модифицируемость поля со стороны СФ-блока: да/нет (нет по умолчанию); смысл этого флага: может ли модифицироваться со стороны СФ-блока значение поля между двумя произвольными чтениями?
- ! Reset Value — значение по сбросу
- ! Modified Write Value (если применим) — указываем для поля, если запись 0/1 сбрасывает/устанавливает/переключает_на_противоположное биты поля, либо если любая запись приводит к сбросу/установке битов поля (всего 8 вариантов)
- ! Read Action (если применим) — указываем для поля, если операция чтения сбрасывает либо устанавливает биты поля
! — выделенное надо очень аккуратно и тщательно переносить из программной модели, в будущем это упростит и автогенерацию RTL и верификацию (по факту для полей описаны готовые ассершены).
В следующих частях опишу какой инструментарий я применяю для получения различных описаний из подготовленного таким способом xml согласно стандарта «IEEE-1685: Standard for IP-XACT, Standard Structure for Packaging, Integrating and Re-Using IP Within Tool-Flows».
Ссылки
- https://standards.ieee.org/getieee/1685/download/1685-2014.pdf— текст стандарта IEEE-1685:2014
- https://sourceforge.net/projects/kactus2/ — свободный инструментарий с GUI для набивки карты регистров