К возрастанию сложности проектирования процессоров

К возрастанию сложности проектирования процессоров

Выпуск 21(6745) от 28 октября 2021 г.
РУБРИКА: МИКРОЭЛЕКТРОНИКА

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

Одним из самых трудных вопросов для любой группы специалистов, занимающихся изучением конъюнктуры рынка, является вопрос о том, что поддерживать в первую очередь. С чем выходить на рынок: с одной ИС, двумя ИС или целым семейством приборов? Какова будет перспектива, если выйти на рынок с ИС завышенного размера и сделать ее немного дороже? Купит ли -кто-нибудь ИС, реализуемые как семейство приборов – ​например при выводе на рынок пяти отдельных ИС вместо одной? Не получится ли в итоге что одной или двумя ИС из этого семейства никто не пользуется? Принятие подобных решений становятся все сложнее, потому что все зависит от степени повышения производительности и сложности, а также требований, предъявляемых к выводимому на рынок изделию. Если разработчик опоздал с моментом вывода своей разработки на рынок или упустил в ней -какую-то широко используемую функцию, его ждет полный провал.


Перемещение данных

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

Специалисты корпорации Rambus отмечают, что это один из аспектов, по которому видно, как разработчики меняют алгоритмы, как реорганизуются вычисления. Например, существует такая вещь, как рефакторинг5, когда разработчик рассматривает свое приложение, и то, как оно могло бы быть написано 10 лет назад. Очевидно, что это могут быть совершенно различные и приложения, и подходы. Суть идеи: «Если изменить приложение, разбить его по-другому, чтобы использовать новые доступные решения физического уровня (ИС, модули, СФ-блоки и т. п.), чего можно добиться в конце концов?» То есть речь идет о переоценке имеющихся аппаратного обеспечения и алгоритмов с целью нахождения для них новых применений и/или расширения имеющихся. Некоторые приложения существуют уже много лет, хорошо известно, как они работают, но, в то же время, существует много встроенных ноу-хау для их оптимизации под существующие сегодня архитектуры. Задача рефакторинга для некоторых приложений очень сложна и является своего рода компромиссом, а также попыткой выяснить, какова будет стоимость разработки. То есть понять, выгодно ли за это браться. Подобный подход зачастую оправдан, так как заниматься разработкой ПО с нуля, а затем все перепроверять, иногда оказывается слишком дорого.

Но основные параметры – ​быстродействие и потребляемая мощность – ​по-прежнему имеют большое значение. При изучении различных вопросов оптимизации, касающихся площади кристалла, тактовой частоты и синхронизации закладывается необходимость прохождения базового теста на синхронизацию – ​в противном случае кристалл ИС не будет работать. Оптимизация преследует, в первую очередь, цель ускорения работы кристалла ИС. Важность вопроса потребляемой мощности во многом зависит от того, какой тип ИС разрабатывается, что для него важнее – ​потребляемая мощность или быстродействие. Соответственно, большинство изменений, которые может внести разработчик, это изменения в оптимизации перемещения блоков/элементов, определения того, какие границы рабочих режимов должны определяться топологией, а также то, как все это повлияет на выход годных. Затем наступает очередь структур, которые разработчик на самом деле не может изменить – ​например структур тестирования. Поэтому при оптимизации единственной наиболее взаимосвязанной частью функции всегда была синхронизация.

Это не новая идея. Корпорация Synopsys давно известна своими инструментальными средствами синтеза, причем со встроенной верификацией синхронизации, верификацией временных параметров. Со временем инструментальные средства и проблемы проектирования стали сложнее, и сейчас оптимизируется не только синхронизация, временные параметры – ​максимально оптимизируется статистическое распределение временных параметров, потому что это оказывает огромное влияние на выход годных, особенно если есть только одно окно приемлемости (т. е. набор значений параметров, позволяющий изготавливать ИС, работающих при желаемых спецификациях). Если производитель может осуществлять сортировку, то некоторые кристаллы, удавшиеся лучше, будут продаваться дороже, а другие подойдут для приложений с меньшей производительностью.

Важной частью этого процесса является исследование пространства проектных решений. Например, у проектировщика есть технические характеристики, а также предполагаемые рабочие нагрузки, но при этом ему нужно найти лучшее решение (с точки зрения быстродействия, энергоэффективности и производительности. Стандартно используются такие подходы, как кодирование на языке регистровых передач (RTL) или на языке Verilog. Но в современных условиях это не позволяет изучить все возможные варианты. Потребуются также наборы инструментальных средств разработки ПО (SDK), включающие библиотеки, заголовочные файлы, help-файлы, документацию и т. п. Нужны будут и компиляторы, работающие с RTL.

Многие специалисты предлагают перейти на более высокий уровень абстракции, такой как язык описания архитектуры. Сторонники этого подхода создают на языке Codal (Codasip Architectural Language) единое описание, позволяющее начать процесс проектирования с -какой-то функциональной модели. Затем они начинают оценивать систему с учетом имеющихся рабочих нагрузок, настраивать параметры, совершенствовать свои архитектуры и продолжают добавлять различные детали и пересматривать их. В итоге получается RTL-интерфейс устройства, который очень подходит для нужд проектировщика. Но этапы этого исследования пространства проектных решений, от функциональной модели до модели реализации, должны быть как можно более плавными. Это невозможно сделать в RTL, потому что это слишком низкоуровневый язык. Если оставаться на уровне языка С, это будет слишком высокий уровень. Язык описания архитектуры дает возможность максимально плавно пройти этот процесс.


Инструментальные средства САПР в современных условиях

Растущая сложность микроархитектур также повышает спрос на инструментальные средства САПР.

Проблема в том, что потребителям нужно гораздо больше, чем они могут получить с помощью современной электроники. Электроника сейчас на порядок сложнее. Это толкает дальнейшее развитие САПР по различным направлениям. Нередко можно увидеть кристаллы ИС, содержащие до 1,2 млрд транзисторов, предназначенных для блоков формирования выводов искусственного интеллекта. При этом в подобных блоках может содержаться с более 150 процессоров. Существование таких ИС меняют ситуацию во многих отношениях.

Отраслевые аналитики указывают, что полупроводниковая промышленность переходит в новый этап развития, когда на первый план выходят сложность и новые проблемы. Этот новый цикл управляется системными компаниями (фирмами-интеграторами систем), такими как Google, Facebook, Amazon, Microsoft, Apple и Tesla, которые создают инновации в областях архитектуры и проектирования. Многие из этих инноваций сосредоточены вокруг искусственного интеллекта.

Это похоже на ситуацию 1980‑х годов, когда корпорация Inmos начала делать свой транспьютер, решив, что может сделать все самостоятельно. Или на аналогичные попытки корпорации Graphecores самостоятельно создать на рубеже 2000‑х годов вычислительную машину с массовым параллелизмом и искусственным интеллектом без привлечения крупнейших поставщиков инструментальных средств САПР. Двадцать лет назад многие пытались создать параллельное аппаратное обеспечение, но для него не было программного обеспечения. Никто не мог запрограммировать это аппаратное обеспечение, и никто не знал, что делать. В настоящее время проблема заключается в том, как запустить эти структуры искусственного интеллекта на аппаратном обеспечении. Вот почему Graphcores и все фирмы, создающие свои разработки на основе Arm, RISC–V или собственных технологических решений, создают собственные микроархитектуры. Эти архитектуры создаются для решения проблем с программным обеспечением. С точки зрения поставщиков САПР это очень интересно, потому что способствует развитию инструментальных средств САПР на основе тех типов технологий и решений, в которых нуждаются сами заказчики. Разработчикам перспективных ИС с минимальными проектными нормами часто требуется не один имитационный прогон модели, а до тысячи. При этом время прогона должно измеряться в часах, а не днях и тем более месяцах. Они также разрабатывают новые архитектуры, которые включают векторную графику и другие перспективные операции, которые реализуют процесс проектирования совсем по-другому. Что же получается в результате? Оказывается, проектировщикам на самом деле не нужно понимать, что представляют собой программные алгоритмы, работающие поверх всего этого. Им просто нужно получить микроархитектуры, чтобы смоделировать то, что им требуется, а поставщикам инструментальных средств САПР необходимо заинтересовать их этим и предоставить соответствующие возможности.

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

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


Заключение

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

Однако все это уже больше не будет простым, и достигнутого никогда не будет достаточно.


Ann Steffora Mutschler. Optimization Driving Changes In Microarchitectures. Electronic Engineering, September 23rd, 2021 https://semiengineering.com/optimization-driving-changes-in-microarchitectures/


ЧИТАЙТЕ ТАКЖЕ

Выпуск 24/25 (6748/6749) от 23 декабря 2021 г. г.
Выпуск 24/25 (6748/6749) от 23 декабря 2021 г. г.