[Loki5000 0]

я разве что то говорил о нетлистах? вы смотрите слишком узко, повторюсь еще раз, на примере симулятора.

А разве упомянутые вами 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]

А разве упомянутые вами vqm файлы это не "Verilog Quartus Mapping File"?

Изъяснялись бы тогда без аббревиатур.

 

дык я так и сказал,

С точки зрения поддержки разных симуляторов проблем не вижу вообще

, а как быть с альтеровским синтезатором расписал %)

 

По моему можно обойтись только одним враппером, т.к. проблема изначально состоит именно в совместном использовании двух блоков на одном уровне иерархии.

 

насколько я помню VHDL, передать generic в пакет нельзя, а у вас все построено на пакетах. так что ИМХО это будут два разных врапера, которым будут соответствовать два разных конфигурационных пакета.

 

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

 

повторюсь сорцы одни и те же, лежат они в одном месте. разными будут только обертки и конфигурационные враперы итого 4 новых файла. даже в SVN можно не создавать для них разные ветки, а ссылаться на одну с помошью svn::externals.

 

ЗЫ. с разработкой на VHDL я давно завязал, так что могу ошибаться. если generic можно передать в package то тогда нужен будет только один файл - обертка.

 

Удачи!!!

[Loki5000 0]

ЗЫ. с разработкой на 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]

Вы правильно помните, generic в vhdl передать нельзя.

Т.е. у нас две скомпилированные библиотеки Amba. Как мы их можем подключить в один проект?

Может все станет ясно, если вы поясните мне, что именно вы подразумеваете под термином "compilation unit"?

 

расчехлил ракетку (все таки правильно сделал что ушел на SV %)) ), в атаче то что я имел в виду. Что бы посмотреть датафлоу выполните скрипт run.do.

 

в итоге есть две либы lib_8/lib_16 из которых я беру только обертки с интерфейсами общего применения в либе work, которые при использовании я могу подключить к двум разным шинам, в моем проекте это могут быть dat_8_t/dat_16_t. А атаче я этих шин не делал, но думаю смысл будет и так понятен %)

2Loki5000.zip

[Loki5000 0]

расчехлил ракетку (все таки правильно сделал что ушел на 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."

 

Спасибо за помощь!

Теперь буду применять предложенный метод к проекту. Возможно, всплывут еще какие-нибудь моменты.

По результатам, отпишусь!