[dxp 32]

Всем привет!

 

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

 

Но вот с Block Design'ом (BD) так не получается. Вроде бы BD похож на IP, но по факту это целая пачка IP, многие из которых сокрыты внутри головных (блоков). И если с синтезом тут проблем нет - Vivado сама разбирается, что там к чему, то с симуляцией возникает вопрос, какие файлы нужны и где они лежат. А файлов там немало, и пути к ним местами весьма замысловаты. Фрагмент дерева файлов:

 

│   ├── 7005
│   │   └── hdl
│   │       └── sc_sc2axi_v1_0_vl_rfs.sv
│   ├── 7bd7
│   │   └── hdl
│   │       └── sc_exit_v1_0_vl_rfs.sv
│   ├── 8047
│   │   └── hdl
│   │       └── sc_si_converter_v1_0_vl_rfs.sv
│   ├── 80cc
│   │   └── hdl
│   │       ├── sc_util_v1_0_vl_rfs.sv
│   │       └── verilog
│   │           ├── sc_util_v1_0_4_constants_noc.vh
│   │           ├── sc_util_v1_0_4_constants.vh
│   │           └── sc_util_v1_0_4_structs.svh
│   ├── 8842
│   │   └── hdl
│   │       └── proc_sys_reset_v5_0_vh_rfs.vhd
│   ├── 8f68
│   │   └── hdl
│   │       └── axi_register_slice_v2_1_vl_rfs.v
│   ├── b89e
│   │   └── hdl
│   │       └── sc_axi2sc_v1_0_vl_rfs.sv
│   ├── c012
│   │   └── hdl
│   │       └── sc_switchboard_v1_0_vl_rfs.sv
│   ├── ea34
│   │   └── hdl
│   │       └── sc_mmu_v1_0_vl_rfs.sv
│   ├── ec67
│   │   └── hdl
│   │       ├── axi_infrastructure_v1_1_0.vh
│   │       └── axi_infrastructure_v1_1_vl_rfs.v
│   ├── ef1e
│   │   └── hdl
│   │       └── lib_cdc_v1_0_rfs.vhd
│   ├── fcfc
│   │   └── hdl
│   │       └── xlconstant_v1_1_vl_rfs.v
│   └── fdc1
│       └── hdl
│           ├── versal_cips_ps_vip_v1_0_2_apis.sv
│           ├── versal_cips_ps_vip_v1_0_2_local_params.sv
│           ├── versal_cips_ps_vip_v1_0_2_reg_init.sv
│           ├── versal_cips_ps_vip_v1_0_2_reg_params.sv
│           ├── versal_cips_ps_vip_v1_0_2_unused_ports.sv
│           └── versal_cips_ps_vip_v1_0_vl_rfs.sv

Это на вот такой вот дизайн:

 

Т.е. простейший, где нет ни одного соединения блока (просто блок сам по себе сложный). Развесистые BD будут давать изрядно более обширные списки файлов. 

 

И вот как это хозяйство пристроить к имеющемуся маршруту процесса моделирования? Я пока вижу один путь: Vivado можно скомандовать, чтобы при команде запуска симуляции (из Vivado же) она сам процесс не запускала, а только генерировала скрипты для компиляции, элаборации, распарсив которые, выдрать все нужные файлы и опции. На основе этой информации уже скомпилировать это хозяйство в отдельную библиотеку, которую, в свою очередь, так же как и библиотеку IP ядер подключать к компиляции общего проекта для симулятора.

 

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

[RobFPGA 27]

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

5 hours ago, dxp said:

И вот как это хозяйство пристроить к имеющемуся маршруту процесса моделирования?

Еще   для  Vivado v2014  я  сделал  такой flow - при generate output product для BD/IP, ну или просто выполняя команду export_simulation ...  Vivado генерирует  скрипты  для компиляции  BD/IP. Скрипты кладутся обычно в .../proj_name/proj_name.ip_user_files/sim_scripts/bd_name/.  
Остается  дело за малым - берем например скрипт для Modelsim  ...bd_name/modelsim/compile.do и ...   парсим его своим скриптом. 
А результат парсинга компилируем куда надо.  При парсинге  можно немного по оптимизировать, например выбросить компиляцию стандартных IP корок (которые уже скомпилированы).   

Этот  flow  у меня работает без изменений и сейчас   в v2021.1 

 

Удачи! Rob.
 

P.S.  есть  еще  путь настоящих  джедаев , разобраться в  скрипте  который работает по команде export_simulation (так как он открыт и доступен в TCL store)  и  изменить/написать свой скрипт который будет сразу выводит  скрипт компиляции в нужном  вам формате. 

[dxp 32]

15 часов назад, RobFPGA сказал:

Еще   для  Vivado v2014  я  сделал  такой flow - при generate output product для BD/IP, ну или просто выполняя команду export_simulation ...  Vivado генерирует  скрипты  для компиляции  BD/IP. Скрипты кладутся обычно в .../proj_name/proj_name.ip_user_files/sim_scripts/bd_name/.  
Остается  дело за малым - берем например скрипт для Modelsim  ...bd_name/modelsim/compile.do и ...   парсим его своим скриптом. 
А результат парсинга компилируем куда надо.  При парсинге  можно немного по оптимизировать, например выбросить компиляцию стандартных IP корок (которые уже скомпилированы).   

Вот по этому пути сейчас и иду (парсинг уже накидал). 

 

15 часов назад, RobFPGA сказал:

Этот  flow  у меня работает без изменений и сейчас   в v2021.1 

Это несказанно радует - значит, структура и подход стабильны.

 

Спасибо за комментарий, подтвердили правильность пути, это прям поддержка! 

 

15 часов назад, RobFPGA сказал:

парсим его своим скриптом. 

А вы какие части выдираете из него? Я пока решил так: вытаскиваю файлы .v, .sv, .vhd - три группы получается, они потом будут компилировать каждая группа по отдельности, и строки с "+incdir+<path>", которые будут нужны для компиляции. Остальное (там он кучу либ генерит) не беру.

 

15 часов назад, RobFPGA сказал:

При парсинге  можно немного по оптимизировать, например выбросить компиляцию стандартных IP корок (которые уже скомпилированы).

Да, как минимум выкинуть из него собственные исходники.

 

15 часов назад, RobFPGA сказал:

P.S.  есть  еще  путь настоящих  джедаев , разобраться в  скрипте  который работает по команде export_simulation (так как он открыт и доступен в TCL store)  и  изменить/написать свой скрипт который будет сразу выводит  скрипт компиляции в нужном  вам формате. 

Про это не знал. Тоже есть над чем подумать. Возможно не столько в сторону изменения этого скрипта, сколько найти в нём подсказку, где брать списки файлов и каталогов. Хотя с каталогами всё скорее всего тухло - он там генерирует часть из них, видимо, по случайному закону (числа какие-то, наверное, чтобы имена не придумывать).

[RobFPGA 27]

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

8 hours ago, dxp said:

А вы какие части выдираете из него? Я пока решил так: вытаскиваю файлы .v, .sv, .vhd - три группы получается, они потом будут компилировать каждая группа по отдельности, и строки с "+incdir+<path>", которые будут нужны для компиляции. Остальное (там он кучу либ генерит) не беру.

Ну так все которые нужны. 
Формат там простой - выделяю имя library куда компилировать надо, списки опций, define, include директорий, и список исходников для компиляции.  Если имя library нет в списке заранее скомпилированных IP core библиотек то создаю соответствующе библиотеку и компилю  туда полученные исходники с выделенными опциями и  инклудами. 

Отдельно  надо не забыть  скопировать из ...bd_name/modelsim/*.(.mem|mif|dat)  файлы инициализации памяти в рабочий каталог сима.    

8 hours ago, dxp said:

Возможно не столько в сторону изменения этого скрипта, сколько найти в нём подсказку, где брать списки файлов и каталогов.

Я пытался разобраться еще в 2014.  Там все с одной стороны все относительно просто, а с другой такая каша.  На сколько помню  списки файлов берутся проходом по иерархии BD/IP стандартными командами типа get_ips ...  get_files ...  с различными опциями  и  анализом различных property полученных  файлов. 
Решив что при выходе каждой новой версии Vivado вникать по новой в эту кашу будет лень сложно решил пойти по более простому пути падавана.      

Удачи! Rob.

[dxp 32]

10 минут назад, RobFPGA сказал:

Формат там простой - выделяю имя library куда компилировать надо, списки опций, define, include директорий, и список исходников для компиляции.  Если имя library нет в списке заранее скомпилированных IP core библиотек то создаю соответствующе библиотеку и компилю  туда полученные исходники с выделенными опциями и  инклудами. 

А есть какой-то смысл именно по библиотекам это рассовывать? Почему просто не скомпилить в одну либу?

Списки опций по идее должны быть те же самые, что и для всего проекта. Define там не встречал.

Опции -L подаются, как вижу, бестолково. Например, после списка vlib и vmap команд идёт первый vlog, где вижу список

 

 -work xilinx_vip -L cpm5_v1_0_4 -L cpm4_v1_0_4 -L axi_vip_v1_1_10 -L smartconnect_v1_0 -L versal_cips_ps_vip_v1_0_2 -L xilinx_vip

 

Т.е. компилируется библиотека xilinx_vip, но все остальные либы на данный момент совершенно пусты (там тупо этот список подаётся в каждый вызов компилятора). Более того, сама же компилируемая библиотека подаётся на вход как сторонняя. Неаккуратно. Не хочется такое дублировать.

 

[RobFPGA 27]

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

1 minute ago, dxp said:

А есть какой-то смысл именно по библиотекам это рассовывать? Почему просто не скомпилить в одну либу?

Для VHDL точно есть так как референс на используемые библиотеки есть в каждом исходнике VHDL. Ну и теоретически в V/SV тоже такое может быть так что для единообразия тоже есть. Тем более если не использовать пре-компилированые библиотеки IP core, а компилировать  их каждый раз по новой.   

Обычно пере-компилированные либы IP core у меня подключены через modelsim.ini в рабочей папке сима (ссылкой на modelsim.ini в папке с пре-компилированнми библиотеками) поэтому они сразу видны при компиляции через  ключ -L.

 

Удачи! Rob.  

[dxp 32]

4 минуты назад, RobFPGA сказал:

Для VHDL точно есть так как референс на используемые библиотеки есть в каждом исходнике VHDL. Ну и теоретически в V/SV тоже такое может быть так что для единообразия тоже есть.

Ну, тогда, выдрав группы файлов .v, .sv, .vhd, скомпилировать эти группы каждую в свою библиотеку, т.е. получается три либы. И смысл понятен, зачем так делать. Но в compile.do их:

 

vlib questa_lib/msim/xilinx_vip
vlib questa_lib/msim/xpm
vlib questa_lib/msim/smartconnect_v1_0
vlib questa_lib/msim/axi_infrastructure_v1_1_0
vlib questa_lib/msim/axi_register_slice_v2_1_24
vlib questa_lib/msim/axi_vip_v1_1_10
vlib questa_lib/msim/lib_cdc_v1_0_2
vlib questa_lib/msim/proc_sys_reset_v5_0_13
vlib questa_lib/msim/xlconstant_v1_1_7
vlib questa_lib/msim/versal_cips_ps_vip_v1_0_2
vlib questa_lib/msim/xil_defaultlib
vlib questa_lib/msim/cpm4_v1_0_4
vlib questa_lib/msim/cpm5_v1_0_4

 

и явно они тут не по типу скомпонованы, а по целевому признаку. Это было бы правильно, когда б лежало где-то отдельно. Но для локальной симуляции смысла никакого нет, только загромождение.

 

Кстати, вижу, например:

 

vlog -work xpm ...\

"<...>/Vivado/2021.1/data/ip/xpm/xpm_cdc/hdl/xpm_cdc.sv" \
"<...>/Vivado/2021.1/data/ip/xpm/xpm_fifo/hdl/xpm_fifo.sv" \
"<...>/Vivado/2021.1/data/ip/xpm/xpm_memory/hdl/xpm_memory.sv" \

 

и 

 

vcom -work xpm -64 -93 \
"<...>/Vivado/2021.1/data/ip/xpm/xpm_VCOMP.vhd" \

 

т.е. .sv и .vhd сорцы беззастенчиво компилируют в одну либу.

[RobFPGA 27]

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

21 minutes ago, dxp said:

Кстати, вижу, например:
vlog -work xpm ...\

Ну так work это рабочая либа сима по умолчанию. И если либа специально не указана сим ищет модули в ней. 
А вот в VHDL сорцах всегда указывается имя либ/package  которые нужны этому модулю. И они симом ищутся по имени подключенной  либы. И если стандартные либы (типа library IEEE, UNISIM) обычно уже подключены  в modelsim.ini то либы  пользовательских модулей и IP блоков которые есть на этой BD нужно компилировать в  либу  с соответствующим именем. При этом важен и порядок компиляции.   
Так же, по имени, ищутся либы и при использовании ключа -L .. .  Если такой либы не будет то будут как минимум варнинги при старте сима. 

 

Удачи! Rob.

[dxp 32]

5 минут назад, RobFPGA сказал:

Ну так work это рабочая либа сима по умолчанию.

В данном случае work - не либа, а ключ компилятора, который указывает имя целевой библиотеки - xpm данном случае. И в неё компилируются разные по типу файлы - и .sv, и .vhd. Я про это. Про требование VHDL - имя импортируемой библиотеки - понял, спасибо.

 

Скрипт, которым парсите, на каком языке? 

[RobFPGA 27]

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

3 hours ago, dxp said:

В данном случае work - не либа

Да конечно ключ,  недосмотрел.  А разные по типу сорцы в одну библиотеку это без проблем. 

3 hours ago, dxp said:

Скрипт, которым парсите, на каком языке?

Так на tcl и парсю, зачем тянуть лишние зависимости.  Тем более  там все простейшим способом (switch, regexp, ...)  парсится. 

 

Удачи! Rob.    

[dxp 32]

01.10.2021 в 21:51, RobFPGA сказал:

Так на tcl и парсю, зачем тянуть лишние зависимости.  Тем более  там все простейшим способом (switch, regexp, ...)  парсится. 

Круть! Для меня Tcl - write-only language. Всё, что сложнее простых условий, стремлюсь утащить куда-нить в Python.

 

А вообще, у вас рабочий маршрут какой? Синтез пускаете в project mode или non-project mode? И с симуляцией - вот распарсили, скажем, тот compile.do, а дальше что? Какой-то тоже скрипт запускаете, который управляет всем процессом компиляции рабочей библиотеки, запуском симулятора и т.д? Из Vivado запускаете или из командной строки рулите процессом (или ещё какой вариант - из редактора, например)?

[RobFPGA 27]

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

1 hour ago, dxp said:

Для меня Tcl - write-only language. Всё, что сложнее простых условий, стремлюсь утащить куда-нить в Python.

TCL  вполне продвинутый язык, на нем тоже можно делать много крутого.

1 hour ago, dxp said:

А вообще, у вас рабочий маршрут какой?

Разные маршруты, зависит как от заказчика так и от моей ленивости. 
В процессе разработки отдельных модулей/небольших проектов обычно project-mode. С переходом в non-project ближе к окончанию если надо.

Для сима  у меня идет "параллельный" проект в tcl. Хотя так как в симе обычно времени проводишь больше чем в Vv/Qu  то можно считать что основной проект у меня едет на своем "велосипеде" в tcl, а из него уже идет параллельный импорт/экспорт в Vv/Qu.     
Есть скопившейся за годы набор вспомогательных функций, парсеров, и определенная структура проекта на tcl для сима. 
Например в папке для каждого функционального блока есть скрипт, (условно setup_tb.tcl) в котором пишу процедуры для компиляции и запуска сима для разных модулей этого блока, типа: 

Spoiler

# ----------------------------------------
add_help "com_tcp" "Compile TCP core"
proc com_tcp {} {
 
  vlog -f "$::SRC_DIR/sim_sv_opt.f" \
    "$::SRC_DIR/tcp/tcp_pq.sv" \
    "$::SRC_DIR/top/tcp_if.sv"

  compile_xip "$::SRC_DIR/tcp/tcp_xip.tcl"                          "$::LIBS_ROOT" "-F $::SRC_DIR/tcp/sim_sv_opt.f"

  compile_do  "$::VV_IP_USER/sim_scripts/tcp_sys/questa/compile.do" "$::LIBS_ROOT" "+define+_FAST_SIM_"
}

# ----------------------------------------
add_help "sim_tcp_tb1" "Тест TCP ARP "
proc sim_tcp_tb1 {} {
  com_tcp
    
  vlog -F "$::SRC_DIR/sim_sv_opt.f" \
    "$::SRC_DIR/tcp/TB/tcp_bfm.sv" \
    "$::SRC_DIR/top/TB/tcp_tb1.sv"

  # make list of library
  list_of_libs "$::LIBS_ROOT" "$::SIM_ROOT/tb_libs.f"

  vsim \
    -voptargs=+acc \
    -suppress 8684,vsim-2685 \
    -L xil_defaultlib \
    -f "$::SIM_SRC/vsim.f" \
    -f "$::env(X_SIM_LIBS)/x_sim.f" \
    -f "$::SIM_ROOT/tb_libs.f" \
    -wave "$::WAVE_DIR/tcp_tb1.wlf" \
    -do "log -r /*; do $::SIM_SRC/w_tcp_tb1.do" \
    tcp_tb1 glbl
} 

# ----------------------------------------
add_help "sim_tcp_tb2" "Тест TCP ping"
proc sim_tcp_tb2 {} {
  ...

 

Соответвенно есть основной setup.tcl скрипт где определяются все глобальные переменные для проекта типа $::SRC_DIR, ... а также поиск и загрузка остальных вспомогательных и  setup_tb скриптов в проекте. Этот скрипт грузится автоматом при запуске Modelsim так как он прописан в startup секции modelsim.ini.  При этом  работа  во внешнем редакторе с запуском компиляции из редактора позволяет оперативно править, перекомпилировать и перезапускать сим с минимальными потерями времени. 
При некой организации эта схема позволяет работает без изменения скриптов и под Win и под Linux,  а также для Vv и для Qu проектов, естественно с небольшим изменением в скрипте глобальных настроек.

         

Удачи! Rob.

[dxp 32]

Чтобы не заводить новую тему, спрошу тут, вопросы связанные. 

 

Существует ли штатный или нештатный способ как-то "прокинуть" в BD параметры? Т.е. вот, скажем, поместили на диаграмму элемент FIFO, зашли в его свойства, там нащёлкали значения параметров (ширина порта данных, использовать ли те или иные порты и т.д.). Всё это прописывается внутри явно. Но вот хочется как-то автоматизировать процесс сборки - например, в проекте есть параметр BUS_WIDTH, он передаётся в модули через `define, и хочется, чтобы он и в BD тоже передавался. Т.е. если захочется поменять его значение, чтобы проект пересобрался консистентно. А то когда правка в более чем одном месте, обязательно будет забываться поправить в каком-нибудь из них.

 

Если BD вести строго в тикле, то проблемы, конечно, нет - пробрасываем параметр в Tcl файл и вуаля. Но это требует определённого дзена в этой теме. Большинству людей удобнее всё-таки конфигурировать BD через GUI. И вот тут что-то у меня тупик. Или плохо искал?

[andrew_b 14]

Ядра в BD и сам BD  синтезируются до синтеза RTL-ной части проекта. На этом этапе никакие дефайны никуда не подставляются.

Вроде так.

[dxp 32]

Имелось в виду что-то вроде импорта в BD сторонней информации (аналог source <script-name>.tcl) с возможностью ссылаться на импортированные значения. В текстовом Tcl это штатно, и если в окошке Diagram мы видим графический аналог этого, то логично предположить, что просится аналогичное средство.