- •Программа drc
- •1. Из меню Verify выбираем опцию drc
- •2. Запуск drc.
- •Программа Analog Artist
- •Шаг 1: Экстракция из топологии.
- •1. Из меню Verify выбирете опцию Extract
- •Шаг 2: Представление(вид) экстрагированной ячейки.
- •Проверка версии топологии для описанной схемы.
- •Шаг 5: Моделирование экстрагированного представления ячейки.
- •2. Из меню Setup oткрываем опцию Environment.
- •3. Выбор анализа.
1. Из меню Verify выбирете опцию Extract
( verify --> Extract )
Появится новое окно с параметрами опции экстракции. Заданные по умолчанию параметры экстрагируют (извлекут) только идеальные элементы. Этот идеальный случай дает результат подобный моделированию из схемного описания. Для более точного представления, однако, мы должны учесть паразитные эффекты. Чтобы получить экстракцию паразитных компонентов, должны быть определены параметры выбора, названные переключателями. Можно ввести переключатель в выделенном блоке, или можно выбрать его из меню, используя опцию Set Switches.
Напримере, чтобы выполнить экстракцию паразитных емкостей, задан переключатель Extract_parasitic_caps.
Проверьте Окно Командного Интерпретатора (основное окно при запуске Cadance) на предмет наличия ошибок после экстракции.
После успешной экстракции Вы увидете новое представление(вид) ячейки названное экстрагированным (extracted) для вашей ячейки в библиотеке(library manager). См. следующий раздел для вызова(доступа)к экстрагированному представлению.
Шаг 2: Представление(вид) экстрагированной ячейки.
Итак, после шага экстракции новое представление ячейки сгенерировано в вашей библиотеке. Это представление (вид) ячейки названо extracted представлением.
В результате загрузки экстрагированного представления, откроется топология, которая выглядит почти идентично топологии, которую экстрагировали. Однако, обратите внимание, что только выводы Входа - выхода появляются как твердые блоки, и все другие формы появляются как основные.
Красные прямоугольники указывают, что это компоненты внутри некоторой иерархии проекта. Нажимая Shift-F, можно видеть всю иерархию.
Видно ряд символов. Если увеличить (zoom), то возможно будет идентифицировать отдельные элементы, типа транзисторов и конденсаторов. Обратите внимание, что параметры (например, размеры канала) этих элементов имеют значения, они были получены из топологии.
Кроме введенных вами элементов схемы имеется ряд элементов, главным образом конденсаторы в экстрагированном представлении ячейки. Это - не элементы схемы, а паразитные емкости, т.е. побочные эффекты при формировании топологии с помощью различных слоев.
Следующий шаг будет соответствие экстрагированного списка связей (netlist) к таковому схемному решению. Это называется проверкой версии топологии для описанной схемы. Это гарантирует, что схемное решение, которое было введено и топология, идентичны.
Проверка версии топологии для описанной схемы.
После того, как топология проекта схемы завершена, проект должен быть проверен со схематическим описанием, созданным ранее. Моделирование, названное "Проверкой топологического решения схемы (Layout-versus-Schematic (LVS)) " сравнит первоначальные связи с тем, что экстрагирован из топологии, и докажет, что два списка связей - действительно эквивалентны. Шаг LVS обеспечивает дополнительный уровень достоверности для целостности проекта, и гарантирует, что эта топология - правильная реализация схемы. Обратите внимание, что проверка LVS только гарантирует топологическое соответствие: успешный LVS не будет гарантировать, что извлеченная схема действительно удовлетворит требованиям технического задания. Любые ошибки, которые могут быть обнаружены в течение LVS (типа неопределенные соединения между транзисторами, или отсутствующие соединения / элементы, и т.д.) должны быть исправлены в топологии перед продолжением моделирования после топологии. Также обратите внимание, что шаг экстрагирования должен повторяться каждый раз, когда изменяется топология.
Шаг 3: Топологическая версия схемы.
Следующим шагом мы сравним схемное решение и экстрагированную топологию, чтобы видеть, являются ли они идентичны.
Из меню Verify выбираем опцию LVS.
Если Вы предварительно выполнили проверку LVS, то выскочит маленькое окно предупреждений. Удостоверитесь, что опция Form Contents выбрана в этом окне.
Верхная половина LVS окна параметров - разбита на две части. Часть слева соответствует схематическому представлению ячейки (schematic), и правая часть соответствует экстрагированному представлению ячейки (extracted), которые должны сравниваться. Удостоверитесь, что введенное в этих рамках представляет значения для вашей схемы.
Хотя имеется ряд параметров для LVS, выберете Run, чтобы запустить сравнение с заданными по умолчанию параметрами, достаточными для выполнения базисных вычислений.
Алгоритм сравнения выполнится на заднем плане, результат выполненного LVS будет отображаться в окне сообщений. Будьте терпеливы, даже для очень маленького проекта, выполнение LVS может длиться некоторое время (минуты).
Успешное сообщение в вышеупомянутом окне сообщений, указывает, что программа LVS закончила сравнивать списки связей (netlists), NOT THAT THE CIRCUITS MATCH. Это могло бы иметь место, что LVS был успешен в сравнении netlists и придумал результат, что обе схемы были различны.
Наблюдая за результатом выполнения LVS , Вы должны проверять вывод программы LVS. Опция Output справа рядом с командой Run.
На рисунке приводится полный результат LVS. Наиболее важная часть отчета может быть для неудачного случая. Тогда список связей действительно не соответствует. Если Вы обнаруживаете, что имеется несоответствие, то должны возвратиться к топологии, найти и исправить ошибку (ошибки).
Большинство других параметров формы LVS, используется для нахождения несоответствий между двумя списками связей (netlists) и генерации списка связей, включающего только паразитные эффекты, относящиеся к одной части схемы.
Пример распечатки проверки списка связей.
@(#)$CDS: LVS version 4.4.1 03/17/98 22:19 (cds10067) $
Like matching is enabled.
Net swapping is enabled.
Using terminal names as correspondence points.
Compiling Diva LVS rules...
Net-list summary for /home/kgf/cds/LVS/layout/netlist
count
4 nets
4 terminals
1 pmos
1 nmos
Net-list summary for /home/kgf/cds/LVS/schematic/netlist
count
4 nets
4 terminals
1 pmos
1 nmos
Terminal correspondence points
1 gnd!
2 in
3 out
4 vdd!
The net-lists match.
layout schematic
instances
un-matched 0 0
rewired 0 0
size errors 0 0
pruned 0 0
active 2 2
total 2 2
nets
un-matched 0 0
merged 0 0
pruned 0 0
active 4 4
total 4 4
terminals
un-matched 0 0
total 4 4
Probe files from /home/kgf/cds/LVS/schematic
devbad.out:
netbad.out:
mergenet.out:
termbad.out:
prunenet.out:
prunedev.out:
audit.out:
Probe files from /home/kgf/cds/LVS/layout
devbad.out:
netbad.out:
mergenet.out:
termbad.out:
prunenet.out:
prunedev.out:
audit.out:
Шаг 4: Результат представлений ячейки.
Так как создано несколько представлений ячейки, рассмотрим соответствие их самой схеме. В этом разделе мы хотим сделать обзор всех этих представлений ячейки и обсудить, для чего они используются.
Представление Schematic
Для любого проекта, схемное решение должно быть первым созданным представлением ячейки. Схемное решение является базисной ссылкой выбранной схемы.
Представление Symbol
Соответствующий путь выполнения состоит в том, чтобы проверку схемного решения проводится отдельно. Для этого схему описывают как блок, с помощью созданного символа.
Представление Layout.
Это - фактические данные фотошаблонов, которые будут изготовлены. Они могут быть сгенерированы автоматизированными инструментальными средствами или вручную.
Представление Extracted
После того, как топология завершена, из нее экстрагируют идентифицированные компоненты и паразитные элементы, и формируют список связей (netlist).
Тестовая схема.
Отдельная ячейка используется как место для размещения теста. В описание элемента теста включают источники, нагрузки, схему тестирования. Ячейка теста обычно состоит только из одиночного схемного решения.