Создание элемента собственной библиотеки

 

В пакете OrCAD используется библиотечный метод проектирования. Он заключается в том, что проектируемое устройство «собирается» из отдельных готовых деталей, называемых компонентами (Component). Ими могут быть резисторы, конденсаторы, транзисторы, реле, разъемы, микросхемы и прочие радиоэлектронные изделия. Все компоненты объединяются в библиотеки, которые входят в состав пакета. Они называются системными. Пользователь может создавать новые описания компонентов и включать их в уже существующие библиотеки. При желании можно организовать и свои личные библиотеки. Они называются пользовательскими.

Общее число библиотечных компонентов достигает в современных САПР нескольких десятков тысяч. Так, например, пакет OrCAD содержит более 30 тысяч компонентов. Однако при использовании библиотек системы OrCAD необходимо помнить, что в нем фактически объединены библиотеки двух пакетов — собственно OrCAD и DesignLab 8 фирмы MicroSim, которая в 1998 году вошла в состав фирмы OrCAD. Кроме того, в системе OrCAD в одном проекте нельзя объединять компоненты, поддерживаемые SPICE-моделями (проекты типа PCB — PSpice) и VHDL-моделями (PCB — Simulate). «Инородные» для данного типа проекта компоненты будут просто игнорироваться.

Другая сложность, характерная для всех современных САПР, заключается в том, что любой компонент имеет не одно, а несколько различных описаний и они хранятся в разных местах. На принципиальной схеме компонент представляется в виде условного графического обозначения (УГО). Его принято называть символом (Part, Symbol). Символы компонентов объединяются в библиотеки, имеющие расширение *.olb. Таким образом, в OLB-библиотеках хранятся схемные образы компонентов. В них отсутствует информация о форме и физических размерах (габаритах) реальных компонентов.

На печатной плате тот же компонент выглядит совсем иначе. Здесь главное передать его физические размеры и форму, чтобы выяснить, сколько места потребуется для его размещения. Такое описание, в отличие от схемного, называют конструкторским или физическим. Оно представляет собой габаритную проекцию корпуса компонента на печатную плату. Иногда его называют футпринтом, или «отпечатком» корпуса (от английского слова footprint — дословно: отпечаток ступни). Конструкторские описания хранятся в библиотеках с расширением *.llb и используются при трассировке печатных плат.

Для моделирования проекта требуется еще одно, третье по счету, описание компонента — описание его функции, поведения или алгоритма работы. Это описание обычно называют функциональным или поведенческим, иногда математическим. Оно задает правило, по которому вычисляется реакция компонента на входные воздействия. По этой причине третий вид описаний называют моделями (аналитическими или имитационными, поведенческими или структурными).

В пакете OrCAD для построения моделей используется стандартный язык описания аппаратуры VHDL, в пакете DesignLab 8 применяются так называемые SPICE-модели. Названные типы моделей не могут обрабатываться одной моделирующей программой, поэтому в OrCAD их две: Simulate для VHDL-моделей и программа PSpice A/D для SPICE-моделей. Для каждого типа моделей должны быть свои библиотеки. VHDL-модели хранятся в библиотечных файлах с расширением *.vhd, а SPICE-модели – в библиотеках с расширением *.lib. В обоих случаях это текстовые файлы. Первые находятся в папке Orcad_10/Capture/Library, вторые – в папке Orcad_10/Capture/Library/Pspice. Кроме того, при проектировании принципиальных схем и разводке печатных плат требуется информация о том, каким образом и сколько символов компонента упаковывается (помещается) в его корпус. Например, в корпус компонента 555LA3 (аналог 74ls00) упаковано четыре вентиля 2И-НЕ, в корпус компонента 555TM2 (аналог 74ls74) — два D-триггера, а в корпус компонента 555LN1 (аналог 74ls04) — шесть инверторов. Необходимо также указывать, к каким выводам корпуса компонента подключены входы и выходы каждого символа, на какие «ножки» подается питание, какие контакты являются взаимозаменяемыми (логически эквивалентными). Эти описания называются упаковочной информацией (Package) и в некоторых САПР хранятся в отдельных библиотеках. Например, в пакете DesignLab — в библиотеках с расширением *.plb. В САПР OrCAD упаковочная информация включена в библиотеки схемных описаний *.olb.

Для проектирования схем и их функциональной верификации необходимы только OLB- и VHD-библиотеки. Именно они и будут рассматриваться в дальнейшем.

