Перейти к содержанию
    

Vivado + Пользовательские IP

Добрый вечер уважаемые участники форума. Возник вопрос по работе с Vivado, в частности меня интересует создание пользовательских IP без упаковки их в core containter.

Попробую объяснить что я хочу получить:

 Давным давно, когда небо было голубее, трава зеленее я работал в Quartus. И там при создании своих ядер мне достаточно было написать простой TCL скрипт. Приведу пример простейшего скрипта SDRAM_CONTROLLER.qip

set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "SDRAM_PACKAGE.vhd"            ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "SDRAM_INITIAL.vhd"            ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "SDRAM_CMD_CONTROLLER.vhd"     ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "INPUT_OUTPUT_BUFFER.vhd"      ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "INPUT_FIFO.vhd"               ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "DELAY_CONTROLLER.vhd"         ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "DATA_CAPTURE_REG.vhd"         ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "KAA_COUNTER_ENA_SCLR.vhd"     ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "KAA_COUNTER_SLD.vhd"          ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "KAA_EDGE_DTCT.vhd"            ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "KAA_reset_bridge.vhd"         ]
set_global_assignment -library "SDRAM_CONTROLLER" -name VHDL_FILE [file join $::quartus(qip_path)   "SDRAM_CONTROLLER.vhd"         ]

И при создании нового проекта в котором мне бы потребовалось применить мой SDRAM контроллер - мне достаточно было подключить скрипт SDRAM_CONTROLLER.qip который бы подтянул все файлы контроллера. И самое замечательное, что не было бы никаких конфликтов с моими библиотечными файлами КАА_* Я в новом проекте мог применять свои библиотечные файлы без ограничений и без конфликтов повторяющихся имен, т.к одинаковые файлы принадлежат разным библиотекам. Такой подход позволял мне из разных проектов собрать более большой проект просто добавляя простейшие скрипты.

Сейчас я работаю с Vivado. У меня есть несколько больших проектов. Каждый из них состоит из моих библиотечных файлов,  из Xillinx IP, и из своих уникальных HDL описаний. Из этих проектов надо собрать более большой проект. Вот тут и появляются первые проблемы:

Для удобства переноса между устройствами я скопировал все исходники проектов в мой большой мега-проект и сразу-же натолкнулся на то, что у меня в проектах есть одинаковые библиотечные файлы, например "KAA_EDGE_DTCT.VHD" на что Vivado ругается. Более того я не могу в Vivado создать библиотеки с одинаковыми именами: https://www.xilinx.com/support/answers/52575.html

Упаковывать в отдельный IP Блок я не хочу. Ибо это неудобно, да я и не работаю в block design. Есть ли какое красивое решение моих проблем ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

4 hours ago, Flip-fl0p said:

Vivado ругается. Более того я не могу в Vivado создать библиотеки с одинаковыми именами

Мне почему то всегда казалось что в проекте не может быть несколько  library с одинаковым именем. А иначе как понять из какой library брать соответствующий entity?

4 hours ago, Flip-fl0p said:

Упаковывать в отдельный IP Блок я не хочу. Ибо это неудобно, да я и не работаю в block design. Есть ли какое красивое решение моих проблем ?

Упаковка в IP  не обязательно подразумевает работу в BD.  Вы также можете генерировать свои корки и включать их непосредственно в  RTL. 
Думаю что без упаковки в IP  тут вам не обойтись.  Хотя  полноценной заменой .qip   это не будет.  Так как .qip  автоматизирует добавление  исходников  в общий список файлов проекта. А  IP корки в Vivado нужно  генерировать с заданными параметрами перед использованием в синтезе.
То есть  RTL параметры из модуля где эта корка используется динамически в корке не изменить. :negative:

Как вариант видится:

добавление файлов в проект своим  скриптом который парсит ваши .qip и создает в проекте нужную структуру библиотек 

работа в Vivado  в non-project режиме - в таком случае вы в tcl скрипте  можете напрямую  включать существующие .qip файлы. 

 

Ну либо экзотический путь -  hook-нуть стандартные функции Vivado  типа synth_design. А в своей  обертке hook_synth_design  парсить  список файлов  проекта  для синтеза,   выделять от туда .qip файлы  которые добавлены в Vviado проект (например как data или memory initialization type).  Парсить эти .qip и динамически добавлять исходники в проект перед вызовом родной synth_design функции. (вот это я навернул  :wacko2:)

Удачи! Rob.

 

P.S.  Только что проверил эту бредовую идею  - и ведь  работает!   Можно будет подшутить над коллегами - смотри мол - в списке файлов проекта исходника нет,  а  проект собирается без ошибок :biggrin: 

hierchy.thumb.png.84e8a89631ca6f088eb35b96a7d40eb0.png

Quote

Hook of synth_design ...
...
>> file src: D:/_wrk_/_temp_/src/test.qip
test.qip>> read_verilog -library work -sv ${QIP_DIR}/tst_mod.sv
WARNING: [filemgmt 56-99] Vivado Synthesis ignores library specification for Verilog or SystemVerilog files. [D:/_wrk_/_temp_/src/tst_mod.sv:]
>> file src: D:/_wrk_/_temp_/src/test_if1.sv
>> file src: D:/_wrk_/_temp_/src/his_25.sv
Command: ::synth_design_ -top test_if1 -part xc7s100fgga676-2
...
synth_design completed successfully
...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, RobFPGA сказал:

 

Спасибо за ответ. Уже поздно. Осмысливать ответ буду завтра с утра (вернее уже сегодня :biggrin:)

Я немного ошибся:

Цитата

Vivado ругается. Более того я не могу в Vivado создать библиотеки с одинаковыми именами

Я имел ввиду создать разные библиотеки (каждая библиотека под проект) но в разных библиотеках могут быть файлы с одинаковым именем. Мало ли у меня есть компонент например KAA_RANDOM_GEN, который был создан давным давно. И успешно работает в проекте. А потом он был по какой-то причине изменен. И вдруг мне понадобилось слить два проекта с одинаковыми именами исходников в один большой. И чтобы каждый более мелкий проект в итоге работал со своим библиотечным компонентом. Что-бы мне не приходилось заменять старый исходник более новым, который может сломать, давно работающий и проверенный проект.

Цитата

То есть  RTL параметры из модуля где эта корка используется динамически в корке не изменить.

Под динамическим изменением Вы имели ввиду передачу параметров из HDL ?

Просто как я понимаю изменить его можно, но для этого требуется как и для всякого IP вручную настроить его параметры и только потом использовать в HDL.

Цитата

добавление файлов в проект своим  скриптом который парсит ваши .qip и создает в проекте нужную структуру библиотек 

Просто мне не понравилась идея с библиотеками в Vivado тем, что стандартная рабочая библиотека в Viavado work. (xil_defaultlib). Работая с проектом у меня все компоненты подключаются  напрямую,например:  KAA_RANDOM_GEN_comp : entity work.KAA_RANDOM_GEN 

Когда я объединяю два проекта. Я вынужден для каждого проекта настраивать своё уникальное имя библиотеки. И вот тут наступает главная засада. Объявляя библиотеки с исходниками например LIB_PRJ_A и LIB_PRJ_B. Я ожидаю, что каждый проект будет автоматически применять свои компоненты LIB_PRJ_A.KAA_RANDOM_GEN  и LIB_PRJ_B.KAA_RANDOM_GEN

А этого не происходит потому-что в исходниках у меня написано  KAA_RANDOM_GEN_comp : work.KAA_RANDOM_GEN. Поэтому я вынужден ещё в момент создания проекта давать какое-то уникальное название для библиотеки, компонентов. А вот это мне не очень нравится. Вернее совсем не нравится. Хотя это решение. Но очень некрасивое.

P.S. 

Цитата

Можно будет подшутить над коллегами - смотри мол - в списке файлов проекта исходника нет,  а  проект собирается без ошибок :biggrin: 

У меня такая фигня происходит если у меня есть компонент, который генерируется или нет в зависимости от настроек компонента верхнего уровня. Из-за этого я не могу напрямую в BD подключать свои исходники. Нужно создавать своё упакованное IP для таких компонентов. Жутко бесит.
Это одна из нескольких причин почему я не работаю в BD.

 

VIVADOOOOOO.PNG

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

1 hour ago, Flip-fl0p said:

Под динамическим изменением Вы имели ввиду передачу параметров из HDL ?

Да - это основное что сложно делать в Vivado  при использовании концепции IP ядер. 

1 hour ago, Flip-fl0p said:

Просто мне не понравилась идея с библиотеками в Vivado тем, что стандартная рабочая библиотека в Viavado work. (xil_defaultlib). Работая с проектом у меня все компоненты подключаются  напрямую например  KAA_RANDOM_GEN_comp : entity work.KAA_RANDOM_GEN 
...
А этого не происходит потому-что в исходниках у меня написано  KAA_RANDOM_GEN_comp : work.KAA_RANDOM_GEN. Поэтому я вынужден ещё в момент создания проекта давать какое-то уникальное название для библиотеки, компонентов. А вот это мне не очень нравится. Вернее совсем не нравится. Хотя это решение. Но очень некрасивое.

