Специфика верификации в области проектирования аналоговых «систем‑на‑кристалле»

Специфика верификации в области проектирования аналоговых «систем‑на‑кристалле»

Выпуск 10 (6709) от 28 мая 2020 г.
РУБРИКА: МИКРОЭЛЕКТРОНИКА

Недавно журналисты издания Design News взяли интервью у Филлипа А. Хартмана, председателя Рабочей группы по языку SystemC (SystemC Language Working Group), получившего награду «Инициативы по совершенствованию методов проектирования» (Accellera Systems Initiative) за технические достижения (2020 Accellera Technical Excellence Award). В частности, обсуждались различия между верификацией и тестированием и ряд других вопросов.

В чем разница между тестированием и верификацией? Хотя эти термины часто используются как синонимы, они имеют совершенно разные значения, особенно если речь идет о проектировании аналоговых «систем-на-кристалле» (SoC).

При тестировании осуществляется проверка работы уже произведенных микросхем, плат или подсистем. При верификации проверка изделий осуществляется еще до того, как конкретное изделие было создано или произведено (т. е. это проверка разработки на соответствие заданным требованиям на уровне системного проектирования, системотехники).

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

При верификации создаются разнообразные модели, имитирующие поведение микросхем. Соответствие верификационных моделей реальным конструкциям проверяется путем тестирования в автоматическом режиме на испытательных стендах. Если результаты верификации совпадают с исходной проектной моделью уровня регистровых передач (register transfer level, RTL), это означает, что данная часть схемотехники кристалла должна работать с другими, уже производящимися компонентами.

RTL – ​это модель реальной схемы, написанная на языке проектирования аппаратных средств (hardware design language, HDL), таком как VHDL или Verilog. По сути, код HDL описывает то, как данные преобразуются в схеме на основе транзисторов при их передаче из регистра в регистр.

Существует несколько методологических подходов к процессу верификации ИС. Один из них – ​«Универсальная методология верификации» (Universal Verification Methodology, UVM). Грамотный специалист по верификации должен наглядно представлять себе все тонкости проектирования SoC и все функциональные возможности кристалла ИС. Его задача – ​как можно лучше верифицировать каждую строку кода RTL для всех возможных тестовых комбинаций схемы (содержащей миллиарды транзисторов) за счет использования испытательных стендов и тестовых примеров.

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


                       

Источник: Wikimedia

Блок-схема полного цикла проектирования и производства ИС

* Функциональное проектирование (functional design) – начальный этап проектирования микросхемы, составление и верификация ее поведенческого описания.

** Логическое проектирование (logic design) – этап, следующий за функциональным проектированием, на котором создается описание взаимодействия логических элементов без учета их аппаратной реализации.

*** DRC (design rule checker) – программа проверки соблюдения проектных норм.

**** LVS (layout-versus-schematic consistency checker) – программа проверки соответствия топологии электрической схеме.

***** ERC (electrical rule checker) – программа проверки соблюдения электрических норм.


и цифро-аналоговой обработки сигнала (analog/mixed-analog, AMS). Соответственно, растет и интерес к возможности верификации AMS при помощи стандарта UVM. В связи с этим многие проектировщики считают, что, во‑первых, в области AMS ИС необходимо повысить уровень абстракции – ​в направлении уровня, достигнутого в сфере цифровых ИС. Во-вторых, существует проблема повторного использования и верификации моделей AMS ИС (причем одним и тем же образом) на всех уровнях абстракции. Неудивительно, что проектировщики таких приборов завидуют наличию стандарта UVM у разработчиков цифровых ИС и желают получить для использования что-либо подобное.

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

Интересно, что подобный подход чаще используется в Европе, чем в США. Часть решений в области синтеза высокого уровня основана на языке программирования SystemC, другая часть в большей степени ориентирована на язык C++. Подход с использованием языка SystemC ближе к верификации и моделированию на системном уровне, больше подходит для создания опытных образцов SoC, исследования архитектуры и т. д. Однако выбор языка программирования – ​дело вкуса, обусловленное опытом проектировщика. Борьба языков Verilog против VHDL и System Verilog против SystemC – ​давняя проблема. Каждый специалист предпочитает работать с тем, что ему лучше знакомо. Многие компании осуществляют моделирование своих ИС с использованием языка SystemC, а затем генерируют на нем и RTL. Однако верификация часто начинается на уровне Verilog – ​что означает необходимость преобразования в Verilog всего, что было сгенерировано в SystemC. Это очень сложный процесс, а его использование – ​вынужденная мера, отчасти потому, что многие фирмы не хотят проводить верификацию с использованием SystemC (иначе говоря, считают, что для верификации Verilog подходит намного лучше, чем SystemC).

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


Blyler John. What is the Difference Between Test and Verification? Design News, April 14, 2020: https://www.designnews.com/design-hardware-software/what-difference-between-test-and-verification/88...


МНЕНИЕ ЭКСПЕРТА

Алексей Мешков

Современные «системы-на-кристалле» состоят из миллиардов транзисторов, включающих в себя как цифровую, так и аналоговую логику. Затраты на верификацию таких систем составляют значительную часть в разработке и по различным оценкам достигают 50–80% всех затрат на проектирование. Вместе с тем верификация необходима, поскольку позволяет выявить значительную долю ошибок до того, как будут получены готовые экземпляры изделий. Подход к верификации, применяемый в АО «МЦСТ», использует разнообразные решения – это тестовые системы и модели, разработанные по методологии UVM, основанной на языке System Verilog для верификации отдельных устройств и подсистем; и верификация крупных блоков на основе эталонных моделей, разработанных на языке С++; и прототипирование с использованием ПЛИС. С одной стороны, такой подход позволяет качественно повысить уровень и надежность верификации, но с другой – разнообразие средств зачастую приводит к дублированию однажды проделанной работы. Поэтому движение в сторону стандартизации методологии UVM-SystemC, являющейся в свою очередь надстройкой над С++, можно только приветствовать, так как это позволит повысить возможности повторного использования моделей и концепций языка С++ для целей верификации. Алексей Мешков, кандидат технических наук, начальник отдела моделирования и верификации АО «МЦСТ»

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

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