Очень часто имеет смысл работать не с системными библиотеками, а со своими личными, необходимыми конкретному отдельному пользователю. В них обычно хранятся только те компоненты, которые встречаются в рабочем проекте. Кроме того, пользователь может отредактировать свойства компонентов под свои специфические требования, не искажая при этом системных библиотек. Разработчики пакета OrCAD, предвидя такую потребность, добавили в файловую структуру каждого проекта специальный раздел, так называемый кэш проекта (Design Cache). Фактически это встроенная в проект библиотека, содержащая копии всех компонентов, используемых в проекте. Кроме того, кэш проекта выполняет еще одну роль. Он является своеобразным буфером, защищая системные библиотеки от неосторожного обращения с ними.

Однако определенную сложность представляет то, что фирменные библиотеки пакета OrCAD содержат описания только зарубежных компонентов. Их имена и графические изображения, как правило, не соответствуют отечественным стандартам. Поэтому российскому пользователю приходится создавать свои графические описания (или редактировать зарубежные), не ограничиваясь при этом рамками одного проекта. Ну а результаты такой работы удобнее всего сохранять в своей личной библиотеке.

Следует обратить внимание еще на одну особенность пакета OrCAD – он содержит схемные библиотеки двух различных типов, компоненты из которых нельзя смешивать в одном проекте. Возможно, по этой причине даже однотипные компоненты имеют некоторые различия в графических описаниях. Кроме того, одни и те же выводы имеют разные имена (сравните I0, I1, — слева, A, B, Y — справа), и уже по этой причине такие элементы не могут моделироваться одной функциональной моделью.

 

Для начала создадим свою личную Olb-библиотеку (для схемных описаний) и назовем ее my_lib.olb. Запустим графический редактор OrCAD Capture и активизируем команду File/New/Library. Откроется окно со стандартным названием библиотеки LIBRARY1 (рис. 1). Если это имя не подходит, его можно заменить другим – my_lib.olb. Для этого необходимо щелкнуть правой кнопкой на строке с названием библиотеки, и когда откроется всплывающее меню, выполним команду Save as….

 

Рис. 1

Необходимо ввести нужное имя и сохранить библиотеку. При повторном открытии личной библиотеки (команда File/Open/Library…) получаем желаемый результат. Теперь необходимо скопировать в свою библиотеку my_lib.olb какие-нибудь компоненты из системной библиотеки, например из ttl.olb. Командой File/Open/Library… загрузим в редактор OrCAD Capture обе библиотеки и расположим их окна рядом (рис. 2). Выделим копируемый элемент, например 7404, и отбуксируем его в окно my_lib на строку с тем же названием. Операцию следует выполнять при нажатой клавише Ctrl, иначе вместо копирования будет выполнено перемещение элемента.

Рис. 2

Описанный способ копирования называется «Drag-and-drop». Тот же результат будет получен, если копирование компонента выполнять через буфер обмена Clipboard. При копировании одного элемента, в итоге в библиотеке их оказалось более двух десятков. Связано это с тем, что вслед за копируемым элементом в новую библиотеку были помещены и все графически подобные элементы (алиасы), а таких для компонента 7404 оказалось много – 27 штук. В действительности в библиотеке ttl.olb хранится один графический образ компонента 74LS04 (так решили разработчики пакета OrCAD), а все остальные подобные ему компоненты только ссылаются на своего «родителя». Иначе говоря, компонент 74LS04 имеет 26 псевдонимов (алиасов, дополнительных имен). Такое решение существенно экономит объем библиотечного Olb-файла, так как вместо 27 рисунков-копий в библиотеке хранится только один оригинал. Кроме того, у всех графически подобных элементов к тому же одинаковая упаковочная информация, так что выигрыш оказывается еще более значительным.

Выделим любой элемент, щелкним на нем правой кнопкой и выполним команду "Edit Part". Для редактирования откроется окно с изображением компонента 74LS04, а не того, на котором вы щелкали мышью. Если проделать эту операцию для нескольких элементов – результат останется прежним: во всех случаях вызываться будет компонент 74LS04.

Далее необходимо выполнить команду View/Package, для того, чтобы увидеть данные об упаковке все того же «родителя» — компонента 74LS04. Кроме того, можно выполнить команду Options/Package Properties…. Откроется диалоговая панель Edit Part Properties, на которой надо нажать кнопку Part Aliases… Появится новая панель с аналогичным названием (рис. 3), и можно увидеть все псевдонимы компонента 74LS04. Выделить весь список (с помощью клавиши Shift) и удалить алиасы, нажав на клавишу Delete. В результате из библиотеки my_lib.olb исчезли все элементы, кроме 74LS04. Кстати, его можно переименовать (командой Rename из всплывающего меню) в элемент 7404.

 

Рис. 3

Описанным выше приемом необходимо скопировать в личную библиотеку my_lib.olb компоненты 7408 и 7432, избавиться от всех ненужных алиасов и сохранить результат. Все элементы в созданной библиотеке вполне работоспособны.

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

Нарисовать схему замещения проектируемого иерархического символа, выбрав для простоты мультиплексор на два входа mux2 Открыть новый проект с тем же названием, подключить к нему библиотеку my_lib.olb и создать в нем схему мультиплексора mux2. Так как это будет «внутренняя начинка» иерархического символа (рис. 4а), подрисовать к ней входные и выходные порты (команда Place/Hierarchical Port…), чтобы образовать вертикальные связи с внешним описанием (рис. 4б).

Рис. 4, а

 

 

Рис. 4, б

 

Назвать открытую по умолчанию папку SCHEMATIC1 другим именем, например mux2_HS, иначе ее будет трудно отыскать в библиотеке. Сохранить проект и закрыть рабочее окно со схемой замещения. Последняя операция совершенно необходима, иначе не сработает метод «Drag-and-drop», да и вообще любое копирование или перемещение.

Теперь можно открыть библиотеку my_lib.olb и скопировать в нее папку mux2_HS. Если операция выполнена успешно, то в файловой структуре библиотеки появилась нужная папка, а в кэше библиотеки (Library Cache) — соответствующие компоненты, входящие в схему замещения (рис. 5).

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

Поскольку библиотека my_lib.olb уже открыта, необходимо щелкнуть на папке с ее названием правой кнопкой мыши и выполнить команду New Part. Откроется панель New Part Properties. Ввести в поле Name имя символа mux2_HS, в следующем окне префикс U изменим на HS и перейти к самому важному – нужно сделать ссылку на схему замещения иерархического символа. Для этого надо нажать кнопку Attach Implementation… (Подключить реализацию, то есть дополнительное описание). В нашем случае – это схема замещения, хранимая в папке mux2_HS. Откроется диалоговая панель с тем же названием (рис. 6, а). В верхнее поле Implementation Type ввести тип внутреннего описания: Schematic View – схема замещения, в следующее поле Implementation (реализация) – имя папки, где она хранится, нижнее поле оставить пустым, так как схема замещения находится в той же самой библиотеке, что и символ. Разместить контакты и нарисовать графику символа в соответствии с рис. 6, б.

Рис. 6, а

Рис. 6, б

Далее необходимо протестировать полученный символ. Создадим новый проект test_mux2_HS.opj, подключим к нему личную библиотеку my_lib.olb и файл ttl.vhd с функциональными моделями компонентов, используемых в проекте. Разместим в окне графического редактора одну копию иерархического символа mux2_HS, подведем к его выводам проводники и проименуем их.

Временные диаграммы mux2_HS выглядят следующим образом:

 

Теперь необходимо сообщить редактору OrCAD Capture, что символ mux2_HS не является примитивом, что это иерархический символ. Для этого дважды щелкнуть на нем левой кнопкой мыши, и, когда откроется окно редактора свойств Property Editor, изменить значение свойства Primitive с DEFAULT (по умолчанию символ считается примитивом) на NO. Убедимся, что символ теперь имеет подчиненную схему. Для этого достаточно выполнить команду View/Descend Hierarchy или нажать комбинацию клавиш Shift+D. Редактор должен понизить иерархию описания и показать схему замещения непримитивного символа mux2_HS.

Если в схеме много непримитивных символов, то проще выполнить групповую операцию по изменению их статуса. Для этого в менеджере проекта выделить проект (имя файла с расширением *.dsn) и выполнить команду Options/Design Properties…. В открывшейся диалоговой панели выбрать вкладку Hierarchy и в разделе Part установить опцию Nonprimitive.

 

1. Запустим графический редактор OrCAD Capture и активизируем команду File/New/Library. Откроется окно со стандартным названием библиотеки LIBRARY1 (рис. 1). Нас не устраивает это имя, и мы сразу заменим его другим — dtrigger.olb. С этой целью щелкнем правой кнопкой на строке с названием библиотеки, и когда откроется всплывающее меню, выполним команду Save as….

 

Рис. 1

2. Закрываем библиотеку и создаем новый проект.

3. Рисуем схему Д-Триггера на элементной базе 74ALS (Рис.2)

 

Рис. 2

4. Назовем открытую по умолчанию папку SCHEMATIC1 другим именем, например dtrigger, иначе ее будет трудно отыскать в библиотеке. Сохраним проект и закроем рабочее окно со схемой замещения.

5. Теперь можно открыть библиотеку dtrigger.olb и скопировать в нее папку dtrigger. Убедитесь, что операция выполнена успешно: в файловой структуре библиотеки появилась нужная папка, а в кэше библиотеки (Library Cache) — соответствующие компоненты, входящие в схему замещения (Рис.3, 4)

 

Рис. 3

 

Рис. 4

6. Библиотека dtrigger.olb уже открыта. Щелкнем на папке с ее названием правой кнопкой мыши и выполним команду New Part. Откроется панель New Part Properties. Введем в поле Name имя символа D-Trigger, в следующем окне префикс U изменим на D и перейдем к самому важному: нам предстоит сделать ссылку на схему замещения иерархического символа. Нажмем кнопку Attach Implementation… (Рис.5)

 

Рис. 5

7. В верхнее поле Implementation Type введем тип внутреннего описания: Schematic View – схема замещения, в следующее поле Implementation (реализация) – имя папки, где она хранится, нижнее поле оставим пустым, так как схема замещения находится в той же самой библиотеке, что и символ. (Рис.6)

 

Рис. 6

8. Разместим контакты и нарисуем графику символа в соответствии с рис. 7

 

Рис. 7

9. Протестируем наш символ. Создадим новый проект test_D.opj, подключим к нему личную библиотеку dtrigger.olb

10. Теперь предстоит самая важная работа: надо сообщить редактору OrCAD Capture, что символ dtrigger не является примитивом, что на самом деле – это иерархический символ. Дважды щёлкнем на нём левой кнопкой мыши, и, когда откроется окно редактора свойств Property Editor, изменим значение свойства Primitive с DEFAULT (по умолчанию символ считается примитивом) на NO. (рис.8)

 

Рис 8

11. Промоделируем наш созданный элемент на мин-макс задержки. И получим временные характеристики. (рис. 10, 11, 12, 13).

 

Рис. 9

Рис. 10

Рис. 11

Рис. 12

 

Вывод:

время задержки при переключении из 0 в 1 Q равно 12 нс

время задержки при переключении из 1 в 0 Q равно 18 нс

время задержки при переключении из 0 в 1 NQравно 12 нс

время задержки при переключении из 1 в 0 NQравно 18 нс

 

1. Запустим графический редактор OrCAD Capture и активизируем команду File/New/Library. Откроется окно со стандартным названием библиотеки LIBRARY1 (рис. 1). Нас не устраивает это имя, и мы сразу заменим его другим — my_lib.olb. С этой целью щелкнем правой кнопкой на строке с названием библиотеки, и когда откроется всплывающее меню, выполним команду Save as….

 

Рис. 1

2. Закрываем библиотеку и создаем новый проект.

3. Рисуем схему мультиплексор на два входа mux2 (рис.2)

 

Рис. 2

4. Назовем открытую по умолчанию папку SCHEMATIC1 другим именем, например mux2_HS, иначе ее будет трудно отыскать в библиотеке. Сохраним проект и закроем рабочее окно со схемой замещения.

5. Теперь можно открыть библиотеку my_lib.olb и скопировать в нее папку mux2_HS. Убедитесь, что операция выполнена успешно: в файловой структуре библиотеки появилась нужная папка, а в кэше библиотеки (Library Cache) — соответствующие компоненты, входящие в схему замещения (рис.3, 4)

 

Рис. 3

Рис. 4

6. Библиотека my_lib.olb уже открыта. Щелкнем на папке с ее названием правой кнопкой мыши и выполним команду New Part. Откроется панель New Part Properties. Введем в поле Name имя символа mux2_HS, в следующем окне префикс U изменим на HS и перейдем к самому важному: нам предстоит сделать ссылку на схему замещения иерархического символа. Нажмем кнопку Attach Implementation… (Рис.5)

 

Рис. 5

7. В верхнее поле Implementation Type введем тип внутреннего описания: Schematic View — схема замещения, в следующее поле Implementation (реализация) — имя папки, где она хранится, нижнее поле оставим пустым, так как схема замещения находится в той же самой библиотеке, что и символ. (Рис.6)

 

Рис. 6

8. Разместим контакты и нарисуем графику символа в соответствии с рис. 7

 

Рис. 7

9. Протестируем наш символ. Создадим новый проект test_mux2_HS.opj, подключим к нему личную библиотеку my_lib.olb

10. Теперь предстоит самая важная работа: надо сообщить редактору OrCAD Capture, что символ mux2_HS не является примитивом, что на самом деле – это иерархический символ. Дважды щёлкнем на нём левой кнопкой мыши, и, когда откроется окно редактора свойств Property Editor, изменим значение свойства Primitive с DEFAULT (по умолчанию символ считается примитивом) на NO. (рис.8)

 

Рис. 8

11. Промоделируем наш созданный элемент на мин-макс задержки. И получим временные характеристики. (рис.9, 10)

 

Рис. 9

Рис. 10