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

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

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

Кажется, что отрасли нужен лучший способ донести требования до компаний EDA. Раньше это определялось СУМО, которое прогнозировало и прогнозировало новые необходимые возможности и сроки их реализации. Этого больше не существует. Сегодня стандарты разрабатываются компаниями-производителями полупроводников. Это изменение по сравнению с прошлым, когда мы привыкли видеть, что компании EDA продвигают разработки, проводимые в рамках таких групп, как Accellera. Когда я смотрю на их недавние начинания, большинство из них инициированы конечными пользователями.

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

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

• Какие инструменты разрабатываются для анализа мощности программного обеспечения?
• Как можно рассчитать энергию, потребляемую для заданной функции?
• Как пользователи могут оптимизировать конструкцию с точки зрения мощности или энергии?

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

Я начал думать, что лаю не на то дерево, и, возможно, это были необоснованные опасения. Мое здравомыслие было восстановлено после комментария к одной из моих недавних историй, связанных с властью. Аллан Кантл, руководитель подпроекта OCP HPC в Open Compute Project Foundation, написал: «Хотя приятно видеть, что подобные статьи подчеркивают необходимость того, чтобы мы все сосредоточились на энергоориентированных вычислениях, печальная новость заключается в том, что наши инструменты не сообщают об этом. энергии любым очевидным способом, чтобы показать глупые архитектурные ошибки, которые мы часто совершаем с точки зрения энергопотребления. Мы решаем все проблемы снизу вверх, сближая вещи. Хотя это действительно приносит огромные преимущества в области энергоэффективности, это также приводит к значительному увеличению плотности энергии. Подход к архитектуре системы «сверху вниз» дает так много «легких» результатов, которых отрасль упускает, потому что нам нужно мыслить нестандартно и не ограничиваться нашими разрозненными областями».

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

Я не могу с этим не согласиться, и меня расстраивает то, что ни одна компания EDA, похоже, меня не слушает. Я уверен, что часть проблемы заключается в том, что крупные клиенты работают над собственными внутренними решениями и считают, что это обеспечит им конкурентное преимущество. Пока не станет ясно, что у всех их конкурентов есть аналогичные решения и что они больше не получают от этого преимуществ, они будут стремиться передать эти решения компаниям EDA, чтобы им не приходилось их поддерживать. Затем компании EDA начнут бороться за то, чтобы решение, которое они приобрели, стало стандартом. Все это занимает много времени.

Частично защищая компании EDA, в наши дни они сталкиваются с таким количеством новых проблем, что они очень разбросаны по новым узлам, 2.5D, 3D, сдвигу влево, мультифизике, алгоритмам искусственного интеллекта – и это лишь некоторые из них. Они уже тратят на НИОКР больше, чем большинство технологических компаний, в процентах от выручки.

Возможно, Accellera могла бы начать включать дискуссионные форумы в такие мероприятия, как DVCon. Это позволит провести открытое обсуждение проблем, которые им необходимо решить. Возможно, они могли бы начать создавать EDA, эквивалентный старой дорожной карте ITRS. Это наверняка сэкономит много времени и энергии (каламбур).