Распространение искусственного интеллекта не изменило основополагающий факт в полупроводниковой отрасли: разработка аппаратного и программного обеспечения по-прежнему в основном ведётся в рамках двух отдельных направлений. Анализ, опубликованный Semiconductor Engineering 15 сентября 2026 года, показывает, что преимущества совместного проектирования известны уже много лет, однако его широкое применение по-прежнему сталкивается с организационными и техническими препятствиями, которые искусственный интеллект пока не устранил.
Проблема начинается с самой структуры рабочих команд. Инженеры по аппаратному и программному обеспечению используют разные инструменты и языки, а также работают по несинхронным графикам и ритмам разработки. В традиционной модели проект достигает стадии производства микросхемы, после чего команды программного обеспечения начинают адаптировать систему к ней, включая работу с изменениями и известными ошибками, называемыми errata. Sam Grove, руководитель направления программного обеспечения и инструментов в MIPS/GlobalFoundries, описывает такую ситуацию как позднюю передачу проекта, из-за которой команда программного обеспечения вынуждена сосредоточиться на запуске продукта, а не на участии в проектировании следующего поколения.
Разрыв имеет не только организационный характер
Даже когда компании пытаются внедрить непрерывную интеграцию, центральным препятствием остаётся скорость получения надёжного результата. Frank Schirrmeister, исполнительный директор по стратегическим программам системных решений в Synopsys, отмечает, что переход от спецификаций к модели аппаратного и программного обеспечения может стать очень быстрым при условии, что систему удаётся моделировать с достаточной скоростью.
Существуют виртуальные прототипы, средства моделирования, инструменты emulation и модели на базе FPGA, однако каждый вариант предполагает свои компромиссы между точностью, производительностью и временем выполнения. Виртуальная модель может помочь заранее проверить влияние программного обеспечения на архитектуру, тогда как моделирование или более детальная модель дают более полное представление о производительности и энергопотреблении. Но запуск полной и репрезентативной рабочей нагрузки конечного продукта остаётся значительно сложнее, чем проверка небольшой функции или синтетической нагрузки.
Сложность возрастает, когда команды хотят выполнять одну и ту же рабочую нагрузку на нескольких этапах — от виртуальной платформы до emulation, затем на модели на базе FPGA и, наконец, на кремнии. Моделирование десяти секунд работы микросхемы может оказаться непрактичным, поэтому необходимо определить, какая часть может выполняться на каждом этапе, вместо того чтобы предполагать, что одна модель охватит все варианты использования.
Общие спецификации — предварительное условие для искусственного интеллекта
Эксперты считают первым требованием создание содержательных и интегрированных спецификаций, которые инженеры и агенты искусственного интеллекта смогут использовать совместно. Согласно статье, сегодня это делают лишь отдельные отрасли, среди которых в большей степени военная и аэрокосмическая промышленность. Без таких спецификаций искусственный интеллект не располагает единым эталоном, связывающим системные требования с проектированием RTL, программным обеспечением и результатами верификации.
Синтетические эксперименты могут помочь измерить время выполнения и энергопотребление программных функций на наборе архитектур, но одного этого недостаточно для принятия проектного решения. Инженеры также балансируют между гибкостью и производительностью, стоимостью и размером, энергетическим бюджетом, тепловыми и экологическими факторами. Arvind Srinivasan, инженер по решениям для верификации в Normal Computing, говорит, что одна из наиболее производительных конструкций может быть полностью специализированной для конкретной задачи, тогда как единого способа кодировать все эти ограничения, чтобы алгоритм искусственного интеллекта мог использовать их как оптимизируемые цели, пока не существует.
Что искусственный интеллект умеет делать сейчас?
Текущие варианты применения более ограничены, чем идея о том, что искусственный интеллект спроектирует систему целиком. Andy Meier, главный менеджер по маркетингу продуктов в Siemens EDA, говорит, что клиенты в основном используют его для создания RTL и тестовых окружений, но не видит сопоставимого по масштабу применения в архитектурных решениях. Это связано с тем, что такие решения требуют широкого понимания компромиссов между производительностью, энергопотреблением, стоимостью и поведением рабочих нагрузок.
В свою очередь, MIPS/GlobalFoundries используют агентов искусственного интеллекта для написания программного обеспечения и аппаратных компонентов в рамках конкретных задач, подчёркивая необходимость понимать ограничения и ошибки инструмента. Steve Roddy, директор по маркетингу в Quadric, также отмечает, что программное обеспечение может многократно измениться за период между созданием модели проекта и появлением кремния — как под воздействием разработчиков, так и помощников на основе искусственного интеллекта. Это означает, что совместное проектирование — не решение, принимаемое один раз в начале проекта, а процесс, который должен постоянно учитывать изменения программного обеспечения.
Normal Computing рассматривает возможность использования искусственного интеллекта для извлечения более абстрактных представлений аппаратного обеспечения, чтобы разработчики программного обеспечения могли работать до завершения RTL. Эта концепция основана на наличии представления спецификаций или ontology, которое может служить общим эталоном, однако не отменяет необходимости связать это представление с последующими моделями и проверить их соответствие.
Верификация и сотрудничество — узкое место
Анализ подтверждает, что прогресс, вероятнее всего, будет постепенным, поскольку полная замена существующих методологий повышает риски проекта. Srinivasan отмечает, что инструменты EDA по-прежнему решают небольшие части проблемы, вместо того чтобы улучшать общий результат, а чёрным ящикам необходимы гарантии корректности, возможности аудита и единый журнал, показывающий взаимосвязь между элементами проекта и результатами их верификации.
Синхронизация моделей остаётся практической проблемой. Модель высокого уровня в SystemC без временной привязки не равна RTL с точки зрения временной точности, а поддержание их согласованности требует значительных затрат времени на верификацию, проверку и подготовку программного обеспечения. Поэтому недостаточно предоставить виртуальную модель; необходима связанная цепочка моделей моделирования и анализа, а также передача знаний между командами проектирования, прикладными командами и службами поддержки клиентов.
С точки зрения certi.news, реальные изменения заключаются не в запуске одного инструмента и не в немедленном переходе отрасли к автономному проектированию под управлением искусственного интеллекта. Изменение состоит в том, что программное обеспечение начало влиять на определение архитектуры ещё до завершения микросхемы, а инструменты EDA пытаются связать этапы, которые ранее были раздельными. Однако источник не предоставляет доказательств того, что проблема решена; напротив, он показывает, что отсутствие унифицированных спецификаций, стоимость моделирования, изменения программного обеспечения и необходимость аудируемости по-прежнему остаются основными ограничениями. Поэтому человеческий опыт сохранит решающее значение в архитектурных решениях, тогда как влияние искусственного интеллекта будет сосредоточено на конкретных задачах, результаты которых можно тестировать и проверять.