Loki5000 0 13 июля, 2009 Опубликовано 13 июля, 2009 · Жалоба я разве что то говорил о нетлистах? вы смотрите слишком узко, повторюсь еще раз, на примере симулятора. А разве упомянутые вами vqm файлы это не "Verilog Quartus Mapping File"? Изъяснялись бы тогда без аббревиатур. т.е. заворачиваем ваши компоненты с конфигурируемыми шинами во врапперы заточенные под конкретную шину. Т.е. был компонент my_conf_ram_ctrl из которого торчат recordы/типы, а стало два компонента my_ram_ctrl_data_x8, my_ram_ctrl_data_x32 из которого торчат обычные типы общего применения (по сути расплетаем веник). создаем две либы my_ram_ctrl_data_x8_lib/my_ram_ctrl_data_x32_lib и компилируем контроллеры + настройки + враперы порознь. Имеем две функциональные модели для быстрого моделирования. По моему можно обойтись только одним враппером, т.к. проблема изначально состоит именно в совместном использовании двух блоков на одном уровне иерархии. Часть проекта, использующая одну из конфигурций, будет компилироваться для моделирования и синтезироваться в нетлист отдельно. И подключаться в проект уже в скомпелированном виде. Решение не самое удобное. Но все же это решение. Спасибо за идею! Все элементарно, просто и понятно, это же ООП в чистом виде :). Вы же делаете application specific проект, тащить туда конфигурируемые хвосты это лишний геморрой. Геморой только в данном случае. При использовании в одном проекте двух разных конфигураций. В остальных случаях ссылаться на одни и те же исходники из множества проектов, очень даже удобно. Даже удобнее чем: PS для 3-х проектов на основе общего ядра я веду 3 ветки разработки, когда нахожу ошибку в базовом ядре в какой либо ветке, то простой svn merge решает все проблемы на внесение изменений в другие Хотя так конечно тоже можно поступать. Похоже, решить задачу именно так, как Вы хотите можно только отказавшись от конфигурационного package и перейдя на использование generic. Правда, возможность такого перехода сильно зависит от содержимого package с типами сигналов. Да, можно было бы все-таки пойти по варианту 1 с unconstrained std_logic_vector. А в компонентах сажаемых на шину завести соответствующий generic. Но тут встает проблема с еще одним ограничением vhdl. unconstrained std_logic_vector нельзя использовать в record-e. Вы могли бы выложить оба package (конфигурационный и с типами сигналов) и описание топового Entity для шины? Поскольку решение желаемой Выми "красоты" если и можно найти, то только для конкретного примера. Приведу сразу "проблемные" строки: файл 'axi_config_pkg.vhd': constant c_XDataWidth : positive := 64; constant c_XWStrobeWidth : positive := 8; файл 'axi_pkg.vhd': subtype st_XData is std_logic_vector(c_XDataWidth - 1 downto 0); subtype st_XWStrob is std_logic_vector(c_XWStrobeWidth - 1 downto 0); type t_XWDCh is record WID : st_XID; WDATA : st_XData; WSTRB : st_XWStrob; WLAST : std_ulogic; end record; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 14 июля, 2009 Опубликовано 14 июля, 2009 · Жалоба А разве упомянутые вами vqm файлы это не "Verilog Quartus Mapping File"? Изъяснялись бы тогда без аббревиатур. дык я так и сказал, С точки зрения поддержки разных симуляторов проблем не вижу вообще, а как быть с альтеровским синтезатором расписал %) По моему можно обойтись только одним враппером, т.к. проблема изначально состоит именно в совместном использовании двух блоков на одном уровне иерархии. насколько я помню VHDL, передать generic в пакет нельзя, а у вас все построено на пакетах. так что ИМХО это будут два разных врапера, которым будут соответствовать два разных конфигурационных пакета. Геморой только в данном случае. При использовании в одном проекте двух разных конфигураций. В остальных случаях ссылаться на одни и те же исходники из множества проектов, очень даже удобно. повторюсь сорцы одни и те же, лежат они в одном месте. разными будут только обертки и конфигурационные враперы итого 4 новых файла. даже в SVN можно не создавать для них разные ветки, а ссылаться на одну с помошью svn::externals. ЗЫ. с разработкой на VHDL я давно завязал, так что могу ошибаться. если generic можно передать в package то тогда нужен будет только один файл - обертка. Удачи!!! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Loki5000 0 14 июля, 2009 Опубликовано 14 июля, 2009 · Жалоба ЗЫ. с разработкой на VHDL я давно завязал, так что могу ошибаться. если generic можно передать в package то тогда нужен будет только один файл - обертка. Вы правильно помните, generic в vhdl передать нельзя. Я не до конца понимаю в вашем предложении вот что: Например, библиотека c описанием типов шины называется Amba. Обе версии контроллера ссылаются на две разные копии библиотеки (по разному сконфигурированные). (т.е. содержат: use Amba.axi.all;) Тогда при компилировании первой библиотеки в QuestaSim мы получаем скомпилированную библиотеку Amba и my_ram_ctrl_data_x8_lib. Но ведь при компилировании второй библиотеки мы получаем опять скомпилированную библиотеку Amba и my_ram_ctrl_data_x16_lib. Т.е. у нас две скомпилированные библиотеки Amba. Как мы их можем подключить в один проект? Где я рассуждаю не правильно? :laughing: Может все станет ясно, если вы поясните мне, что именно вы подразумеваете под термином "compilation unit"? Из мануала к Квесте я понял, что фокус с "compilation unit" можно делать для system verilog. Цитата: "vlog -mfcu Instructs the compiler to treat all files within a compilation command line as a single compilation unit. Optional. The default behavior is to treat each file listed in a command as a separate compilation unit, per the SystemVerilog standard. Prior versions concatenated the contents of the multiple files into a single compilation unit by default." А как провернуть такое для vhdl? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 15 июля, 2009 Опубликовано 15 июля, 2009 · Жалоба Вы правильно помните, generic в vhdl передать нельзя. Т.е. у нас две скомпилированные библиотеки Amba. Как мы их можем подключить в один проект? Может все станет ясно, если вы поясните мне, что именно вы подразумеваете под термином "compilation unit"? расчехлил ракетку (все таки правильно сделал что ушел на SV %)) ), в атаче то что я имел в виду. Что бы посмотреть датафлоу выполните скрипт run.do. в итоге есть две либы lib_8/lib_16 из которых я беру только обертки с интерфейсами общего применения в либе work, которые при использовании я могу подключить к двум разным шинам, в моем проекте это могут быть dat_8_t/dat_16_t. А атаче я этих шин не делал, но думаю смысл будет и так понятен %) 2Loki5000.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Loki5000 0 16 июля, 2009 Опубликовано 16 июля, 2009 · Жалоба расчехлил ракетку (все таки правильно сделал что ушел на SV %)) ), в атаче то что я имел в виду. Что бы посмотреть датафлоу выполните скрипт run.do. Круто! :a14: Удивительно, но в мануале Квесты про то, что можно одну библиотеку мэпить на другую. (т.е. как у вас: vmap work lib_8) ни словечка не сказано! Написано только: "The vmap command defines a mapping between a logical library name and a directory by modifying the modelsim.ini file." А то, что вместо directory можно указывать имя другой библиотеки, ни словечка. Это как раз то, что я имел ввиду, когда писал в первом посте: "Возможно, этот недостаток можно обойти, если использовать ссылки на библиотеку work." Спасибо за помощь! Теперь буду применять предложенный метод к проекту. Возможно, всплывут еще какие-нибудь моменты. По результатам, отпишусь! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться