по материалам из Интернет

Физическая верификация СБИС: новый век - новые проблемы

Наступление эры глубоко-субмикронных СБИС размерностью в миллионы условных вентилей, совпадающее с наступлением нового века, делает неизбежными большие перемены в среде средств автоматизированного проектирования. Многие передовые промышленные предприятия присматриваются к проблемам нанометровых проектов и к тому, как удовлетворить возрастающие в связи с этим нужды разработчиков в новых программных инструментах и методологиях проектирования.

Разрыв между технологическими возможностями, которые могут быть реализованы в кремнии, и современными средствами САПР продолжает возрастать. Требуется новое поколение САПР, способное удовлетворить требованиям более быстрого и, одновременно, более точного анализа в нанометровых (глубоко-субмикронных) проектах. Одна из точек, на которой фокусируются проблемы — физическая верификация нанометровых проектов.

Первое, с чем придётся столкнуться, — взрывной характер роста проектных данных, сопровождающий проекты, содержащие сотни миллионов транзисторов. Главная проблема состоит в том, что средства САПР, с одной стороны, должны работать на очень высоком уровне абстракций для того, чтобы завершить проект в отведённое время, а с другой стороны, высокая скорость передачи сигналов требует того, чтобы физическая верификация проекта проводилась при высочайшей степени детализации и точности, что потребует очень больших затрат времени и объёмов данных. Другая сторона этой же проблемы — как наиболее эффективно передать результаты верификации (диагностику) на верхний уровень проектирования для принятия нужного корректирующего решения и генерации откорректированной версии проекта.

Необходимость использования для многомиллионно-вентильных проектов стиля проектирования, основанного на использовании уже имеющихся решений и связанного с применением глубокой иерархии, требует тесной интеграции инструментов, которые непосредственно использует разработчик, и инструментов, которые применяются для анализа проекта на поздних стадиях его разработки, чтобы обеспечить надёжное и непрерывное соответствие целей проекта и проектных данных. Скорее всего, для достижения необходимой интеграции потребуются принципиально новые средства проектирования, так как современные системы проектирования могут быть пригодными только для проектов с нормами до 0,15–0,18 мкм.

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

До последнего времени для этого требовались фактически только редактор топологии, средства размещения и трассировки блоков, контроль геометрических (DRC) и электрических (ERC) проектных норм, сравнение топологической реализации схемы с её исходным описанием (LVS). Теперь же, в проектах с нанометровой геометрией, временной анализ — лишь одна из множества дополнительных процедур, составляющих процесс физической верификации. В системах ближайшего будущего потребуется дополнительно и одновременно с этим решать проблемы питания, целостности сигналов, элект-ромагнитной интерференции, миграции металла, надёжности и термического анализа.

Точная оценка и отслеживание всей совокупности критических параметров требует разрушения барьеров между логическим проектированием, синтезом, физическим проектированием и физической верификацией. Иначе, вариант размещения, явившийся результатом учёта одной проблемы (например, нарушений, выявляемых при временном анализе), может обострить и другую (например, вывести за пределы допустимых отклонений параметры целостности сигналов).

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

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

Современные планировщики не могут справиться с новой ролью, в них просто отсутствует возможность реализации того каскадного эффекта, который оказывает влияние на все другие инструменты в новой методологии. В настоящее время инженеры проводят размещение и трассировку, затем верификацию и получают листинг ошибок и их координат. Затем они вручную проходят по координатам и либо исправляют ошибку, либо игнорируют диагностику. При новом же подходе, получив, например, результаты термического или другого вида финишного анализа, возникает вопрос: что делать с полученной диагностикой? Разработчик уже не может только лишь подкорректировать какой-то топологический примитив (сдвинуть его, модифицировать), как при исправлении ошибки КТО. Корректировка такого рода проблем затрагивает весь каскад инструментов, начиная с переразмещения и перетрассировки. Теперь все виды анализов будут взаимозависимы, поэтому требуется лучшая связь между средствами экстракции параметров, различных видов анализа, размещения и трассировки и, в дополнение к этому, новая методология исправления ошибок. Конфликт между требованием большей точности анализа и большими объёмами входных данных означает то, что методы минимизации данных и выделения в первую очередь наиболее критических элементов должны стать неотъемлемой частью новых средств проектирования вместе с более высокоинтегрированными базами данных и интеллектуальными инструментами работы с ними. Средства проектирования всех уровней должны “понимать” иерархию проекта и настраивать степень точности вычислений в соответствии с уровнем, на котором в данный момент проводятся работы, и в соответствии с выбранным разработчиком соотношением скорость/точность.

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

Но здесь перед разработчиками новых иерархических средств проектирования стоят серьёзные проблемы. Нужно понять, как описывать фрагмент кристалла в качестве “чёрного ящика” в новых условиях, как работать с временными характеристиками и интерфейсами блоков. Использование обширной иерархии проекта делает управление проектными данными очень критичным местом всего процесса проектирования, так как разбиение проекта на меньшие части на множестве уровней иерархии требует очень тщательного отслеживания каждой части на протяжении всего маршрута. Ещё одной проблемой является проблема выделения, “вырезания” самих иерархических блоков. Если проект разбивается на уровни, то где конец уровня — на выходе одного уровня, или на входе другого? Разработчик может выделять элементы иерархии по функциональным признакам или на уровне синтезируемых блоков, но проект может не иметь логических границ на том же самом уровне. И всё-таки, несмотря на все трудности, использование иерархии и новых иерархических методов физического проектирования и физической верификации неизбежно.

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