Редактор tcl

[Nick_K 0]

On 11/29/2019 at 12:49 PM, RobFPGA said:

Вообще для TCL есть стандартная технология  package  которая позволяет управлять иерархией  проекта на tcl.

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

[RobFPGA 0]

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

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]

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 0]

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

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]

В вивадо каждая стадия имеет в настройка tcl.pre и tcl.post... То есть перед и после синтеза, ининциализацииб оптимизации, повер оптимизации, плейса, пост плейс повер оптимизации, пост плейс физической оптимизации, рутинга пост рут физичесокй оптимизации и записи битстрима можно воткнуть свои скрипты.  Может это как то Вам поможет?

[Nick_K 0]

14 hours ago, vitus_strom said:

В вивадо каждая стадия имеет в настройка tcl.pre и tcl.post...

Да, спасибо, я знаю) Но тут дело обстоит с необходимостью влезть именно в стандартный поток синтезирования или имплементации. К примеру развести часть схемы первее, чем всё остальное. Это не преИмплемент и не постСинтез. Вот и приходится придумывать как лезть в недри и хукать нужные процессы/скрипты

[RobFPGA 0]

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

50 minutes ago, Nick_K said:

Но тут дело обстоит с необходимостью влезть именно в стандартный поток синтезирования или имплементации. К примеру развести часть схемы первее, чем всё остальное.

IMHO для этого  лучше  пользовать non-project mode.  Тут вам никто не мешает  скриптами рулить процессом так как нравится.  Причем запускать эти скрипты можно и из под GUI  

Удачи! Rob.

[Nick_K 0]

1 hour ago, RobFPGA said:

IMHO для этого  лучше  пользовать non-project mode.  Тут вам никто не мешает  скриптами рулить процессом так как нравится.  Причем запускать эти скрипты можно и из под GUI 

Это я понимаю, но вот упомянутые hook'и не дают спать спокойно. Жаль временно пришлось поставить данный таск на паузу

[RobFPGA 0]

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

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.