Flip-fl0p 4 8 апреля, 2020 Опубликовано 8 апреля, 2020 · Жалоба Добрый вечер уважаемые участники форума. Возник вопрос по работе с 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. Есть ли какое красивое решение моих проблем ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 8 апреля, 2020 Опубликовано 8 апреля, 2020 · Жалоба Приветствую! 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 параметры из модуля где эта корка используется динамически в корке не изменить. Как вариант видится: добавление файлов в проект своим скриптом который парсит ваши .qip и создает в проекте нужную структуру библиотек работа в Vivado в non-project режиме - в таком случае вы в tcl скрипте можете напрямую включать существующие .qip файлы. Ну либо экзотический путь - hook-нуть стандартные функции Vivado типа synth_design. А в своей обертке hook_synth_design парсить список файлов проекта для синтеза, выделять от туда .qip файлы которые добавлены в Vviado проект (например как data или memory initialization type). Парсить эти .qip и динамически добавлять исходники в проект перед вызовом родной synth_design функции. (вот это я навернул ) Удачи! Rob. P.S. Только что проверил эту бредовую идею - и ведь работает! Можно будет подшутить над коллегами - смотри мол - в списке файлов проекта исходника нет, а проект собирается без ошибок 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 ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 9 апреля, 2020 Опубликовано 9 апреля, 2020 · Жалоба 1 час назад, RobFPGA сказал: Спасибо за ответ. Уже поздно. Осмысливать ответ буду завтра с утра (вернее уже сегодня ) Я немного ошибся: Цитата 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. Цитата Можно будет подшутить над коллегами - смотри мол - в списке файлов проекта исходника нет, а проект собирается без ошибок У меня такая фигня происходит если у меня есть компонент, который генерируется или нет в зависимости от настроек компонента верхнего уровня. Из-за этого я не могу напрямую в BD подключать свои исходники. Нужно создавать своё упакованное IP для таких компонентов. Жутко бесит. Это одна из нескольких причин почему я не работаю в BD. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 9 апреля, 2020 Опубликовано 9 апреля, 2020 · Жалоба Приветствую! 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. Поэтому я вынужден ещё в момент создания проекта давать какое-то уникальное название для библиотеки, компонентов. А вот это мне не очень нравится. Вернее совсем не нравится. Хотя это решение. Но очень некрасивое. Понятие красоты оно такое разное Как по мне отдельный функционал в отдельные библиотеки как раз красивое решение (и легко реюзабельное). Я на VHDL почти не пишу, но мне кажется что тут у вас проблемы не с библиотеками, а с организацией структуры проектов. Если вы несколько разных проектов хотите свалит в общую кучу work то ясень пень в нем не могут быть одинаковые entity. Да и в Qu у вас же в qip указывается имя библиотеки куда компилируются исходник. То как оно будет работать если в вашем исходнике будет референс на work а не на эту library, разве найдется нужный entity? Так что тут либо отдельные проекты растягивать по отделенным library (и менять референс work в них на имя проектной library). Либо компилировать эти суб-проекты как отдельные сущности (как IP или отдельные проекты). Ну или может поможет еще какая магия VHDL типа configurations. Но что то я сомневаюсь в этом. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 9 апреля, 2020 Опубликовано 9 апреля, 2020 · Жалоба Нашёл шикарную статью : 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 9 апреля, 2020 Опубликовано 9 апреля, 2020 · Жалоба Приветствую! 4 minutes ago, Flip-fl0p said: Оказывается если я абсолютно все исходники проекта запихаю в отдельную библиотеку. То будет всё как я и хочу. Скрипт фактически полный аналог .qip. Ну так я об таком и писал 11 hours ago, RobFPGA said: ... добавление файлов в проект своим скриптом который парсит ваши .qip и создает в проекте нужную структуру библиотек У меня такой скрипт просто берет готовые qip из проекта в Qu и автоматом импортирует все фалы из них в проект для Vivado с нужной структурой библиотек. Удачи! Rob Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 12 апреля, 2020 Опубликовано 12 апреля, 2020 · Жалоба Появилась новая неприятная особенность. Например у меня есть 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. Если не нашел, то берет первый попавшийся модуль с нужным названием Как мне явно указать в Verilog из какой библиотеки подцепить мой модуль ? Пока не нашел ничего лучше, чем создать VHDL wrapper, который помещается в библиотеку xil_defaultlib, в котором уже идет явное указание брать файл из конкретной библиотеки. Получается какая-то порнография когда проект состоит из смешанных языков HDL. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 12 апреля, 2020 Опубликовано 12 апреля, 2020 · Жалоба Приветствую! Можно было бы попробовать перемешать эту кашу ложечкой `uselib чтобы не "пригорало" ... `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 для синтеза это не работает (и наверное не только в Vivado) . Хоть при этом и пишет в дереве проекта правильное назначение на разные library но при синтезе цепляет только тот модуль который первый по порядку синтеза. Остальные, с одинаковым именем entity, вообще не синтезируются. Так что IMHO путь героев-врапперов тут самое то Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 13 апреля, 2020 Опубликовано 13 апреля, 2020 · Жалоба Когда столкнулся с похожей проблемой, не пожалел времени и переделал все, по принципу : 1 модуль - 1 файл. Имя уникально. За все остальное расстрел. Прошло много времени, пока не пожалел о своем выборе) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 13 апреля, 2020 Опубликовано 13 апреля, 2020 · Жалоба 1 час назад, des00 сказал: Когда столкнулся с похожей проблемой, не пожалел времени и переделал все, по принципу : 1 модуль - 1 файл. Имя уникально. За все остальное расстрел. Прошло много времени, пока не пожалел о своем выборе) +100 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 13 апреля, 2020 Опубликовано 13 апреля, 2020 · Жалоба 9 часов назад, des00 сказал: Когда столкнулся с похожей проблемой, не пожалел времени и переделал все, по принципу : 1 модуль - 1 файл. Имя уникально. За все остальное расстрел. Прошло много времени, пока не пожалел о своем выборе) Но ведь в процессе работы у Вас образовалась собственная библиотека ? Вопрос в том, как быстро и удобно из собственных IP , которые могут состоять как из библиотечных элементов собственной разработки, так и из IP от Xilinx, собрать рабочий проект. Чтобы можно было спокойно взять свои IP и из них создать новый проект. При этом хочется чтобы проект можно было собрать из готовых деталей без применения напильника. Я беру IP который для меня чёрный ящик. Я просто беру его и подключаю к своему проекту не задумываясь над его внутренним наполнением. Не задумываясь с тем, что там могут быть файлы с такими же именами как и у меня. Потом когда я закончу свою работу - я передаю все это дело дальше... Вот я и думаю над простой системой организации проектов. Чтобы было легко, понятно. И удобно. Иногда бывает так, что два куска одного проекта разрабатываются разными людьми и коллега сделал своё ядро в достаточной степени, чтобы я мог его подключить к своему проекту и отлаживать свою часть. Но проект ещё сырой и там куча всякого мусора: ненужные исходники, ненужные Xilinx ip и пр. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 13 апреля, 2020 Опубликовано 13 апреля, 2020 · Жалоба Приветствую! 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ную и кирпично-корочную часть Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 14 апреля, 2020 Опубликовано 14 апреля, 2020 · Жалоба 9 hours ago, Flip-fl0p said: Но ведь в процессе работы у Вас образовалась собственная библиотека ? Вопрос в том, как быстро и удобно из собственных IP , которые могут состоять как из библиотечных элементов собственной разработки, так и из IP от Xilinx, собрать рабочий проект. Чтобы можно было спокойно взять свои IP и из них создать новый проект. При этом хочется чтобы проект можно было собрать из готовых деталей без применения напильника. Я беру IP который для меня чёрный ящик. Я просто беру его и подключаю к своему проекту не задумываясь над его внутренним наполнением. Не задумываясь с тем, что там могут быть файлы с такими же именами как и у меня. Потом когда я закончу свою работу - я передаю все это дело дальше... Вот я и думаю над простой системой организации проектов. Чтобы было легко, понятно. И удобно. Иногда бывает так, что два куска одного проекта разрабатываются разными людьми и коллега сделал своё ядро в достаточной степени, чтобы я мог его подключить к своему проекту и отлаживать свою часть. Но проект ещё сырой и там куча всякого мусора: ненужные исходники, ненужные Xilinx ip и пр. Конечно образовалась и все в соответствии с тем самым правилом: 1 модуль - 1 уникальное имя. Вам в команде нужен библиотекарь, т.е. человек, задача которого будет вести библиотеку общих компонентов, использовать которую должны все разработчики. Есть даже книги посвящённые построению команд для разработки, там есть перечень обязательных в команде лиц) Сама команда должна выработать соглашение об именах и четко его придерживаться. Например, если ковыряли выложенные здесь мои проекты, можно заметить что у rtl файлов, представляющих из себя корку, одинаковый префикс. Это исключает конфликт модулей при использовании корки в режиме чистого RTL (кстати подобный же подход, есть в декриптованных корках от альтеры. даже тривиальные вещи делаются в файлах с уникальным именем с префиксом проекта). Ну и RobFPGA правильно говорит, если у вас такие конфликты, значит вам нужно уходить на работу с черными ящиками и сборки из предкомпилированных корок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться