После того, как мы здесь и здесь разобрали, что же такое компьютерные симуляторы и какими они бывают, настало время поговорить о том, как они используются. И начну я, пожалуй, с наиболее интересной области применения – расскажу о том, как профессиональные программисты используют симуляторы при разработке ПО, чтобы написать и отладить софт для «железа», которого еще даже не существует.



Речь пойдет об использовании моделей не самых простых устройств, таких как, например, SoC (System on Chip) или печатных плат со множеством интегрированных устройств на борту. В разработке самих этих устройств можно выделить два этапа. Сначала разрабатывается аппаратная часть. Это процесс небыстрый – может занять и год, и больше.

После того как появляется первая ревизия физического устройства и проводятся базовые проверки, устройство передается разработчикам ПО. С этого момента начинается вторая фаза – разработка софта для устройства. Это могут быть прошивки (firmware), BIOS, BSP/CSP (Board and CPU Support Package) для различных операционных систем, а также драйвера.


Кстати, в разработке чипов, которые часто называют «силикон» (silicon), эти фазы именуются «пре-силикон» (pre-silicon) и «пост-силикон» (post-silicon) или просто «силикон».

Теоретически, разработка ПО возможна и до появления физического устройства. Однако, на практике так мало кто делает. Разработка без возможности промежуточных запусков и отладки, а для этого как раз и требуется устройство, – дело сильно неблагодарное, я встречал мало таких мазохистов. Все ждут «железо», а оно, как я написал выше, появится только через год.

Кроме того, с «железом» есть еще и другая проблема. Первую ревизию выпускают лимитированной серией и раздают по одной штуке в руки. Проще говоря, плат и чипов на всех не хватает. Возникают очереди, конфликты, доходит до рукоприкладства. А если ты случайно спалил устройство, что очень даже несложно, то вся разработка останавливается, пока не будет найдено другое устройство. Часто оно не находится, необходимо производить новое, а потом ждать доставку. Это сильно тормозит процесс.

И тогда на помощь разработчикам ПО приходят симуляторы!

Создание виртуальной модели устройства начинается одновременно с проектированием физического устройства. Но так как создание и выпуск модели существенно проще, первые релизы таких моделей появляются условно не через год, а много раньше. Используя такие модели, разработчики ПО могут сразу приступить к своим задачам, не дожидаясь «железа».

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


При таком подходе разработчики моделей и софта используют общие спецификации. Запуская ПО на модели, они, по сути, проверяют работу друг друга.

Дополнительным плюсом является валидация «железа» при том, что самого железа еще даже нет. Это звучит удивительно на первый взгляд, но речь здесь идет об архитектурных ошибках при проектировании устройства, часть из которых может выявляться при запуске софта на модели. И это очень круто, так как есть возможность исправить эти ошибки в «железе» до того, как оно будет выпущено. В противном случае эти ошибки привели бы к необходимости перевыпуска следующих ревизий, а это довольно дорогое удовольствие.

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

Большие компании-производители устройств могут поддерживать целую экосистему, выстроенную вокруг своих продуктов. В такую экосистему входят множество других компаний, в том числе и тех, которые производят ПО для данного оборудования. Например, это могут быть производители BIOS, так называемые IBV (Independent BIOS Vendors), наиболее известные из которых AMI, Insyde, Phoenix. Такие компании также получают модели от производителя оборудования и начинают разработку до появления физического устройства. Например, для платформ Intel используется симулятор Simics, о чем подробнее можно прочитать в статье Ecosystem Partners Shift Left with Intel for Faster Time-to-Market.

Очевидно, что создание моделей требует дополнительных затрат. Объем затрат, конечно, зависит от типа моделей (функциональные, потактовые и т.д.), но в целом можно принять стоимость создания модели примерно равной стоимости написания ПО для устройства. Не все компании готовы платить такую цену за более ранний выпуск, поэтому такой подход распространен в больших корпорациях. У них есть достаточные для этого бюджеты, а более ранний вывод продукта на рынок существенно увеличивает их доходы. Хотя в последнее время наблюдается тенденция более широкого использования симуляторов для разработки ПО и в небольших по размеру компаниях.

Часто для сокращения затрат в модели реализуют не всю возможную функциональность, а только минимально необходимую для определенных сценариев использования устройства. Например, если сетевое устройство не планируется использовать в VLAN-ах, а только чтобы обновлять прошивку и делать загрузку по tftp, то логику с VLAN tag-ами реализовывать необязательно, а вот функциональность для сценариев загрузки устройства по сети и обновления прошивки надо реализовать в полном объеме.

Что в итоге получается?

Если принять, что время разработки «железа» и софта примерно равны друг другу (см. картинку выше), то использование моделей позволяет существенно, практически в 2 раза, сократить время вывода продукта на рынок (т.н. TTM – Time To Market), так как разработка «железа» и софта ведется параллельно, а не последовательно. Для этого часто используют термин Shift Left, пришедший из области тестирования, где он означал как можно более раннее тестирование. Этот же термин применим и к разработке ПО, которая как бы сдвигается влево по шкале времени, когда выполняется на симуляторе.

К моменту появления первой ревизии оборудования останется только проверить работоспособность ПО на реальном «железе». В идеале, ошибки и исправления не должны быть значительными и данный этап не вносит больших задержек, так как код уже написан и отлажен на модели.

Подобный подход не «бесплатный», он требует дополнительного бюджета и команды программистов, поэтому надо четко понимать, насколько окупятся эти затраты в том или ином случае.

Это не единственный вариант использования симуляторов. Об архитектурных исследованиях и создании сложного окружения я расскажу в следующих статьях. Не переключайтесь.