В наше время невозможно представить жизнь без различной техники. Человечество настолько привыкло к автоматизации, к таким средствам массовой информации и развлечениям, как телевизор, радио, компьютер и т.д., что невозможно существовать без подобных вещей. Все это - электротехника. Практически в любом даже бытовом предмете присутствуют элементы электроники. Даже современные стиральные машинки имеют электронное управление. Таким образом, очень актуальной задачей и проблемой является разработка и создание различного рода электрических схем. Для разработки существует множество компьютерных систем, которые имеют визуальный интерфейс и позволяют довольно легко, быстро, удобно и с большим количеством возможностей моделировать ту или иную идею. Но сам процесс создания микросхемы зачастую является сложным и дорогостоящим. Поэтому нецелесообразно производить деталь, если мы не убедились в ее полезности, работоспособности и т.д. Хорошим решением этой проблемы было создание симуляторов, которые позволяют без создания микросхемы, программно промоделировать её поведение, протестировать её и т.д. Аппаратура описывается на HDL (Hardware Description Language) - языке описания аппаратуры.

Степень интеграции современных СБИС растет экспоненциально[5]. С переходом к технологическим нормам 0,25 мкм и ниже разработчик СБИС при создании сколь угодно сложных систем уже практически не ощущает недостатка в транзисторах на кристалле. На первый план выходит другой сдерживающий фактор – проблема функциональной верификации СБИС. Особую остроту она приобретает при разработке систем на кристалле, включающих не только цифровые, но и аналоговые, смешанные, а также процессорные ядра со встроенным программным обеспечением.

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

Рисунок 1 – Соотношение динамики роста производственных возможностей с производительностью средств проектирования и верификации СБИС

Главная проблема традиционного подхода к функциональной верификации – в том, что она строится по схеме: сначала система разрабатывается и лишь затем – тестируется. Но если верификация поглощает более 60–70% времени или трудозатрат при проектировании СБИС, такая последовательность действий недопустима. Другой важный фактор – экспоненциальное увеличение (от объема СБИС) необходимого числа и длины тестовых векторов, а следовательно, размера и сложности средств тестирования. Одновременно усложняется и процесс поиска причины обнаруженной тестом неисправности.

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

Процесс верификации усложняется не только с ростом степени интеграции СБИС, но и с увеличением числа и разнообразия реализуемых на ней функций. Например, типичная современная система на кристалле включает один или несколько высокопроизводительных процессоров, мультигигабитные интерфейсы ввода-вывода, встроенную оперативную память, сложную систему синхронизации с множеством асинхронных генераторов, аналоговые, смешанные и СВЧ-блоки, встроенное программное обеспечение (ПО), зачастую работающее под управлением операционной системы реального времени (ОС РВ), специализированные устройства цифровой обработки сигналов и многое другое. Поэтому чрезвычайно важное значение приобретает не столько верификация отдельных блоков, сколько верификация их взаимодействия. Так, проектировщики цифровых устройств должны учитывать поведение аналоговых и СВЧ-схем и их взаимодействие с цифровыми блоками. Отладка многих цифровых блоков невозможна без исполнения встроенного ПО. Применение готовых IP-блоков еще больше усложняет верификацию интерфейсов, поскольку они поставляются, как правило, в виде "черных ящиков", не позволяющих анализировать их внутреннее поведение. На рисунке 2 изображена диаграмма зависимости требуемой скорости верификации от сложности объектов.

Рисунок 2 – Рост требуемой скорости верификации при переходе к более сложным объектам

Существует два подхода к решению проблемы верификации. Первый предполагает  усовершенствование самих средств верификации. Современные средства должны обеспечивать верификацию во всех возможных областях. Это – имитационное моделирование, аппаратная эмуляция, программно-аппаратная верификация, аналоговое, цифровое и смешанное моделирование, причем, в идеальном случае, с возможностью взаимодействия всех областей между собой. Средства верификации должны поддерживать все стандартные языки проектирования и верификации – VHDL, Verilog, VHDL_AMS, Verilog_A, Spice, C, C++, SystemC, System Verilog, MATLAB, PSL assertions и др. Второй подход заключается в изменении самой методики верификации, а именно – в переносе соответствующих процедур верификации на более ранние этапы проектирования. Это, как правило, подразумевает создание системных тестов, моделирование на уровне транзакций, верификацию интерфейсов различных подсистем одновременно с их проектированием, т.е. возможность верификации системы, отдельные блоки которой представлены на разных уровнях абстракции. В этом случае, проектирование на системном уровне по существу начинается с создания моделей высокого уровня на основе C, C++, SystemC и System Verilog, оставляя за кадром детали каждого отдельного блока. Такой подход позволяет начинать верификацию системы, не ожидая детальной проработки всех блоков и интерфейсов. Причем интерфейсы между блоками и тестовыми моделями, описанными на разных уровнях абстракции, очень эффективно реализует механизм транзакций.