Понятие красоты оно такое разное :yes3: Как по мне отдельный функционал  в отдельные библиотеки как раз красивое решение (и легко реюзабельное).

Я на VHDL  почти не пишу, но мне кажется что тут  у вас проблемы не с библиотеками, а с организацией структуры проектов. Если вы несколько разных проектов хотите свалит в общую кучу work  то  ясень пень в нем не могут быть одинаковые entity.  Да и в Qu  у вас же в qip указывается имя библиотеки куда компилируются исходник. То как оно будет работать если в вашем исходнике  будет референс на work а не на эту library,  разве найдется нужный entity?  

Так что тут либо отдельные проекты растягивать по отделенным library (и менять референс work в них на имя проектной library).  Либо компилировать эти суб-проекты как отдельные сущности (как IP или отдельные проекты). 
Ну или может поможет  еще какая магия VHDL типа configurations.  Но что то я сомневаюсь в этом.

Удачи! Rob. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нашёл шикарную статью https://habr.com/ru/post/308962/

Путем изучения гугла и этой статьи я написал простенький скрипт: 

set lib_name prj_a
set script_path [ file dirname [ file normalize [ info script ] ] ]
cd $script_path

add_files -norecurse {
	KAA_edge_dtct.vhd
	KAA_unsigned_cnt.vhd
	EDGE0.vhd
}
set_property library $lib_name [get_files  {
	KAA_edge_dtct.vhd
	KAA_unsigned_cnt.vhd
	EDGE0.vhd
}]

Оказывается если я абсолютно все исходники проекта запихаю в отдельную библиотеку. То будет всё как я и хочу. Скрипт фактически полный аналог .qip. 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

4 minutes ago, Flip-fl0p said:

Оказывается если я абсолютно все исходники проекта запихаю в отдельную библиотеку. То будет всё как я и хочу. Скрипт фактически полный аналог .qip. 

Ну так я об таком и писал  

11 hours ago, RobFPGA said:

... добавление файлов в проект своим  скриптом который парсит ваши .qip и создает в проекте нужную структуру библиотек 

У меня такой скрипт просто берет готовые  qip из проекта в Qu  и автоматом импортирует все фалы из них  в проект для Vivado с нужной структурой библиотек.

Удачи! Rob

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Появилась новая неприятная особенность. 

Например у меня есть 3 одинаковых HDL описания в разных библиотеках:

project_lib_a.KAA_reset_bridge.

project_lib_b.KAA_reset_bridge.

project_lib_c.KAA_reset_bridge.

Подключая в Verilog модуль, модуль написанный на VHDL, я просто подключаю модуль как verilog описание:

KAA_reset_bridge #
(
     .sync_stages         ( 3        ),
     .input_active_level  ("Negative"),  // "Negative" / "Positive"     Входной  активный уровень асинхронного сброса
     .output_active_level ("Negative")   // "Negative" / "Positive"     Выходной активный уровень асинхронного сброса
)
KAA_reset_bridge_inst
(
     .clk                ( JESD_rx_clk          ),
     .asy_reset_in       ( ~break_work & resetn ),
     .reset_sync_clk     ( resetn_sync          )
);

 

По-умолчанию Vivado пытается найти модуль из библиотеки проекта xil_defaultlib. Если не нашел, то берет первый попавшийся модуль с нужным названием :dash2:

Как мне явно указать в Verilog из какой библиотеки подцепить мой модуль ? 

Пока не нашел ничего лучше, чем создать VHDL wrapper, который помещается в библиотеку  xil_defaultlib, в котором уже идет явное указание брать файл из конкретной библиотеки. Получается какая-то порнография когда проект состоит из смешанных языков HDL.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

Можно было бы попробовать  перемешать эту кашу ложечкой  `uselib   чтобы не "пригорало"  :biggrin:

...
`uselib lib=test_e1
test_e #(...) i_test_e1 (
...
);

`uselib lib=test_e2
test_e #(...) i_test_e2 (
...
);

`uselib // xil_default
test_e #(...) i_test_e3 (
...
);

Но вот беда - похоже что в Vivado  для синтеза это не работает  :cray:(и наверное не  только в Vivado) .
Хоть при этом и пишет в дереве проекта правильное назначение на разные library но при синтезе  цепляет только тот модуль который первый по порядку синтеза. Остальные, с одинаковым именем  entity, вообще не синтезируются. :unknw:

Так что IMHO  путь героев-врапперов тут  самое то  :wink:

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Когда столкнулся с похожей проблемой, не пожалел времени и переделал все, по принципу : 1 модуль - 1 файл. Имя уникально. За все остальное расстрел. Прошло много времени, пока не пожалел о своем выборе) 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, des00 сказал:

