Nick_K 0 11 декабря, 2019 Опубликовано 11 декабря, 2019 · Жалоба On 11/29/2019 at 12:49 PM, RobFPGA said: Вообще для TCL есть стандартная технология package которая позволяет управлять иерархией проекта на tcl. Извиняюсь за доставучесть, но может есть где-то документация или гайд какой, как и куда пихать пакеты для Вивады, а также покрытие вопросов с глобальными перемеными и т.д.? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 11 декабря, 2019 Опубликовано 11 декабря, 2019 · Жалоба Приветствую! 36 minutes ago, Nick_K said: Извиняюсь за доставучесть, но может есть где-то документация или гайд какой, как и куда пихать пакеты для Вивады, а также покрытие вопросов с глобальными перемеными и т.д.? Основной гайд для Vivado Tcl это UG835 (Command Reference Guide) и UG894 (Using Tcl Scripting). Второй как раз и рассказывает как правильно делать скрипты для Vivado. Естественно и доки по самому TCL. В Vivado tcl позволяет легко дописать и интегрировать свой функционал в инструментарий оболочки. Тут главное понять основные принципы работы. Например то что enviroment при работе в GUI и при запуске процессов Synthesis/P&R из под GUI - разный. Но при этом каждый этот процесс в самом начале грузит Vivado_init.tcl Соответственно в Vivado_init можно напихать своих процедур кастомизации/автоматизации Vivado. Например навешать hook-ов на стандартные процедуры (open_project, close_project, ...). У меня например на open_project вешается hook который в папке рядом с файлом открываемого *.xpr ищет дополнительный *.tcl в котором лежать настройки/хелперы для этого конкретного проекта. Так же и для "глобальных" переменных. Но IMHO лучше делать так чтобы таких, реально глобальных переменных, было как можно меньше. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 11 декабря, 2019 Опубликовано 11 декабря, 2019 · Жалоба 1 hour ago, RobFPGA said: Например то что enviroment при работе в GUI и при запуске процессов Synthesis/P&R из под GUI - разный Это я уже понял. И даже когда запускается через скрипт, вход в синтезируемый проект и имплементированый тоже разный с разными возможностями и функционалом. 1 hour ago, RobFPGA said: Но при этом каждый этот процесс в самом начале грузит Vivado_init.tcl Соответственно в Vivado_init можно напихать своих процедур кастомизации/автоматизации Vivado. По вышеуказанными ЮГ я это тоже нашёл. Только возникает вопрос: что делать если проект нужно запустить на "чужой" машине? Руками "пакостить в ихний инит или есть возможность в процессе билда скриптом, задать нужные параметры/указать пути/etc так чтобы и мне было комфортно и потом долго не искать чего не пашет на другом компе. 1 hour ago, RobFPGA said: Например навешать hook-ов на стандартные процедуры (open_project, close_project, ...) Собсттвеноо это мне и интересно. Сначала я думал сделать обёртки для данных процедур и запускать всё через тикль файлы, но теперь вижу, что в этом вопросе я чень много чего не знаю/не понимаю... И прочтение ЮГ сильно ясности не приносят увы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 11 декабря, 2019 Опубликовано 11 декабря, 2019 · Жалоба Приветствую! 21 hours ago, Nick_K said: ... Только возникает вопрос: что делать если проект нужно запустить на "чужой" машине? ... или есть возможность в процессе билда скриптом, задать нужные параметры/указать пути/etc ... Для чужой машины это единственный путь (хотя вроде как Vivado_init.tcl локальный для user). Ну и плюс еще статическая конфигурация через enviroment переменные. Например стандартная для TCL переменная TCLLIBPATH. Указываем (или добавляем) в ней путь к своей папке с tcl-наворотами set TCLLIBPATH=path_to_dsn/dsn/tcl_lib А в папке tcl_lib кладем pkgIndex.tcl В котором ссылки на свои package Spoiler # pkgIndex.tcl package ifneeded my_pkg 1.0 [list source -quiet [file join $dir .../my_pkg.tcl]] ... # my_pkg.tcl package provide my_pkg 1.0 namespace eval ::my_pkg { namespace export version ... variable MY_PKG_VERSION 1.0 variable REL_PKG_DIR [relative_path [file dirname [info script]] [pwd]] ... } proc my_pkg::version {} { puts ">> my_pkg version:$my_pkg::MY_PKG_VERSION, path:'$my_pkg::REL_PKG_DIR' relative to '[pwd]'" } ... И теперь при запуске Vivado (равно как и любого другого TCL интерпретатора) командой package require my_pkg в начале своего скрипта грузим процедуры из my_pkg в рабочую область, хукаем стандартные процедуры, добавляем переменные, .... в общем развлекаемся как можем. Успехов! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitus_strom 0 11 декабря, 2019 Опубликовано 11 декабря, 2019 · Жалоба В вивадо каждая стадия имеет в настройка tcl.pre и tcl.post... То есть перед и после синтеза, ининциализацииб оптимизации, повер оптимизации, плейса, пост плейс повер оптимизации, пост плейс физической оптимизации, рутинга пост рут физичесокй оптимизации и записи битстрима можно воткнуть свои скрипты. Может это как то Вам поможет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 12 декабря, 2019 Опубликовано 12 декабря, 2019 · Жалоба 14 hours ago, vitus_strom said: В вивадо каждая стадия имеет в настройка tcl.pre и tcl.post... Да, спасибо, я знаю) Но тут дело обстоит с необходимостью влезть именно в стандартный поток синтезирования или имплементации. К примеру развести часть схемы первее, чем всё остальное. Это не преИмплемент и не постСинтез. Вот и приходится придумывать как лезть в недри и хукать нужные процессы/скрипты Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 12 декабря, 2019 Опубликовано 12 декабря, 2019 · Жалоба Приветствую! 50 minutes ago, Nick_K said: Но тут дело обстоит с необходимостью влезть именно в стандартный поток синтезирования или имплементации. К примеру развести часть схемы первее, чем всё остальное. IMHO для этого лучше пользовать non-project mode. Тут вам никто не мешает скриптами рулить процессом так как нравится. Причем запускать эти скрипты можно и из под GUI Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 12 декабря, 2019 Опубликовано 12 декабря, 2019 · Жалоба 1 hour ago, RobFPGA said: IMHO для этого лучше пользовать non-project mode. Тут вам никто не мешает скриптами рулить процессом так как нравится. Причем запускать эти скрипты можно и из под GUI Это я понимаю, но вот упомянутые hook'и не дают спать спокойно. Жаль временно пришлось поставить данный таск на паузу Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 12 декабря, 2019 Опубликовано 12 декабря, 2019 · Жалоба Приветствую! 1 hour ago, Nick_K said: Это я понимаю, но вот упомянутые hook'и не дают спать спокойно. Пишете что-то подобное в Vivado_init.tcl и спите спокойно ### proc hook_proc {name hook_name} { if {[llength [namespace which {${name}_}]]==0} { rename ::${name} ::${name}_ rename ${hook_name} ::${name} } } ### proc hook_synth_design args { puts "Hook of synth_design ..." # processing input options for {set ii 0} {$ii < [llength $args]} {incr ii} { set option [string trim [lindex $args $ii]] puts ">> synth_design: $option" } set top_run [current_run -synthesis] set top_fset [get_property SRCSET $top_run ] set top_name [get_property TOP $top_fset] puts ">> synth_design: current_project property ..." set str [report_property -return_string [current_project]] puts "$str\n" puts ">> synth_design: current_run property ..." set str [report_property -return_string $top_run] puts "$str\n" puts ">> synth_design: current_fileset property ..." set str [report_property -return_string $top_fset] puts "$str\n" uplevel 1 ::synth_design_ $args } ... hook_proc "open_project" "hook_open_project" hook_proc "synth_design" "hook_synth_design" ... Хотя если повесить коллеге на open_project такой hook "... puts "Happy new Year!"; file delete -force $prj_file; ..." сна вам точно не видать Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться