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

Cимуляция Vivado XSIM c inremental compilation

Всем доброго дня. Хотел бы услышать мнения о «практичности» функциональной симуляции в Vivado с помощью встроенного симулятора XSIM.

Немного предыстории. Работаю с FPGA уже больше 10 лет, в основном XIilnx/Altera. Обычно непосредственно написание кода происходит во внешних редакторах (скажем SlickEdit), симуляция в Active-HDL (ооочень редко ModelSim), а непосредственно сборка/отладка уже в родных IDE Quartus/Xilinx ISE(Vivado). Пока работать с симулятором удобнее чем Active-HDL не приходилось. Пару рас пытался "пересаживаться" на ModelSim, но как-то не срасталось (ИМХО с ним нормально работаnь только скриптами).

 

Вот сейчас появилась необходимость достаточно тесно работать с Vivado 2017.4 и симулировать SoC проекты (частично и/или полностью).

Наличие встроенного XSIM вроде как должно помогать достаточно удобно симулировать всю "встроенную" инфраструктуру Xilinx-а, т.е. многочисленные IP cores (открытые и шифрованные), AXI интерфейсы и т.п. Для каждого IP Core можно сгенерить Example Design, с готовым рабочим тестбенчем (иногда и несколько тестбенчей, для разных вариантов). При этом поддерживается смешанная симуляция (т.е. и VHDL, Verilog, SystemVerilog). И вроде как нет необходимости заморачиваться со сторонними симуляторами (ModelSim, и т.п.), генерить симуляционные библиотеки и подгонять скрипты.

Казалось бы всё здорово. Но что-то в XSIM запуск симуляции (даже для небольших проектов) занимает весьма существенное количество времени, т.к. происходит полная компиляция. Не совсем понятно, как эффективно заниматься симуляционным дебагом, т.е. вносить небольшие изменения в код и перезапускать симуляцию для анализа изменений. Вроде как начиная с версии Vivado 2016.3 имеется опция incremental compilation, которая должна упростить жизнь, т.е. при перезапуске симуляции отслеживать и перекомпиливать только измененные компоненты. Но на практике эффект не особо заметен. Даже с включенной опцией "incremental compilation" в консоли видно, что перекомпиливается вроде как всё (начиная с IEEE библиотек), хоть и появляются --incr флаги. В итоге задержка итерации перезапуска симуляции вместо пары секунд может занимать минуты и более, что совершенно непрактично.

На форумах Xilinx-а нашёл пару веток, где народ жалуется на подобное, но чётких ответов как-то нет.

 

Так вот хотел бы спросить у людей, кто как на практике вообще решает вопросы такие проблемы.

1) Пользуется ли кто вообще встроенным в Vivado XSIM, и при этом симуляция занимает «вменяемое» количество времени? Может можно как-то настроить XSIM или весь Vivado проект (использовать некое подобие partitions или OOC для симуляции, как-то оптимизировать tcl скриптами, …)?

2) Что насчёт сторонних симуляторов (где можно более менее полноценно дежрать целый проект и производить инкрементальную компиляцию)?

Изначально хотел продолжать использовать Active-HDL. Но, к примеру, у меня даже не получилось скомпилить симуляционные библиотеки, т.к. для Vivado 2017.4 требуется вроде Active-HDL >=10.4, а у меня 9.1. Худо бедно вручную удалось скомпилить некоторые библиотеки но лишь частично. Тем не менее для симуляции это не всегда помогает, особенно когда смешанная симуляция, да и не поддерживаются многие SystemVerilog специфичные вещи.

Изменено пользователем Vengin

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


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

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

 

Всем доброго дня. Хотел бы услышать мнения о «практичности» функциональной симуляции в Vivado с помощью встроенного симулятора XSIM.
Увы - этот инструмент пока еще молод и зелен. Для мелочи его как то хватает а для большой работы увы неудобен. Но иногда выбирать не приходится - что есть тем и пользуешься.

 

... симуляция в Active-HDL (ооочень редко ModelSim), а непосредственно сборка/отладка уже в родных IDE Quartus/Xilinx ISE(Vivado). Пока работать с симулятором удобнее чем Active-HDL не приходилось. Пару рас пытался "пересаживаться" на ModelSim, но как-то не срасталось (ИМХО с ним нормально работаnь только скриптами).
Так и есть скриптами - но когда привыкаешь то назад уже и не хочется - сам долгое время работал в Aldec но проекты росли и начиная с какого то размера стало удобнее работать в Aldec скриптами :). Ну а потом уже на ModelSim переключится было просто и естественно.

 

