реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Cимуляция Vivado XSIM c inremental compilation, Ну ооочень долго
Vengin
сообщение May 24 2018, 11:11
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 71
Регистрация: 7-02-07
Из: Беларусь, г. Минск
Пользователь №: 25 149



Всем доброго дня. Хотел бы услышать мнения о «практичности» функциональной симуляции в 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 - May 24 2018, 11:19
Go to the top of the page
 
+Quote Post
RobFPGA
сообщение May 24 2018, 12:47
Сообщение #2


Профессионал
*****

Группа: Свой
Сообщений: 1 137
Регистрация: 23-12-04
Пользователь №: 1 643



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

Цитата(Vengin @ May 24 2018, 14:11) *
Всем доброго дня. Хотел бы услышать мнения о «практичности» функциональной симуляции в Vivado с помощью встроенного симулятора XSIM.
Увы - этот инструмент пока еще молод и зелен. Для мелочи его как то хватает а для большой работы увы неудобен. Но иногда выбирать не приходится - что есть тем и пользуешься.

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

Цитата(Vengin @ May 24 2018, 14:11) *
Вот сейчас появилась необходимость достаточно тесно работать с Vivado 2017.4
...
Наличие встроенного XSIM вроде как должно помогать достаточно удобно симулировать всю "встроенную"
...
Казалось бы всё здорово. Но что-то в XSIM запуск симуляции (даже для небольших проектов) занимает весьма существенное количество времени, т.к. происходит полная компиляция.
...
Да это беда и быстрого решения этой медленной беды в ближайшее время мне кажется не будет.

Цитата(Vengin @ May 24 2018, 14:11) *
Так вот хотел бы спросить у людей, кто как на практике вообще решает вопросы такие проблемы.
1) Пользуется ли кто вообще встроенным в Vivado XSIM, и при этом симуляция занимает «вменяемое» количество времени? Может можно как-то настроить XSIM или весь Vivado проект (использовать некое подобие partitions или OOC для симуляции, как-то оптимизировать tcl скриптами, …)?
Можно попробовать на простых примерах сделать компиляцию и запуск xsim без GUI чисто скриптами (xvlog,xvhdl -> xelab -> xsim). И посмотреть что там отжирает больше всего времени. В Vivado многое делается не оптимально еще на этапе IDE. Многое делается спекулятивно (философия лучше перебдеть) - часто одни и те же библиотечные исходники компилируются по нескольку раз. Так как на них есть зависимости в разных корках.

Цитата(Vengin @ May 24 2018, 14:11) *
2) Что насчёт сторонних симуляторов (где можно более менее полноценно дежрать целый проект и производить инкрементальную компиляцию)?
Изначально хотел продолжать использовать Active-HDL. Но, к примеру, у меня даже не получилось скомпилить симуляционные библиотеки, т.к. для Vivado 2017.4 требуется вроде Active-HDL >=10.4, а у меня 9.1.
Увы старыми версиями симов не получится работать - вроде начиная с Vivado 2017 Xilinx поменяли ключи шифрования исходников для симуляции соответственно старые версии симов не могут их компилировать.

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

Успехов! Rob.
Go to the top of the page
 
+Quote Post
Vengin
сообщение May 26 2018, 11:49
Сообщение #3


Участник
*

Группа: Участник
Сообщений: 71
Регистрация: 7-02-07
Из: Беларусь, г. Минск
Пользователь №: 25 149



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. Но как-то это всё странно.
Go to the top of the page
 
+Quote Post
RobFPGA
сообщение May 26 2018, 13:01
Сообщение #4


Профессионал
*****

Группа: Свой
Сообщений: 1 137
Регистрация: 23-12-04
Пользователь №: 1 643



Приветствую!
Цитата(Vengin @ May 26 2018, 14:49) *
RobFPGA...
Пожалуй надо ещё раз присмотреться к ModelSim (может QuestaSim?). Хоть и не очень хотелось бы добавлять ко всей этой разработческой цепочке (внешний редакторы, внешниие симуляторы) ещё одну IDE. Иногда аж завидуешь другим "отраслям" программирования, где практически всё можно сделать в одной среде (типа Visual Studio).
QuestaSim более навороченная версия ModelSim больше ориентированная на верификацию. Для FPGA разработки разницы нет.
Тут уж Вам решать - в чем работать - понятное дело с хорошим инструментом работать приятнее но идеального в мире не бывает вот и приходится скриптингом городить "франкинштейна" из того что есть под рукой. А иногда под рукой кроме фирменного tools не первой свежести и нет ничего sad.gif. Все зависит от возможностей и желаний заказчика.

Цитата(Vengin @ May 26 2018, 14:49) *
Сейчас бегло глянул документацию ModelSim, и с удивлением обнаружил, что 'incremental compilation' поддерживается только для Verilog/SystemVerilog/SystemC. Для VHDL (с которым сейчас в основном приходится работать) вроде как нет. Неужели это так? Скажем тот же Active-HDL без проблем компилит VHDL инкеремнтально.
Все зависит от Вашего design flow и рабочего enviroment.
У меня от выстроен так что необходимость перекомпилировать все глобально довольно редка - соответственно особого профита от incremental compilation нет. Тем более для RTL FPGA дизайна. Это ведь не gate-level когда исходники для компиляции могут быть с десяток-другой GByte wacko.gif !
А так для каждой более-менее крупного лог. блока дизайна свой скрипт/proc компиляции. Модули в разработке компилятся сразу в редакторе. Поэтому затраты времени на перезапуск сима невелеки.

Удачи! Rob.
Go to the top of the page
 
+Quote Post
Vengin
сообщение May 26 2018, 15:51
Сообщение #5


Участник
*

Группа: Участник
Сообщений: 71
Регистрация: 7-02-07
Из: Беларусь, г. Минск
Пользователь №: 25 149



Цитата(RobFPGA @ May 26 2018, 16:01) *
Все зависит от Вашего design flow и рабочего enviroment.
У меня от выстроен так что необходимость перекомпилировать все глобально довольно редка - соответственно особого профита от incremental compilation нет. Тем более для RTL FPGA дизайна. Это ведь не gate-level когда исходники для компиляции могут быть с десяток-другой GByte wacko.gif !
А так для каждой более-менее крупного лог. блока дизайна свой скрипт/proc компиляции. Модули в разработке компилятся сразу в редакторе. Поэтому затраты времени на перезапуск сима невелеки.

Честно говоря, не совсем уловил мысль. Вот сейчас у меня проект, который с нуля компилируется (Elaboration) в Active-HDL минут 3-5 (в зависимости от конфигурации проекта). Изначально пытался делать тестбенчи для индивидуальных компонентов, но на каком-то этапе это потеряло смысл - всё равно нужно проверять работоспособность всей системы. В конечном итоге всё естественно проверяется в железе, но это тоже не очень эффективно, т.к. полная раскладка проекта занимает 1.5 – 4+ часа. Да и с железом приходится работать удалённо, что тоже накладывает определённые ограничения.
Т.е. сейчас есть немаленький проект, который изначально проверяется в симуляции (а релизы в железе). И естественно если после любого малейшего изменения для симуляции требуется перекомпиляция всего проекта – это крайне неэффективно. Поэтому меня и настораживает отсутствие(?) Incremental compilation.
Go to the top of the page
 
+Quote Post
RobFPGA
сообщение May 26 2018, 19:27
Сообщение #6


Профессионал
*****

Группа: Свой
Сообщений: 1 137
Регистрация: 23-12-04
Пользователь №: 1 643



Приветствую!
Цитата(Vengin @ May 26 2018, 18:51) *
Честно говоря, не совсем уловил мысль. Вот сейчас у меня проект, который с нуля компилируется (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 загружается только один раз!
При этом время компиляции для большого числа файлов в разы меньше чем в первом случае.

Цитата(Vengin @ May 26 2018, 18:51) *
...
Т.е. сейчас есть немаленький проект, который изначально проверяется в симуляции (а релизы в железе). И естественно если после любого малейшего изменения для симуляции требуется перекомпиляция всего проекта – это крайне неэффективно. Поэтому меня и настораживает отсутствие(?) Incremental compilation.
А зачем перекомпилировать все после небольшой правки ? Конечно иногда это необходимо (например после правки глобального pkg)
Но обычно нужно перекомпилить только то что правилось.
Другое дело - вы что то поправили и жмете кнопку "Run Simulation" по который IDE генерирует скрипт типа приведенного выше в котором туеву хучу раз запускается alog/acom с опцией -incremental чтобы убедится что данный файл не нужно перекомпилировать sm.gif

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

Удачи! Rob.


Go to the top of the page
 
+Quote Post
Vengin
сообщение May 31 2018, 09:08
Сообщение #7


Участник
*

Группа: Участник
Сообщений: 71
Регистрация: 7-02-07
Из: Беларусь, г. Минск
Пользователь №: 25 149



Цитата(RobFPGA @ May 26 2018, 22:27) *
если надо скомпилировать сотню файлов то 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 загружается только один раз!
При этом время компиляции для большого числа файлов в разы меньше чем в первом случае.
Кстати да. Встречался с этим периодически, но как-то не подумал, что это поможет уменьшить общее время компиляции. Надо будет обновить скрипты. Спасибо за подсазку.

Цитата(RobFPGA @ May 26 2018, 22:27) *
А зачем перекомпилировать все после небольшой правки ? Конечно иногда это необходимо (например после правки глобального pkg)
Но обычно нужно перекомпилить только то что правилось.
Другое дело - вы что то поправили и жмете кнопку "Run Simulation" по который IDE генерирует скрипт типа приведенного выше в котором туеву хучу раз запускается alog/acom с опцией -incremental чтобы убедится что данный файл не нужно перекомпилировать sm.gif
В том то и дело. Когда ранее пытался разобраться с ModelSim, мне казалось что для повторного запуска симуляции нужно опять запускать скрипт сборки всего-всего (а не только изменившихся файлов). Сейчас чуток поэкспериментировал - вроде да можно скомпилить только измененные файлы и рестартовать симуляцию. Неудобно только что (если через TCL console) нужно вручную вбивать имена модифицированных файлов. Хотя в GUI ModelSim есть возможность скопмилить обновлённые файлы (в подокне Projects правым кликом на исходники Compile -> Compile Out-Of-Date), странно, что нет соответствующей TCL команды.

Ладно, будем пытаться двигаться в этом направлении. RobFPGA, ещё раз спасибо за дельные советы. Если кто ещё может поделиться опытом - пишите.
Go to the top of the page
 
+Quote Post
RobFPGA
сообщение May 31 2018, 10:54
Сообщение #8


Профессионал
*****

Группа: Свой
Сообщений: 1 137
Регистрация: 23-12-04
Пользователь №: 1 643



Приветствую!
Цитата(Vengin @ May 31 2018, 12:08) *
...Неудобно только что (если через 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_ и выбрать из списка запуск сима нужного модуля.
Цитата(Vengin @ May 31 2018, 12:08) *
(в подокне Projects правым кликом на исходники Compile -> Compile Out-Of-Date), странно, что нет соответствующей TCL команды.
Зато есть команда vdir которая дает инфу о содержимом библиотек.
Можно сваять свой оптимизатор - но как потом оправдывать послеобеденный сон на рабочем месте? - так хоть веская причина есть - "...не видеш что ли - компилируется ..." sm.gif

Удачи! Rob.

P.S. как раз после обеда решил посмотреть сколько же можно будет подремать пока с 0 компилируется небольшой проектик без всякого incremental - 623 запуска vlog/vcom - 2122 штуки Сompiling (module|package|entity|architecture)
Всего ~3 мин 30 сек! Мда не поспишь. sad.gif
Go to the top of the page
 
+Quote Post
Vengin
сообщение Jun 2 2018, 11:43
Сообщение #9


Участник
*

Группа: Участник
Сообщений: 71
Регистрация: 7-02-07
Из: Беларусь, г. Минск
Пользователь №: 25 149



Немного оффтопик, но пока тема ещё свежая хочу уточнить 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 - Jun 2 2018, 12:05
Go to the top of the page
 
+Quote Post
RobFPGA
сообщение Jun 2 2018, 15:30
Сообщение #10


Профессионал
*****

Группа: Свой
Сообщений: 1 137
Регистрация: 23-12-04
Пользователь №: 1 643



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

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

Вы когда запускаете ModelSim посмотрите что пишется первой строчкой в консоле
Код
Reading ./в_недрах_системы/ModelSim10_4e/tcl/vsim/pref.tcl
Можно по дефолту тут подкрутить или грузить свой похожий tcl с нужными настройками

Цитата(Vengin @ Jun 2 2018, 14:43) *
2) Глюк масштабирования мышью в окне Wave. Когда в waveform пытаюсь делать Zoom с помощью мыши (Ctrl + колесо вверх/вниз), делается только Zoom In. Т.е. "Ctrl+колесо вверх" ="Ctrl+колесо вниз" = Zoom In (хотя что-то должно быть Zoom Out). ЕМНИП, в более ранних версиях ModelSim тоже была такая проблема.
У меня одного такой глюк?
Направление зума зависит еще и от положения указателя мыши относитель но курсора.

Удачи! Rob.


Go to the top of the page
 
+Quote Post
Vengin
сообщение Jun 3 2018, 08:35
Сообщение #11


Участник
*

Группа: Участник
Сообщений: 71
Регистрация: 7-02-07
Из: Беларусь, г. Минск
Пользователь №: 25 149



Цитата(RobFPGA @ Jun 2 2018, 18:30) *
Вы когда запускаете ModelSim посмотрите что пишется первой строчкой в консоле
Код
Reading ./в_недрах_системы/ModelSim10_4e/tcl/vsim/pref.tcl
Можно по дефолту тут подкрутить или грузить свой похожий tcl с нужными настройками
Как-то не всё получается настроить из pref.tcl. Например получилось настоить цвета "основных" окон (переменной PrefMain) - окна консоли, библиотек, проекта и т.п.. А вот поменять цвета текстового редактора переменной PrefSource так и не удалось.

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

Вообще конечно, GUI интерфейс моделсима живёт какой-то своей хаотичной жизнью. Тулбары прыгают как хотят, размеры и положения подокон то запоминаются то нет. Layout-ы вроде это контролируют, но тоже не совсем понятно как. Остаётся только верить, что со всременем удастся "приручить" большую часть скриптами, и что это не будет очень уж геморно.
2018-й год на дворе, а тут smile3046.gif
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd July 2018 - 09:32
Рейтинг@Mail.ru


Страница сгенерированна за 0.01075 секунд с 7
ELECTRONIX ©2004-2016