Когда столкнулся с похожей проблемой, не пожалел времени и переделал все, по принципу : 1 модуль - 1 файл. Имя уникально. За все остальное расстрел. Прошло много времени, пока не пожалел о своем выборе) 

+100

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 часов назад, des00 сказал:

Когда столкнулся с похожей проблемой, не пожалел времени и переделал все, по принципу : 1 модуль - 1 файл. Имя уникально. За все остальное расстрел. Прошло много времени, пока не пожалел о своем выборе) 

Но ведь в процессе работы у Вас образовалась собственная библиотека ?

Вопрос в том, как быстро и удобно из собственных IP , которые могут состоять как из библиотечных элементов собственной разработки, так и из IP от Xilinx, собрать рабочий проект. Чтобы можно было спокойно взять свои IP и из них создать новый проект. При этом хочется чтобы проект можно было собрать из готовых деталей без применения напильника. Я беру IP  который для меня чёрный ящик. Я просто беру его и подключаю к своему проекту не задумываясь над его внутренним наполнением. Не задумываясь с тем, что там могут быть файлы с такими же именами как и у меня. Потом когда я закончу свою работу - я передаю все это дело дальше... Вот я и думаю над простой системой организации проектов. Чтобы было легко, понятно. И удобно.

Иногда бывает так, что два куска одного проекта разрабатываются разными людьми и коллега сделал своё ядро в достаточной степени, чтобы я мог его подключить к своему проекту и отлаживать свою часть. Но проект ещё сырой и там куча всякого мусора: ненужные исходники, ненужные Xilinx ip  и пр. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

2 minutes ago, Flip-fl0p said:

Вопрос в том, как быстро и удобно из собственных IP , которые могут состоять как из библиотечных элементов собственной разработки, так и из IP от Xilinx, собрать рабочий проект.

Вот как раз  концепция IP корок  в Vivado и подразумевает   работу с независимыми subмодулями IP корок  которые  выступают в вашем проекте как black-box. Тоесть  - вы или кто другой  создал такую корку, отладил, и упаковал в IP.
А вы в своем проекте их используете как кирпичики. Плюс к этому режим out-of-context ускоряет сборку так как результат синтеза такого независимого модуля можно  положить  как compile point .dcp в локальный или даже в обший на фирму кэш корок.  
Но повторюсь -  такая концепция не вяжется со сквозной  конфигурацией RTL через parameter/generic. Приходится выносить такую конфигурацию на уровень tcl скрипта. Тут уж вам решать как удобнее организовывать проект и делить его на гибко-RTLную  и кирпично-корочную часть :sorry2:

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 hours ago, Flip-fl0p said:

 Но ведь в процессе работы у Вас образовалась собственная библиотека ?

Вопрос в том, как быстро и удобно из собственных IP , которые могут состоять как из библиотечных элементов собственной разработки, так и из IP от Xilinx, собрать рабочий проект. Чтобы можно было спокойно взять свои IP и из них создать новый проект. При этом хочется чтобы проект можно было собрать из готовых деталей без применения напильника. Я беру IP  который для меня чёрный ящик. Я просто беру его и подключаю к своему проекту не задумываясь над его внутренним наполнением. Не задумываясь с тем, что там могут быть файлы с такими же именами как и у меня. Потом когда я закончу свою работу - я передаю все это дело дальше... Вот я и думаю над простой системой организации проектов. Чтобы было легко, понятно. И удобно.

Иногда бывает так, что два куска одного проекта разрабатываются разными людьми и коллега сделал своё ядро в достаточной степени, чтобы я мог его подключить к своему проекту и отлаживать свою часть. Но проект ещё сырой и там куча всякого мусора: ненужные исходники, ненужные Xilinx ip  и пр. 

Конечно образовалась и все в соответствии с тем самым правилом: 1 модуль - 1 уникальное имя. Вам в команде нужен библиотекарь, т.е. человек, задача которого будет вести библиотеку общих компонентов, использовать которую должны все разработчики. Есть даже книги посвящённые построению команд для разработки, там есть перечень обязательных в команде лиц) 

Сама команда должна выработать соглашение об именах и четко его придерживаться. Например, если ковыряли выложенные здесь мои проекты, можно заметить что у rtl файлов, представляющих из себя корку, одинаковый префикс. Это исключает конфликт модулей при использовании корки в режиме чистого RTL (кстати подобный же подход, есть в декриптованных корках от альтеры. даже тривиальные вещи делаются в файлах с уникальным именем с префиксом проекта). 

Ну и RobFPGA правильно говорит, если у вас такие конфликты, значит вам нужно уходить на работу с черными ящиками и сборки из предкомпилированных корок. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...