Вот сейчас появилась необходимость достаточно тесно работать с Vivado 2017.4

...

Наличие встроенного XSIM вроде как должно помогать достаточно удобно симулировать всю "встроенную"

...

Казалось бы всё здорово. Но что-то в XSIM запуск симуляции (даже для небольших проектов) занимает весьма существенное количество времени, т.к. происходит полная компиляция.

...

Да это беда и быстрого решения этой медленной беды в ближайшее время мне кажется не будет.

 

Так вот хотел бы спросить у людей, кто как на практике вообще решает вопросы такие проблемы.

1) Пользуется ли кто вообще встроенным в Vivado XSIM, и при этом симуляция занимает «вменяемое» количество времени? Может можно как-то настроить XSIM или весь Vivado проект (использовать некое подобие partitions или OOC для симуляции, как-то оптимизировать tcl скриптами, …)?

Можно попробовать на простых примерах сделать компиляцию и запуск xsim без GUI чисто скриптами (xvlog,xvhdl -> xelab -> xsim). И посмотреть что там отжирает больше всего времени. В Vivado многое делается не оптимально еще на этапе IDE. Многое делается спекулятивно (философия лучше перебдеть) - часто одни и те же библиотечные исходники компилируются по нескольку раз. Так как на них есть зависимости в разных корках.

 

2) Что насчёт сторонних симуляторов (где можно более менее полноценно дежрать целый проект и производить инкрементальную компиляцию)?

Изначально хотел продолжать использовать Active-HDL. Но, к примеру, у меня даже не получилось скомпилить симуляционные библиотеки, т.к. для Vivado 2017.4 требуется вроде Active-HDL >=10.4, а у меня 9.1.

Увы старыми версиями симов не получится работать - вроде начиная с Vivado 2017 Xilinx поменяли ключи шифрования исходников для симуляции соответственно старые версии симов не могут их компилировать.

 

А так да - я все симулирую в ModelSim причем скриптами для запуска из Vivado не пользуюсь - своими парсю скрипты генерируемые Vivado для корок и BD что позволяет мне выбирать что и когда и куда компилировать. A Sublime и ModelSim делает процесс "симуляционного дебага" гладким и шелковистым :)

 

Успехов! Rob.

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


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

RobFPGA, спасибо за подробные разъяснения! Пожалуй надо ещё раз присмотреться к ModelSim (может QuestaSim?). Хоть и не очень хотелось бы добавлять ко всей этой разработческой цепочке (внешний редакторы, внешниие симуляторы) ещё одну IDE. Иногда аж завидуешь другим "отраслям" программирования, где практически всё можно сделать в одной среде (типа Visual Studio).

 

Сейчас бегло глянул документацию ModelSim, и с удивлением обнаружил, что 'incremental compilation' поддерживается только для Verilog/SystemVerilog/SystemC. Для VHDL (с которым сейчас в основном приходится работать) вроде как нет. Неужели это так? Скажем тот же Active-HDL без проблем компилит VHDL инкеремнтально.

Чуток погуглил, и нашёл некий workaround - general script for compiling, recompiling and simulating VHDL/Verilog code using ModelSim. Но как-то это всё странно.

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


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

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

RobFPGA...

Пожалуй надо ещё раз присмотреться к ModelSim (может QuestaSim?). Хоть и не очень хотелось бы добавлять ко всей этой разработческой цепочке (внешний редакторы, внешниие симуляторы) ещё одну IDE. Иногда аж завидуешь другим "отраслям" программирования, где практически всё можно сделать в одной среде (типа Visual Studio).

QuestaSim более навороченная версия ModelSim больше ориентированная на верификацию. Для FPGA разработки разницы нет.

Тут уж Вам решать - в чем работать - понятное дело с хорошим инструментом работать приятнее но идеального в мире не бывает вот и приходится скриптингом городить "франкинштейна" из того что есть под рукой. А иногда под рукой кроме фирменного tools не первой свежести и нет ничего :(. Все зависит от возможностей и желаний заказчика.

 

Сейчас бегло глянул документацию ModelSim, и с удивлением обнаружил, что 'incremental compilation' поддерживается только для Verilog/SystemVerilog/SystemC. Для VHDL (с которым сейчас в основном приходится работать) вроде как нет. Неужели это так? Скажем тот же Active-HDL без проблем компилит VHDL инкеремнтально.
Все зависит от Вашего design flow и рабочего enviroment.

У меня от выстроен так что необходимость перекомпилировать все глобально довольно редка - соответственно особого профита от incremental compilation нет. Тем более для RTL FPGA дизайна. Это ведь не gate-level когда исходники для компиляции могут быть с десяток-другой GByte :wacko: !

А так для каждой более-менее крупного лог. блока дизайна свой скрипт/proc компиляции. Модули в разработке компилятся сразу в редакторе. Поэтому затраты времени на перезапуск сима невелеки.

 

Удачи! Rob.

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


Ссылка на сообщение
Поделиться на другие сайты
Все зависит от Вашего design flow и рабочего enviroment.

У меня от выстроен так что необходимость перекомпилировать все глобально довольно редка - соответственно особого профита от incremental compilation нет. Тем более для RTL FPGA дизайна. Это ведь не gate-level когда исходники для компиляции могут быть с десяток-другой GByte :wacko: !

А так для каждой более-менее крупного лог. блока дизайна свой скрипт/proc компиляции. Модули в разработке компилятся сразу в редакторе. Поэтому затраты времени на перезапуск сима невелеки.

Честно говоря, не совсем уловил мысль. Вот сейчас у меня проект, который с нуля компилируется (Elaboration) в Active-HDL минут 3-5 (в зависимости от конфигурации проекта). Изначально пытался делать тестбенчи для индивидуальных компонентов, но на каком-то этапе это потеряло смысл - всё равно нужно проверять работоспособность всей системы. В конечном итоге всё естественно проверяется в железе, но это тоже не очень эффективно, т.к. полная раскладка проекта занимает 1.5 – 4+ часа. Да и с железом приходится работать удалённо, что тоже накладывает определённые ограничения.

Т.е. сейчас есть немаленький проект, который изначально проверяется в симуляции (а релизы в железе). И естественно если после любого малейшего изменения для симуляции требуется перекомпиляция всего проекта – это крайне неэффективно. Поэтому меня и настораживает отсутствие(?) Incremental compilation.

 

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


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

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

Честно говоря, не совсем уловил мысль. Вот сейчас у меня проект, который с нуля компилируется (Elaboration) в Active-HDL минут 3-5 (в зависимости от конфигурации проекта).
Compilation и Elaboration это две разные сущности. Первая компилирует ваш исходник в некий "obj" формат и incremental опция применяется именно тут. То есть tools смотрит на дату файла и решает нужно ли обновлять obj в библиотеке или нет.

Затем Elaboration линкует и оптимизирует все obj модули в один целый "exe" для симуляции. Вот на этом этапе сделать incremental обновления уже тяжело (если вообще возможно). А обычно именно этот этап занимает большую часть времени на старте.

 

Другое дело надо смотреть как IDE запускает проект на сим. В Aldec я давно уже не работал но вроде помню что например если надо скомпилировать сотню файлов то IDE генерирует скрипт типа такого:

alog/acom [options]  folder/file_1
...
alog/acom [options] folder/file_N

Соответствен каждый раз загружается и запускается компилятор alog/acom!

А ведь ручками можно сделать так

alog/acom [options]  file1 file2 ...
# или так 
alog/acom [options]  folder/*.v  folder/*.vhd
# ну или так 
alog/acom [options]  -f file_list.f -f file_list.f

В этом случае alog/acom загружается только один раз!

При этом время компиляции для большого числа файлов в разы меньше чем в первом случае.

 

...

Т.е. сейчас есть немаленький проект, который изначально проверяется в симуляции (а релизы в железе). И естественно если после любого малейшего изменения для симуляции требуется перекомпиляция всего проекта – это крайне неэффективно. Поэтому меня и настораживает отсутствие(?) Incremental compilation.

А зачем перекомпилировать все после небольшой правки ? Конечно иногда это необходимо (например после правки глобального pkg)

Но обычно нужно перекомпилить только то что правилось.

Другое дело - вы что то поправили и жмете кнопку "Run Simulation" по который IDE генерирует скрипт типа приведенного выше в котором туеву хучу раз запускается alog/acom с опцией -incremental чтобы убедится что данный файл не нужно перекомпилировать :)

 

Изначально пытался делать тестбенчи для индивидуальных компонентов, но на каком-то этапе это потеряло смысл - всё равно нужно проверять работоспособность всей системы. В конечном итоге всё естественно проверяется в железе, но это тоже не очень эффективно, т.к. полная раскладка проекта занимает 1.5 – 4+ часа. Да и с железом приходится работать удалённо, что тоже накладывает определённые ограничения.
А по другому и ни как - Сначала TB покрывающие все более менее функционально законченные блоки - от самых низов до всего проекта целиком. Потом проверка (ну и debug) в железе. Причем чем полнее этап TB тем меньше гемороя c HW. И при этом накапливая TB для различных ситуаций со временем значительно сокращаются затраты на debug в железе.

 

Удачи! Rob.

 

 

 

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


Ссылка на сообщение
Поделиться на другие сайты
если надо скомпилировать сотню файлов то IDE генерирует скрипт типа такого:

alog/acom [options]  folder/file_1
...
alog/acom [options] folder/file_N

Соответствен каждый раз загружается и запускается компилятор alog/acom!

А ведь ручками можно сделать так

alog/acom [options]  file1 file2 ...
# или так 
alog/acom [options]  folder/*.v  folder/*.vhd
# ну или так 
alog/acom [options]  -f file_list.f -f file_list.f

В этом случае alog/acom загружается только один раз!

При этом время компиляции для большого числа файлов в разы меньше чем в первом случае.

Кстати да. Встречался с этим периодически, но как-то не подумал, что это поможет уменьшить общее время компиляции. Надо будет обновить скрипты. Спасибо за подсазку.

 

А зачем перекомпилировать все после небольшой правки ? Конечно иногда это необходимо (например после правки глобального pkg)

Но обычно нужно перекомпилить только то что правилось.

Другое дело - вы что то поправили и жмете кнопку "Run Simulation" по который IDE генерирует скрипт типа приведенного выше в котором туеву хучу раз запускается alog/acom с опцией -incremental чтобы убедится что данный файл не нужно перекомпилировать :)

В том то и дело. Когда ранее пытался разобраться с ModelSim, мне казалось что для повторного запуска симуляции нужно опять запускать скрипт сборки всего-всего (а не только изменившихся файлов). Сейчас чуток поэкспериментировал - вроде да можно скомпилить только измененные файлы и рестартовать симуляцию. Неудобно только что (если через TCL console) нужно вручную вбивать имена модифицированных файлов. Хотя в GUI ModelSim есть возможность скопмилить обновлённые файлы (в подокне Projects правым кликом на исходники Compile -> Compile Out-Of-Date), странно, что нет соответствующей TCL команды.

 

Ладно, будем пытаться двигаться в этом направлении. RobFPGA, ещё раз спасибо за дельные советы. Если кто ещё может поделиться опытом - пишите.

 

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


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

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

...Неудобно только что (если через TCL console) нужно вручную вбивать имена модифицированных файлов. Хотя в GUI ModelSim есть возможность скопмилить обновлённые файлы ...
У меня в Sublime это автоматом - отредактировал файл - F7 -> запустился vlog/vcom для компиляции - потом в ModelSim restart и прогон с новой версией. В других редакторах тоже можно настроить такое.

Ну а первоначальный запуск симуляции в скрипте setup_tb.tcl который грузится автоматом при запуске ModelSim выглядит так -

...
proc com_module1 {} {
  vlog -f "sv_opt.f" -F "$::SRC_DIR/module1/sv_opt1.f" -F "$::SRC_DIR/module1/src_list1.sv"
    ...
  vlog -f "sv_opt.f" -F "$::SRC_DIR/module1/sv_opt.f" "$::SRC_DIR/module1/module1.sv"
}

proc sim_module1_tb {} {
  # compile submodule
  com_module1
  # compile TB
  vlog -f "sv_opt.f" -F "$::SRC_DIR/module1/TB/sv_opt.f" "$::SRC_DIR/module1/TB/module1_tb.sv"
  # make list of all simulation library
  mk_tb_libs "$::LIBS_ROOT" "tb_libs.f"

  vsim -novopt \
    -f tb_libs.f \
    ... \
    -title module1_tb \
    -wave ./wave/module1_tb.wlf \
    -do {log -r /*; do ./w_module1_tb.do} \
    module1_tb glbl
}

потом достаточно в консоли набрать sim_ и выбрать из списка запуск сима нужного модуля.

(в подокне Projects правым кликом на исходники Compile -> Compile Out-Of-Date), странно, что нет соответствующей TCL команды.
Зато есть команда vdir которая дает инфу о содержимом библиотек.

Можно сваять свой оптимизатор - но как потом оправдывать послеобеденный сон на рабочем месте? - так хоть веская причина есть - "...не видеш что ли - компилируется ..." :)

 

Удачи! Rob.

 

P.S. как раз после обеда решил посмотреть сколько же можно будет подремать пока с 0 компилируется небольшой проектик без всякого incremental - 623 запуска vlog/vcom - 2122 штуки Сompiling (module|package|entity|architecture)

Всего ~3 мин 30 сек! Мда не поспишь. :(

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


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

Немного оффтопик, но пока тема ещё свежая хочу уточнить 2 вещи связанные с ModelSim.

 

1) Может кто знает, где ModelSim хранит свои настройки GUI (шрифты, бэкграунды и т.п.), то что доступно по меню Tools -> Edit Preferences)? Предпочитаю переделывать цветовую схему под чёрный бэкграунд. Явной возможности Import/Export Preferences нет, а хочется иметь возможность переносимости настроек между разными версиями софта (сейчас в ModelSim SE-64 10.5).

В папке самого ModelSim таких настроечных файлов найти не удалось (сделал полную копию и, после внесения изменений, сравнивал каталоги). В папке конкретного проекта (а вдруг?) тоже нет. Общий поиск по системным каталогам ничего не дал. Может в реестре где?

UPD: сам спросил, сам ответил. Да в реестре: HKEY_USERS\<S-1-5-21-xxx>\Software\Model Technology Incorporated\ModelSim

 

2) Глюк масштабирования мышью в окне Wave. Когда в waveform пытаюсь делать Zoom с помощью мыши (Ctrl + колесо вверх/вниз), делается только Zoom In. Т.е. "Ctrl+колесо вверх" ="Ctrl+колесо вниз" = Zoom In (хотя что-то должно быть Zoom Out). ЕМНИП, в более ранних версиях ModelSim тоже была такая проблема.

У меня одного такой глюк?

Изменено пользователем Vengin

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


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

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

 

...

1) Может кто знает, где ModelSim хранит свои настройки GUI (шрифты, бэкграунды и т.п.), то что доступно по меню Tools -> Edit Preferences)? Предпочитаю переделывать цветовую схему под чёрный бэкграунд. Явной возможности Import/Export Preferences нет, а хочется иметь возможность переносимости настроек между разными версиями софта (сейчас в ModelSim SE-64 10.5).

Вы когда запускаете ModelSim посмотрите что пишется первой строчкой в консоле

Reading ./в_недрах_системы/ModelSim10_4e/tcl/vsim/pref.tcl

Можно по дефолту тут подкрутить или грузить свой похожий tcl с нужными настройками

 

2) Глюк масштабирования мышью в окне Wave. Когда в waveform пытаюсь делать Zoom с помощью мыши (Ctrl + колесо вверх/вниз), делается только Zoom In. Т.е. "Ctrl+колесо вверх" ="Ctrl+колесо вниз" = Zoom In (хотя что-то должно быть Zoom Out). ЕМНИП, в более ранних версиях ModelSim тоже была такая проблема.

У меня одного такой глюк?

Направление зума зависит еще и от положения указателя мыши относитель но курсора.

 

Удачи! Rob.

 

 

 

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


Ссылка на сообщение
Поделиться на другие сайты
Вы когда запускаете ModelSim посмотрите что пишется первой строчкой в консоле

Reading ./в_недрах_системы/ModelSim10_4e/tcl/vsim/pref.tcl

Можно по дефолту тут подкрутить или грузить свой похожий tcl с нужными настройками

Как-то не всё получается настроить из pref.tcl. Например получилось настоить цвета "основных" окон (переменной PrefMain) - окна консоли, библиотек, проекта и т.п.. А вот поменять цвета текстового редактора переменной PrefSource так и не удалось.

 

Направление зума зависит еще и от положения указателя мыши относитель но курсора.
Однако. Какая-то корреляцию от положения указателя мыши и курсора вроде наблюдается, но понять логику мне честно говоря по прежнему не удалось. "Железно" Zoom In/Out удаётся получить только клавиатурой (ну или кнопки меню тулбаров). Да и то, понять где центр зума - загадка.

 

Вообще конечно, GUI интерфейс моделсима живёт какой-то своей хаотичной жизнью. Тулбары прыгают как хотят, размеры и положения подокон то запоминаются то нет. Layout-ы вроде это контролируют, но тоже не совсем понятно как. Остаётся только верить, что со всременем удастся "приручить" большую часть скриптами, и что это не будет очень уж геморно.

2018-й год на дворе, а тут :smile3046:

 

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


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

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти