Как к реестру акционеров и определениям битового поля между драйвером устройства и FPGA это управляет

Question

Как к реестру акционеров и определениям битового поля между драйвером устройства и FPGA это управляет

забудьте усеченный и удалите. поддержите свои определения таблицы (в случае, если Вы хотите воссоздать его), и просто используйте таблицу отбрасывания.

8

c embedded driver device-driver vhdl

задан Tim Kryger 18 October 2009 в 19:41

5 ответов

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

Используйте YAML. (Или, вздох, XML, или даже очень простой DSL вашего дизайна.) Определите исходные данные. Напишите сценарии, чтобы вывести его как VHDL и C. Все языки сценариев поддерживают YAML, и он также разработан для анализа с помощью инструментов оболочки. Вы даже можете использовать упрощенный VHDL или C и написать сценарий, чтобы преобразовать его с помощью простого преобразования текста в соответствующий C или VHDL.
Сделайте все это в препроцессоре C. . Вы можете написать набор макросов вызовов , которые определяют макеты регистров. Тогда у вас может быть #if или, возможно, два отдельных . h файлы, которые определяют две разные версии ваших макросов определений: одна расширяется в VHDL, а другая расширяет те же определения в C.

0

ответ дан 5 December 2019 в 12:59

Вы можете взглянуть на doxygen , он поддерживает язык VHDL и, используя промежуточные файлы, вы сможете более или менее легко извлечь информацию. Побочным продуктом может быть документация по вашему RTL-коду.

Другой вариант - создать синтаксический анализатор C из определений Yacc / Lex, вы можете найти несколько здесь . Оттуда вы можете проанализировать VHDL, извлечь информацию (вам нужно будет определить, как получить определение ваших регистров) и создать файл заголовка C. Это, вероятно, довольно сложно.

Но на вашем месте я бы действительно поступил иначе и определил смещения регистров и поля в отдельном файле (например, в XML) и написал небольшой скрипт для генерации как заголовков C, так и Пакет VHDL,

5

ответ дан 5 December 2019 в 12:59

Our design group uses SystemRDL to capture the register definitions for our Programmable System-on-Chip. We use Denali Blueprint with customized scripts for the various targets - generate the register map, PDF documentation, Verification, C header files, etc.

We are not using it to generate the RTL source yet.

http://www.spiritconsortium.org/releases/SystemRDL
http://www.google.com/search?q=SystemRDL

2

ответ дан 5 December 2019 в 12:59

Я согласен с Марти, создавая собственные скрипты делать такие вещи весело, но в долгосрочной перспективе может быть проблематично.

Мы создали инструмент под названием IDesignSpec, который реализован в виде подключаемого модуля для редакторов документов, который позволяет вам указывать регистры в документе и генерировать заголовок C, VHDL, Verilog, OVM, VMM, IP-XACT, HTML, XML, SystemRDL. , PDF и др. Из него.

Вы можете создавать собственные выходные данные с помощью TCL API. Он может читать в различных входных форматах, таких как XML, IP-XACT, SystemRDL и т. Д.

Преимущество этого подхода в том, что у вас есть одна спецификация, и все автоматически синхронизируется.

В настоящее время поддерживаются следующие редакторы: MS Word 2003 и 2007, OpenOffice, StarOffice и FrameMaker.

Вы можете получить более подробную информацию на http://www.agnisys.com

Вот полный список доступных решений:

Название компании: Коммерческие инструменты (решение предоставляется)

Agnisys: IDesignSpec (плагин для Word / Excel / OpenOffice и интерфейс командной строки в Linux и Windows)
Atrenta: 1Team-Genesis-Registers (настольное приложение) -> Приобретено Synopsys. Инструмент недоступен.
Duolog: BitWise (приложение на основе Eclipse) -> Приобретено ARM, инструмент по-прежнему доступен.
PDTi: SpectaReg (веб-приложение) -> Инструмент больше не доступен.
Semifore: CSRCompiler (интерфейс командной строки)

Бесплатные инструменты / инструменты с открытым исходным кодом

Veripool: VRegs
ParadigmWorks: Spec2Reg

3

ответ дан 5 December 2019 в 12:59

Другие вопросы по тегам:

c embedded driver device-driver vhdl

Похожие вопросы:

score 2 · Accepted Answer

Я думаю, что финал, хотя это и мешало вам, направляет вас в правильном направлении. И я согласен с RedGlyph в том, что вам следует подумать о небольшом изменении рабочего процесса.

Вы думали о том, чтобы иметь один «главный документ» для информации вашего контрольного регистра и автоматически генерировать из него все - RTL, код тестовой среды, заголовки программного обеспечения драйвера и документацию?

Я работал над проектами, в которых была контрольная информация хранится в одной главной таблице, и все, что нам нужно, сгенерировано из этого. На одном семействе микросхем я написал несколько скриптов Python для генерации этого материала из файлов CSV, экспортированных из электронной таблицы. В другом проекте электронная таблица содержала макросы для создания файлов RTL и т. Д., Которые нам были нужны.

Написание собственных сценариев - это хорошо и хорошо, как и вы » иметь полный контроль над ними и знать, как они работают в деталях. Но помните, что вам нужно потратить время на поддержку этих скриптов и их обновление, чтобы делать новые вещи. И подумайте, что произошло бы, если бы тот, кто написал эти сценарии, решил пойти на новую работу - будет ли кто-нибудь еще достаточно знаком со сценариями, чтобы изменить их? Мы рассматриваем возможность покупки стороннего инструмента по причинам, упомянутым выше.

Я также работал над проектами, в которых документация и файлы заголовков были перенесены обратно из RTL - это был кошмар. Документация обычно отставала от дизайна, и часто поля управления «пропадали». Я бы предпочел больше не участвовать в таком проекте;)

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

Я также работал над проектами, в которых документация и файлы заголовков были перенесены обратно из RTL - это был кошмар. Документация обычно отставала от дизайна, и часто поля управления «пропадали». Я бы предпочел больше не участвовать в таком проекте;)

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

Я также работал над проектами, в которых документация и файлы заголовков были перенесены обратно из RTL - это был кошмар. Документация обычно отставала от дизайна, и часто поля управления «пропадали». Я бы предпочел больше не участвовать в таком проекте;)

Мы также работали над проектами, в которых документация и файлы заголовков были перенесены с RTL - это был кошмар. Документация обычно отставала от дизайна, и часто поля управления «пропадали». Я бы предпочел не участвовать в таком проекте снова;)

Мы также работали над проектами, где документация и файлы заголовков были перенесены из RTL - это был кошмар. Документация обычно отставала от дизайна, и часто поля управления «пропадали». Я бы предпочел не участвовать в таком проекте снова;)