dxp

А что такое "полярность тактового сигнала"? Это ж просто меандр, где у него полярность? Может начальная фаза имеется в виду, что она должна приходить на устройства, тактируемые от одного источника, в одной фазе? Но если так, то PCIe вообще может работать от разных источников тактовой частоты, которые не разбегаются по частоте больше, чем 600 ppm, какая уж тут начальная фаза может быть, если клоки полностью асинхронные.

rebase -- мощная штука при правильном использовании: позволяет держать историю красивой (когда она состоит из комитов слияния, где чётко видна этапность добавления фич и фиксов, по такой истории легко ориентироваться -- быстро находится добавление той или иной фичи, а по комитам слитой ветки видна локальная история разработки фичи, ничего не смешивается) при работе группой. Где пригождается rebase, лучше показать на примере. У нас процесс построен так (он рекомендованный, насколько знаю): есть общая ветка разработки, она постоянная, она содержит только целостные комиты, т.е. состояние проекта таково, что он собирается и работает. Основной смысл этого в том, чтобы любой участник команды мог взять крайний комит за основу для разработки своей фичи, и у него всё будет собираться, не будет чужих ошибок, которые будут ему мешать развивать и собирать своё. Для этого создаётся временная ветка (feature branch -- FB). Сливать в общуюю ветку может только её мейнтейнер, у остальных таких прав нет (это обеспечивает целостную базу как отправную точку для всех участников проекта независимо от их дисциплинированности -- главное, чтобы ментейнер не был раздолбаем и добросовестно проверял перед слиянием -- это несложная работа, её вообще можно автоматизировать, но у нас руки пока не дошли, не обременительно запускать сборку/тесты руками). Работа участниками проекта ведётся параллельно. Когда фича готова к слиянию, её автор создаёт pull/merge request на слияние этой FB в общую. Перед этим он делает rebase на общую ветку, чтобы объединить свою фичу с кодом общей, которая за время работы над FB могла уйти вперёд (как правило так и происходит). Мейнтейнер проверяет целостность кода, запуская сборку, тесты. Если всё успешно, FB сливается в общую с комитом слияния (git merge --no-ff). Результатом будет чётко видная в истории ветка FB со всеми своими комитами, слитая в общую через комит слияния. Делать объединение общей ветки с FB обязательно -- на этом этапе вылезают всякие конфликты, ошибки и т.п. Объединять можно двумя способами: через merge и через rebase. Если делать через merge, то это нарушает описанную выше "красивость" истории (которая нужна далеко не только из эстетических аспектов, но является мощным подспорьем для ретроспективы кода). rebase позволяет держать локальную историю разработки фичи компактно и целостно, не смешивая с комитами других веток. Да, это изменяет историю развития проекта в смысле строгой хронологии, но для работы с кодом гораздо важнее вид с точки зрения добавления фич и фиксов, когда видны этапы работы, а не вид с точки зрения последовательных дат комитов. Получается, что хотя работа участниками проекта во временном аспекте ведётся параллельно, в истории комитов результаты их работы (фичи/фиксы) добавляются строго последовательно, что убирает путаницу: вид такой, как будто все работали друг за другом по цепочке, дожидаясь результата (слияния) от предыдущего члена команды. В описанном процессе rebase пригождается не толькло при работе командой. Ровно то же самое и когда работаешь один, если приходится параллельно вести больше одной FB (например, при разработке фичи отвлекаться на правку багов, создавая для них свои ветки).

Насклько знаю, у ртути ветки не такие лёгкие и бесплатные, как в гите. Там даже какую-то нахлобучку добавляли, которая имеет схожую реализацию -- перемещаемые метки. Общего у ртути и гита то, что они обе системы с локальным репозиторием. Про остальные две не знаю, но низкая известность и популярность говорят сами за себя: мало сообщество, качество инструмента напрямую зависит от количества использующих и т.п. Есть Bazaar, тоже одно время интенсивно развивалась/продвигалась, но на сегодняшний день по факту сдулась (она на Python реализована, как я понял, там серьёзные вопросы с производительностью, особенно на больших проектах). Т.ч. систем управления версиями много всяких, это да, и какие-то в чём-то могут безоговорочно превосходить остальные, но мы говорим о выборе рабочего инструмента, на который претендуют только хорошо проверенные в деле, сиречь популярные, системы. По совокупности гит рулит.

Для этого надо делать резервное копирование. Некоторые люди считают, что система контроля версий git служит и для этого, но это заблуждение. Удалённые репозитории для публикации и обмена, а не для хранения резервных копий. Например, вы можете публиковать далеко не все ветки, которые есть у вас. И эти локальные ветки в случае утери локального репозитория потеряются безвозвратно. А пушить всё подряд на удалённый сервер -- так себе практика, оно не для этого предназначено. Кстати, именно поэтому git -- это система управления версиями с локальным репозиторием, а не с распределённым, как её частно называют. Никакой распределённости репозитория реально нет, а есть только локальные, которые могут обладать уникальным содержимым, которое не может быть восстановлено в случае утраты из репозиториев других участников проекта. Кроме того, в рабочих материалах могут находиться какие-то временные файлы, которые не удостоины того, чтобы попасть в истоирию, но которые в моменте важны, их утеря может создать препятствия в работе. Поэтому регулярное резервное копирование рабочих материалов и решает все эти проблемы. У меня оно делается автоматически каждую ночь по расписанию (комп вы выключается).

Раз такой открытый обмен мнениями, то позволю себе. Оценка будет жёсткая (любителям svn не понравится), но зато правдивая: если сравнивать git vs svn в контексте именно управления версиями, то git является системой управления версиями как таковой, а svn нет. svn, cvs, Perforce и все подобные системы с центральным репозиторием являются скорее системами инкрементального архивирования с функциями менджмента кода (особенно Perforce). Главное, что отличает git от перечисленных и делает его эффективным имеено как систему управления версиями -- это способность лёгкого, быстрого создания веток и их эффективного слиния хоть методами merge, хоть rebase. Именно такие ветки (которые по сути ветками и не являются -- это традиционное, устоявшееся название, а по сути это просто перемещаемые вместе с "головой" (HEAD) метками) и позволяют бесплатно (ничего не внося в код, не плодя копий) вести отслеживание изменений кода. git позволяет делать реально атомарные комиты -- т.е. когда в комит входят изменения, касающиеся только чего-то одного. Это очень важная штука: такие комиты можно легко таскать между ветками, их можно отменять, не ломая других фич. Вот эта схема с индексом (stage) именно для этого и предназначена (когда в начале не понимал этого, тоже раздражало, что вместо просто commit надо ещё в add в индекс делать, хорошо, что хоть опция -a там была 🙂) : нередко бывает, что изменения кода в одном файле относятся к разным по смыслу фичам/фиксам, и пихать это в один комит неправильно -- потом его ни отменить (нечасто это надо, но бывает), ни перетащить изменения в другую ветку, где они актуальны уже сейчас (а другие изменения и этой ветки, где комит, пока не нужны, они ждут своего слияния в общую ветку). Так вот, git позволяет добавить в индекс выборочно правки из файла, не трогая другие. И так, накидав в индекс, изменения, связанные по смыслу, из разных файлов, можно получить, закомитив, тот самый атомарный комит. Делается это командой git add -i. Существует вполне удобный GUI инструмент для этого -- git-cola, в ней можно прямо выделять в файле нужные строки изменений и добавлять в индекс (или удалять из индекса добавленное по ошибке). Push после каждого комита тоже делать совершенно не нужно. git -- это система с локальным репозиторием, самый главный реп -- это тот, с которым вы работаете, который лежит у вас рабочем проекте. Push -- это просто способ опубликовать ваши изменения (серверов для публикации может быть сильно больше, чем один 🙂 ). Публиковать надо тогда, когда это необходимо, и не ранее. Пока всё лежит локально, можно менять историю изменений, устраняя ошибки при комитах. Это позволяет легко держать историю проекта красивой и удобной для ретроспективы. Это крайне важная штука -- по такой истории можно быстро эффективно найти практически всё (пример такой истории можно посмотреть по ссылке ниже), по ней легко разобраться, когда что происходило и быстро "вспомнить" нюансы ушедшего в прошлое процесса разработки. К сожалению, тот же svn не позволяет ничего из вышеперечисленного. Ветвление в нём -- это боль. Поэтому типовая история проекта в svn (cvs или Perforce) -- это ровная цепочка комитов, глядя на которую, не понятно, где когда что делалось -- нужно ползать по всем звеньям цепочки и искать, вчитвываясь в комментарии. И комиты там редко бывают атомарными, обычно комит в svn -- это целый список несвязанных между собой изменений. Да, конечно, и в svn можно стараться делать короткие атомарные комиты, но это технически непросто делать, когда разные по смыслу изменения присутствуют в одном файле. Есть пара моментов, где системы svn/Perfoce сильнее, чем git: связь с внешними репозиториями; работа с нетекстовыми файлами большого размера. Оба преимущества проистекают из того, что svn/Perforce основаны на нативной файловой системе: единицы слежения за изменениями -- это файлы, ветки -- это директории. Это позволяет легко цеплять сторонние репозитории как директории (хоть целиком, хоть фрагменты) через svn:externals в svn или mapping в Perforce (этот в этом вопросе вообще очень крут). В git же единицей слежения является не файл, а слепок проекта, т.к. совокупность файлов. Директории в нём вообще ничего не значат и учитываются просто в путях файлов, за счёт чего и поддерживается файловая структура с директорими (но закомитить пустую директорию не получится, т.к. для git директория не является ценностной единицей). А submodules в git -- это не самая приятная штука, особенно, когда дело доходит до того, чтобы их удалять/переносить. Уже не впервые высказываюсь на эту тему. Вот тут подробнее про использование: Исходя из вышесказанного, можно сделать определённый вывод: если требуется гибкое и удобное версионирование, то git тут вне конкуренции. Это относится в первую очередь к разработке кода. А вот, например, для схематики/PCB отлично подходит svn, т.к. там обычно никакого ветвления (и слияния, которое в случае с нетекствыми файлами очень затруднительно) не требуется, а нужно инкрементально сохранять последовательные изменения проекта.

Не-не, на том сервере 5 PCIe Gen3 x8 торчало непосредственно из CPU (4 выходили слотами в сторону морды (19" стоечное исполнение) -- для подключения NIC, 1 по райзер плату, туда накопители цеплялись). Т.е. PCIe линки были непосредственно подключены к CPU. 29 секунд он думал до выдачи BIOS screen. Это точно до начала опроса внешних периферийных устройств.

Пару слов про требование готовности PCI устройство. Согласно спеке ATX устройство должно быть готово к работе (енумерации аппаратурой хоста) не позднее 100 мс. Это довольно малое время, учитывая сложность современных устройств. В начале работы с PCIe сильно парился по этому поводу, потому что тот же Artix 200 при всём желании не успевал загрузиться за 100 мс чисто физически на максимальной скорости при внешнем тактировании (там что-то порядка 130 мс уходило). Но потом выяснилось, что требование-то это никто не отменял, но реально оно давно не соответствует необходимости. Оно возникло во времена 386 РС, когда PCI внедрялся в эту платформу, тогда процы были маленькими, системные платы относительно простыми, объёмы памяти смешными (по нынешним временам), там процессорная система через 100 мс уже была готова чекать конфигурацию периферийных устройств. Современный РС при подаче питания занимается самодиагностикой (и прочим) несколько секунд! Это настольный. Замерял на серверной платформе (какой-то Xeon, не самый современный), там вообще 29 секунд он находился где-то внутри себя и только после этого только появлялся BIOS screen. Наверное инициировать загрузку по окончании PERST# идеологически неверно (а правильно было бы формировать сигнал конфигурирования из него внутри платы), но учитывая тайминг готовности современных CPU, я бы не опасался, что Artix 25 не успеет загрузиться до начала енумерации.

Сам-то по себе CDR вполне исправно работает -- и при загрузке, и потом при работе не сбивается. Если только: Это вполне бы объяснило. Подытоживая, видятся две причины. Логическая: то, что вы упомянули (выше в цитате) -- BIOS ведёт себя по-разному при "холодном" старте и при "тёплом". Физическая: при перезагрузке присутствует какое-то аномальное поведение цепей питания или сброса (например, длительность импульса или фронтов сигнала некорректные). Причём, не фатально аномальные, но так, что конкретной плате этого хватает. Чёткая повторяемость эффекта (как я понял, это происходит каждый раз при описанной последовательности действий) голосует за первый сценарий. Возможно, при перезагрузке BIOS инициализирует аппаратуру материнки не в полном объёме, как это имеет место при "холодном" старте. Но против этого говорит то, что другие платы в этом сценарии работают, т.е. дело, получается, не в логике работы RC. А ОС какая? Если Linux, может в логе загрузки что-то есть на эту тему?

Непростой случай. Из общего описания очевидно, что тут нет проблем с физикой в смысле передачи сигналов. И тем не менее причина где-то на физическом уровне, раз оно зависит от физического переставления платы в другой слот и от самой физической платы (конкретного экземпляра). Интересно, есть ли повторяемость в другом хосте с MSI материнкой, т.е. это зависит именно от производителя материнки или от конкретного экземпляра. Так же интересно, одна из пяти -- это статистика: 1000 плат и 200 вот таких, или просто есть пять плат и одна себя так ведёт. Из области предположений: такое поведение можно было бы объяснить, если, скажем, грешить на питание или сигнал сброса платы (если он задействован) -- например, при перезагрузке по кнопке там возникает короткая просадка, которая не сбрасывает плату до конца, и внутренняя аппаратура PCIe залипает в каком-то состоянии, которое препятствует успешному линку.

ну, и в итоге в каком состоянии LTSSM залипает?

Возможно, полезно посмотреть на LTSSM -- в каком состоянии оно зависает. Если линк пропадает, наверняка дивайс пытается поднять линк заново, но почему-то ему этого не удаётся. Состояние этого автомата может подсказать ответ или направление поиска. Но это не точно. 🙂

Вы хотели сказать "непакованный массив и пакованный массив"? Вообще-то, разница есть. В непакованном массиве, объявленном традиционным способом (когда младшие по порядку элементы индексируются от 0), такая запись поместит старшие элменты массива (если N равеняется размеру элемента) в старшие биты RHS: А для пакованного массива туда попадут младшие биты -- будет изменён порядок следования, как тут: только тут по 4 бита упаковка ведётся, но суть ясна. Картинки и примеры отсюда: https://www.amiq.com/consulting/2017/05/29/how-to-pack-data-using-systemverilog-streaming-operators/ https://www.amiq.com/consulting/2017/06/23/how-to-unpack-data-using-the-systemverilog-streaming-operators/

Согласен. Но тогда задачу надо было формулировать как: "...коэффициент передачи тока базы транзистора находится в диапазоне 40..120, найти диапазон токов, протекающих через нагрузку...". И по сути она всё равно сводится к исходной, просто вместо одного значения в конечную формулу надо подставить два.

Разумеется, все присутствующие это понимают. Это учебная задача, цель которой выявить понимание схемы и принципов работы её элементов. На практике, конечно, никто именно так схемы не проектирует, обычно требуется обеспечить "не меньше". Но если нужно точно, то схема уже другая (составной БТ или полевик). Ещё и ОУ надо на практике правильно подобрать (напряжение смещения, входные токи, их разность, температурные дрейфы и т.п.). Но это на практике. А для обучения годится и этот вариант с бетой 50 и идеальным ОУ -- это просто частный случай, фрагмент практической реализации. Инженер должен уметь делать декомпозицию задачи на более простые. Если на этом примере обучающийся правильно поймёт принцип работы схемы и способ вычисления тока, то он легко поймёт, что при реальной бете 40..120 (а в диапазоне температур 20..150) ток в нагрузке будет гулять в диапазоне... который можно посчитать, взяв минимальное и максимальное значения беты. Меня больше удивляет, что за решение такой задачи уже обещают оценку 5. Имхо, уровень сложности задачи не соответствует высшему.

Если сопротивление нагрузки будет, скажем, 10к, то ток через неё будет уже совсем не 1.96 мА.

+1. Делал такое ещё на Quartus'е лохматых годов (2005-й), всё прекрасно пробрасывалось из внутреннего по иерархии модуля на топ через inout.

Учитывая номиналы элементов, задача решается в уме, мелкая заковырка только в необходимости учёта тока базы. Автор темы, если хочет иметь специальность по теме, обязан решить её сам, задача элементарнее некуда. А если ему нужен просто документ о ВО, то это совсем другая история, и советы участников форума ему бесполезны.

Вектор -- синтезируемый тип в V. В SV это называется пакованный массив (packed array). (если уж наводить строгость). Ну, отдельного встроенного булевого типа в V/SV нет, имелось в виду, что автоматически приводится к однобитному значению, пригодному для анализа на true/false.

numpy в целом неплох. Но там есть не всё, и кое-что не устроило по быстродействию. Конкретно построение гистрограмм яркостей пикселов -- в numpy функция построения гистограммы навороченная, универсальная, умеет много чего, что нам не нужно было. И скорость работы получалась так себе. В итоге простой цикл на С работал в разы быстрее. Этим и удовлетворился. Matplotlib -- конечно. scipy -- не помню, вроде что-то использовали, но мало (поэтому и не помню). pandas -- нет, не пришлось. Со сменой работы тематики изменились, давно этим не занимюсь. P.S. Сам проект этот лежит где-то на github. Могу поискать, если интересно. Но там поразбираться немного придётся, не всё так просто и на виду.

Не, немного не так. Jupyter Notebook -- это вариант, относящийся к классу программ-ноутбуков: это такие программы, которые позволяют совмещать описательную и вычислительную часть. Например, Matlab тоже относится к этому классу. В случае Jupyter там технология состоит в том, что есть некое вычислительное ядро (в нашем случае на Python, но может быть вроде как на любом из языков, составляющих основу Jupyter -- Julia, Python, R, от них и его название, а в принципе там можно добавлять и другие языки -- типа расширяемая штука), и есть интерфейс. Там есть различные способы запуска. Например, если выполнить ipython, то запустится монолитный процесс, где ядро и интерфейс консоли совмещены. Но если выполнить jupyter console, то внешне это будет выглядеть точно так же (только запуск будет подольше и будет выхлоп в шелл про какие-то кернелы), но тут уже сама консоль запускается отдельно от ядра (в другом процессе) и цепляется к ядру. Можно запустить другую консоль, указав, что нужно прицепиться к уже запущенному ядру. Так можно работать, например, вдвоём (или более) интерактивно. jupyter qtconsole -- почти то же самое, что и в предыдущем случае, но запустится gui консоль, в которой, например, можно сделать режим, когда картинки (результат того же plot) будут внедрятся непосредственно в лог консоли (как в web-based jupyter notebook), что часто удобнее, нежели ловить графику в отдельных окошках. И вот в предыдущем посте я описывал вариант, когда собственное приложение собирается с jupyter kernel, к которому можно прицепить ipython console или qtconsole. А поскольку ядро внедрено в программу, то оно "видит" все потроха (как workspace в Matlab или IPython), что даёт полную инспекцию и контроль. Ну, тут зависит, на каком уровне оно внедрено -- полный контроль надо всем -- это когда на верхнем модуле, а если на каком-то из вложенных, то от этого модуля и вниз по иерархии. Ну, а Jupyter Notebook -- веб приложение, которое тоже запускает ядро. По идее можно к этому ядру прицепиться консолью (вроде пробовал, даже получалось, но смысла для себя не увидел). Идея примерно та же, что и с консолями -- можно назапускать ядер и цепляться к ним этими веб мордами. Ну, и возможности отображения и "деплоя" страниц ноутбука тут совсем другие -- даже github умеет из коробки отображать страницы Jupyter Notebook, ничего ставить не надо на пользовательской стороне. Прицепиться Jupyter Notebook к ядру, которое было внедрено в нашу программу, у меня не получилось. Но оно и не надо было -- там консоль нужна, а не документ ноутбука делать.

Ещё пять копеек. Дешёвая ПЛИСка (Gowin, какой-нить), на которой скрафтить желаемое количество МАС'ов, и любой МК по вкусу, лучше с аппаратным контроллером памяти, чтобы отмапить доступ к внешним МАС через шину памяти. Просто ещё один вариант со своими + и -.

Проект jupyter позволяет написать приложение, в которое внедряется ядро (jupyter kernel), позволяющее иметь полный контроль (инспекцию) надо всеми потрохами приложения в реальном времени через jupyter console. Мы таким образом делали прогу, которая качала видеопоток с камеры, производила его анализ и обработку. Тяжелые в вычислительном плане функции были написаны на C/C++ и подключены через boost::python. Сама прога была реализована с помощью PyQt. Собственно, цель была в упрощении разработки алгоритмов обработки видеопотока в камере (тепловизор). Камера включалась в bypass режим, когда "сырой" поток значений пикселов с сенсора лился на РС, а тут это программа его обрабатывала в реальном времени, корректировала ключевые параметры видеотракта и управляла сигналами сенсора, подстраивая его. Поэтом отработанный, отлаженный алгоритм портировался на "железо" (ПЛИС+набортный процессор). Внешне это выглядело так. Запускается программа (PyQt), появляются её окна (картинки на разных этапах обработки видеотракта) и запускается консоль (jupyter console). В любой момент можно командой через консоль включить, выключить что-то, поменять значение того или иного параметра или вывести в цикле и наблюдать динамику изменения параметров видеотракта (да вообще любых объектов в программе). Можно, например, дать команду сграбить эн кадров (хоть тыщу), и потом спокойно их анализировать, обрабатывать через интерактивный режим Python в jupyter. К примеру, посмотреть шумы отдельных пикселов во времени (поиск аномально ведущих себя элементов приёмника -- для тепловизионных это обычное дело). Ну, и всякие гистограммы, профили строк или столбцов на разных уровнях экспозиции смотреть -- в общем, тут только фантазия и потребности ограничивают. Доступ ко всем объектам в реальном времени без останова программы. Очень эффективный и мощный метод разработки оказался: по сути программный видеотракт (software-defined) с полным доступом к потрохам (инспекция и контроль). Понятно, что это можно использовать с любыми приборами: получаешь работающую железку с полным доступом к внутренностям в реальном времени и мощным фремфорком для анализа и обработки. До этого варианта был ещё написанный на Qt (честный С++), но там работать было не очень удобно -- доступа такого не было, если что-то надо сделать, то это сначала написать, скомпилировать, запустить. В итоге интерфейс управления через консоль начинал обрастать и становится едва ли не сложнее самой программы. Это и натолкнуло на идею переписать на Python (PyQt), чтобы облегчить/ускорить процесс обновления программы. Ну, и попутно предпринимались попытка как-то скрестить это с мегаудобным IPython. Так набрели на эту тему с внедрением jupyter kernel. По производительности вариант на чистом Qt и этот на PyQt+jupyter kernel оказались почти эквивалентными (системный монитор загрузки CPU показывал одни и те же значения ±1%) -- это в основном благодаря тому, что все тяжёлые функции были вынесены на уровень C/C++ и numpy, а Python был в своей основной роли orchestration language.

При логических операциях целые неявно приводятся к булевому типу и потом выполняется операция. Та же логика действует в обычном: int x = ...; ... if(x) begin ... end

Название темы опровергает ваш тезис. Проблема? За несколько лет интенсивного использования и не догадывался, что это проблема. Запускать сборщик заново? Это проблема? svh файлы генерируются за доли секунды. Если их содержимое не изменилось (сборочный тул проверяет это по хэшам), то дальнейшая цепочка сборки не выполняется. Что касается времени выполнения, то процесс компиляции по сравнению с прогоном на рантайме по длительности отличается на пару порядков (1-2 минуты компиляция, час-полтора прогон). О какой экономии тут речь? Генерация нетлиста занимает дни? Это что за процесс такой? Боюсь спросить, а сколько времени занимает прогон тестов этого нетлиста? Месяцы? А если под генерацией нетлиста подразумевается синтез и PnR, то это совсем другая история. C DPI тоже дружим, но по другому поводу -- связь с инструментарием внешнего (по отношению к симулятору) мира.

Не ведаю, что такое "иерархичность yaml-дерева", даже к стыду не знаю, что такое "yaml-дерево". Если имеется в виду, что значения словаря может в свою очередь тоже могут являться ключом для другого словаря, то для определения параметров этого не надо. Гораздо важнее возможность вычислять значения параметров на основе других (определённых выше) и импортировать другие yaml файлы с параметрами, которые так же можно использовать при вычислениях (что штатное "yaml-дерево" не поддерживает, т.к. это просто формат хранения). И это у нас есть. Не лучше. Не знаю, что там написано на С++, но на Python такие вещи делаются куда проще: и пишутся, и читаются, и сопровождаются. А DPI -- это симулятор онли. У нас же эта система параметров используется в первую очередь для обслуживания синтеза, включая генерирование IP ядер, создание проекта синтезатора (Vivado), компиляцию HLS модулей и применение параметров общего назначения, из которых генерятся не только svh заголовки для SV, но и tcl файлики для симулятора и синтезатора. Вся кухня работает по зависимостям, т.е. лишней работы не делается. И зачем рантайм конфигурация, если это можно сделать на этапе компиляции? Рантайм нужен там, где по-иному не получается или неэффективно (негибко, громоздко). В случае заранее заданных параметров всё известно на этапе компиляции. На рантайме симулятору и другой нагрузки достаточно.