FAQ (ЧаВО) по PROTEUS для начинающих и не только

[Halex07]

ЧАСТЬ II. PROTEUS для продвинутых пользователей

3. Виды симуляции и типы моделей в ISIS.

3.1. Интерактивное и графическое моделирование. PROSpice - ядро симулятора ISIS.

Прежде чем мы продолжим изучение непосредственно программы Proteus, необходимо сделать небольшое лирическое отступление для того, чтобы следующий материал был более понятен. Имитация реального поведения электронных компонентов и схем составленных из них в программе ISIS основывается на применении SPICE-моделирования поведения компонентов. Язык SPICE (Simulation Program with Integrated Circuit Emphasis) был разработан в Калифорнийском университете Беркли в начале семидесятых годов прошлого века и де-факто стал основой для большинства программ, симулирующих поведение электронных компонентов. Это и P-CAD и MultiSim (Workbench) и даже такой монстр, как OrCAD. Отличие Протеуса от упомянутых заключается в том, что если там используется версия языка PSPICE (разработанная фирмой MicroSim Corporation, которую в 1998 году благополучно «проглотил» OrCAD), то ISIS ProSPICE базируется на другом клоне, именуемом SPICE3F5. Поскольку начиная с версии PSPICE2 в ней появились некоторые отличия от стандарта SPICE разработчики Протеуса предупреждают, что не всегда SPICE-модели сторонних фирм, большинство из которых предоставляет PSPICE-модели будут адекватно симулироваться в ISIS. Тем не менее, если заглянуть в библиотеки аналоговых компонентов ISIS, то можно заметить, что большинство моделей представлены именно SPICE-моделями.
ISIS поддерживает как интерактивную симуляцию в реальном времени, так и симуляцию с помощью графиков, воспроизводящих сигналы в определенных точках схемы с установленными там пробниками. В любом случае поведение схемы просчитывается с помощью встроенного в программу симулятора ProSPICE. С каждой новой версией Proteus ядро Prospice обновляется, например в версии 7.6 SP0 поставляется и версия симулятора ProSPICE 7.6.00. Версию ядра вашей копии Proteus всегда можно посмотреть в логе симуляции после запуска на выполнение любого проекта или графика. ProSPICE различных версий не взаимозаменяемы и защищены лицензией на программу. Чем новее версия Proteus, тем более быстрое ядро ProSPICE встроено в программу.
Однако, даже самые последние версии не в состоянии удовлетворить запросы наших амбициозных пользователей. Поэтому, если вы при симуляции схемы в реальном времени получаете в логе программы загрузку ЦП компьютера 100% и сообщение:

Simulation is not running in real time due to excessive CPU load
Симуляция не работает в реальном времени из-за чрезмерной загрузки центрального процессора

стоит подумать об использовании графиков для анализа поведения схемы.
Как правило это сообщение вылетает из-за чрезмерной нагруженности схемы аналоговыми компонентами и попыткой иммитировать их работу на достаточно высоких частотах. Возможности ЦП компьютера небезграничны, а при интерактивной симуляции львиная часть ресурсов «съедается» на поддержку элементов, содержащих активную графику: индикация, анимированные провода и пробники и т.п. Не стоит забывать, что и виртуальные инструменты: осциллограф, таймер-частотомер, вольтметры/амперметры и пр. сами по себе являются активными моделями и тоже нагружают симулятор. В то же время при рассчете графиков такой важный фактор, как быстродействие компьютера отходит на второй план. Протеус все равно рассчитает точки графика, только затратит на это больше времени. Именно поэтому применение графиков для анализа аналоговых схем предпочтительно. По этому поводу приведу дословную цитату из ProSPICE HELP (раздел ADVANCED TOPICS =› How to make interactive simulations run faster (Как сделать интерактивную симуляцию быстрее):

«Моделирование цифровой схемы на два три порядка (т.е. вплоть до 1000 раз) быстрее, чем аналоговой. Это объясняется тем, что входящий в ProSPICE цифровой симулятор при обработке цифровых элементов опускает множество ненужных вычислений.
Например, компьютер с процессором Пентиум III 600 МГц может обрабатывать до 2 миллионов цифровых событий в секунду, но у того же компьютера при симуляции синусоидального генератора частотой 2 кГц загрузка ЦПУ может достигнуть 100%. Такая форма сигнала потребует расчета приблизительно 60 000 временных точек в секунду и для каждой из этих точек необходимо, чтобы было найдено решение уравнения сходимости – процесс намного более сложный, чем обработка простого цифрового сигнала.
Для многих компонентов интуитивно понятно: какое моделирование требуется – аналоговое или цифровое. Например, почти вся ТТЛ-логика и часть КМОП представлены цифровыми моделями, в то время, как аналоговые ИС: операционные усилители, компараторы - аналоговыми. Все компоненты представленные (имеется ввиду в библиотеках) стандартными SPICE моделями требуют только аналогового моделирования.
Для некоторых целей строго аналоговые по своей природе компоненты диоды и резисторы могут быть представлены цифровой моделью. Это справедливо для монтажного ИЛИ, подтягивающих резисторов, элементов с открытым коллектором на выходе и диодно-резисторной логики.»

Ну вот мы постепенно и подошли к рассмотрению типов моделей в Протеусе.

[Halex07]

3.2. Типы моделей в ISIS.
Если исключить из рассмотрения чисто графические модели, напротив которых в библиотеках стоит: No Simulator Model (Не симулируемая модель), а к ним относятся практически все разъемы и часть компонентов, к которым пока не разработаны модели, то все остальные можно поделить на четыре больших группы: различные Primitive (примитивы): Analogue, Digital, PLD, Mixed (аналоговые, цифровые, программируемые логические матрицы, смешанные); SPIСE Model (Модели SPICE); Schematic Model (Схематичная модель) и VSM DLL Model (Программные модели, объединенные в библиотеках DLL). На резонный вопрос – а зачем вообще представлены No Simulator Model, сразу отвечу – не забывайте, что существует еще и ARES, а как передать в него тот же разъем, если к нему нет ни схемного изображения, ни футпринта (расположения выводов и занимаемого на печатной плате места). Вот для этих целей и находятся в библиотеках ISIS такие компоненты и если вы установили их в схему и попытаетесь запустить симуляцию, то получите сообщение об ошибке:

No model specified for (обозначение элемента)
Simulation FAILED due partition analysis error(s)

Об этом я уже говорил, но повториться не вредно – для таких моделей в свойствах установите галочку Exclude from Simulation (Исключить из симуляции), чтобы избавиться от этой ошибки. Приступим к краткому рассмотрению остальных.

Сначала поговорим о примитивах. Analogue Primitive и Digital Primitive: К первым относятся большинство резисторов, конденсаторов, часть моделей транзисторов и диодов. Ко вторым элементы цифровой логики из библиотеки Simulator Primitives и часть цифровых элементов из других библиотек. По своей сути это те же SPICE-модели, но встроенные непосредственно в симулятор ProSPICE. Особо хочу отметить примитивы из библиотеки Simulator Primitives, которые мы впоследствии будем использовать при создании схематичных моделей компонентов. Как и все SPICE-модели они содержат ряд характерных свойств, которые заданы по умолчанию, но могут быть измененны пользователем по своему усмотрению. Описание Properties (свойств), характерных для того или иного примитива всегда можно посмотреть в хелпе ProSPICE Primitives (Рис. 1).Кроме того, практически всегда доступна кнопка HELP при вызове свойств примитива, установленного в поле проекта (Рис. 2). Не стоит пренебрегать этими возможностями, особенно при моделировании аналоговых схем. Зачастую изменение всего одного из свойств компонента позволяют «оживить» молчавшую до этого схему. Ну и еще, что касается этих свойств. При создании более сложных моделей из примитивов они наследуют Properties, входящих в их состав примитивов и изменение этих свойств в окне Other Properties немедленно отзовется на поведении модели. Задание поведения и свойств PLD Primitive (логических матриц) осуществляется с помощью таблиц соответствия, содержащихся в JEDEC файлах. Подробно они рассмотрены в соответствующем разделе HELP: PLD Modelling Primitives. Особо хочу остановиться на Mixed Model Primitives, содержащих как аналоговые, так и цифровые свойства. Ряд свойств этих моделей применим в частности к КМОП логике и позволяет управлять уровнями переключения моделей, что важно при создании, например, мультивибраторов на КМОП микросхемах. Ну и особую группу в примитивах составляют Real Time Primitives. Эти примитивы мы будем применять для создания активных моделей, которые позволяют изменять и контролировать параметры схем в процессе симуляции.

SPICE Model – это тоже модели SPICE, но содержащие текстовое описание на языке SPICE. Эти описания объединены в файлы-библиотеки с расширением .SML (SPICE Model Library) размещенные в папке MODELS программы Протеус. Чуть позже мы рассмотрим возможность применения описаний на языке SPICE, предоставляемых производителями компонентов на своих сайтах, для создания своих функциональных моделей в ISIS.

Schematic Model – схематичные модели, построенные с применением аналоговых и цифровых примитивов. Схема создается на дочернем листе графической модели, затем преобразуется в файл описания модели с расширением .MDF (Model Description File) с помощью встроенного в ISIS компилятора (меню Tools =› Model Compiler…). Далее MDF файл описания используется либо самостоятельно для соответствующей графической модели компонента, либо «родственные» по назначению или производителю файлы объединяются в библиотеки описаний компонентов с расширением .LML, которые также расположены в папке MODELS программы Протеус. Этой группе моделей мы чуть позже уделим особое внимание, поскольку Schematic Model наиболее приемлемы для быстрого создания собственных моделей.

Ну и последняя и самая «продвинутая» группа, «изюминка» Протеуса - это VSM DLL Models – программные модели. Это все модели микроконтроллеров, периферии, сложных индикаторов, датчиков и прочая, прочая, прочая. Все эти модели реализованы программным путем и используют для симуляции динамические библиотеки DLL, скомпилированные при их создании. Именно здесь кроются и их преимущества и недостатки тоже. Любая ошибка программистов, допущенная, при создании модели выливается в многочисленные нарекания пользователей программы. Кроме того, при создании программных моделей как правило допускаются всевозможные упрощения, на некоторые из которых нет указаний в хелпах на эти модели. При использовании программных моделей в своих разработках не следует ожидать стопроцентного соответствия поведения реальному компоненту (микроконтроллеру, индикатору и т.п.). Почему то об этом напрочь забывают конечные пользователи Протеуса. Я по этому поводу привожу все время один и тот же пример с многоразрядными цифровыми индикаторами. Ну не реализованы там аналоговые свойства!!! Так зачем Вам в своих разработках, если они предназначены только для проверки работоспособности цеплять к этим индикаторам всевозможную обвеску: резисторы, силовые ключи и пр. аналоговую мишуру, без которой реальная схема действительно работать не будет, а то и слегка «задымит». Конечно, если Вам предоставлен в аренду компьютер NASA, или даже нашего Российского ЦУП, то может и имеет смысл досконально воспроизводить схему. Но проделывать такое на домашней или офисной персоналке с весьма ограниченными возможностями – это уже из ряда «сексуальных извращений». Проявите творческую смекалку, которой всегда славился русский мужик. Ну и в заключение этого лирического отступления хочу отметить, что ни один симулятор не заменит полностью реальное моделирование устройства, каким бы навороченным он не был. Можно сколько угодно удачно гонять в ралли «Формула-1» на компьютере, но сев за руль реального авто благополучно въехать в ближайший столб. От этого не застрахован никто, недавно испытал на собственной шкуре. Это относится ко всем пакетам сквозного проектирования и даже к такому монстру как OrCAD. У каждой программы есть свои плюсы и минусы. А уж какой и для чего пользоваться – выбирать Вам. Я не собираюсь здесь проводить сравнения и тесты, а перехожу к следующему разделу FAQ По протеусу.
Рисунок 1
Рисунок 2

[Halex07]

3.3. Взаимосвязи симулятора Proteus VSM.
Наш теоретический экскурс продолжается, и для пояснения работы симулятора я не нашел ничего лучшего, как привести картинку из старого описания Proteus VSM SDK с некоторыми моими комментариями (Рис. 3). Связи и направления взаимодействия различных составляющих симулятора показаны стрелками.
Из диаграммы видно, что ISIS непосредственно работает только с графическими моделями, размещенными в проекте и ядром симулятора ProSPICE. Как я уже упоминал выше, ProSPICE оперирует с аналоговыми свойствами моделей через SPICE3F5 и цифровыми через DSIM – цифровой симулятор, который за счет того, что оперирует с меньшим количеством параметров является наиболее быстрым. Обновление активной графики осуществляется по умолчанию с частотой около 20 кадров в секунду. Количество же операций по вычислению электрических параметров может достигать нескольких миллионов и ограничено вычислительной мощью Вашего компьютера. Электрическая модель, в том числе и програмная может иметь и свой графический интерфейс, минующий управление ISIS. Поскольку операции по обслуживанию графики (а проще сказать мультфильма, который вы наблюдаете на экране) и расчета электрических параметров как бы разнесены в два разных интерфейса да еще с разными скоростями, между ними необходимо соблюдать некоторые соотношения, чтобы одно не противоречило другому.
Рисунок 3

[Halex07]

3.4. Параметры анимации.
Возвращаемся к тем опциям меню System, которые я не стал описывать раньше. Итак снова заглянем System =› Set Animations Options… (Рис.4). Ранее мы рассмотрели только назначение галочек в правой части этой панели, теперь пришла пора узнать – что скрывается за числами в левой части окна.
В первом же окне Frames per Second (кадров в секунду) и обнаружились наши 20 кадров. По рекомендации разработчиков это значение оптимально для большинства современных компьютеров, так как обеспечивает наилучшее соотношение между сглаженным воспроизведением графики и нагрузкой на графический процессор компьютера. Но если кому-то «шаловливые ручки» не дают покоя, то может поэкспериментировать с его изменением. Увеличение значения (max=50) увеличивает нагрузку на ЦПУ, уменьшение – уменьшает и замедляет анимацию.
Заранее хочу предупредить, и это будет подтверждено приложенным примером, что все изменения в Animated Circuits Configuration относятся только к открытому в данный момент проекту и сохраняются вместе с ним. Т.е. максимум, что вы сможете «испортить» это текущий проект и то при условии, что нажмете кнопку Save «Сохранить».
Куда больший интерес представляют Timestep Per Frame (временной интервал на кадр анимации) и Step Animation Rate (частота кадров анимации в сек). По умолчанию они установлены соответственно 50m (миллисекунд) и 4 (кадра в сек). Первый параметр определяет временной интервал, на который продвинется симуляция за один кадр, а второй – количество таких кадров в секунду. Здесь я должен сделать еще одно, ну очень лирическое отступление от темы, связанное с лингвистикой. Дело в том, что для аглицкого слова Frame (кадр, фрагмент, фрэйм…), я дважды использовал перевод «кадр», но именно в этом окне Протеуса все так замешано, что у нормально владеющего русским языком человека можно «сдвинуть крышу». Так вот эти два параметра больше связаны именно с симулятором ProSPICE и как бы взаимообратны. Чем меньше значение Timestep Per Frame тем медленнее обновляется анимированная картинка, но зато можно разглядеть подробности быстропротекающих процессов. Те вычисления, которые ProSPICE не успел закончить к моменту окончания Timestep урезаются и не входят в данный кадр. Максимальное Step Animation Rate – количество этих таймстепов в секунду, которое позволяет установить Протеус равно 10. Еще одно немаловажная деталь – при уменьшении параметра Timestep Per Frame, его можно уменьшить даже до единиц и десятков микросекунд, (но при этом сильно замедлится симуляция) - то, что уменьшается нагрузка на ЦПУ компьютера. А теперь вспомните опять это противное сообщение в логе:
Simulation is not running in real time due to excessive CPU load
Если начать нахально на порядок увеличивать Timestep Per Frame даже на процессе, протекающем нормально вы рискуете получить этот «горчичник». Для иллюстрации вышесказанного прилагается пример Dinamic_point, содержащий три варианта дизайна: Slow (медленный), Standard (по умолчанию) и Fast (быстрый) с разными настройками Timestep Per Frame. По пожеланиям некоторых пользователей я в данном случае использовал AVR, хотя не уверен что это корректно с моей стороны. Дело в том, что пример в версии 7.6, но я как обычно сделал файлы секций .SEC для импорта в старые версии. Но ведь использован процессор Mega8515 и в очень старых версиях он просто отсутствует. Вот и дилемма с приведением примеров на AVR – или использовать старую 90-ю серию, или лишить пользователей ранних версий возможности посмотреть примеры.
Обратите также внимание на параметр Single Step Time – именно он связан с кнопкой Step пошаговой анимации внизу слева в основном окне ISIS. Вот именно с такими шагами симуляция будет продвигаться при каждом нажатии кнопки, а не по шагам микропрограммы контроллера, если таковой присутствует в схеме – для этого существует другая кнопка и в другом месте. Если Вам необходимо подробнее рассмотреть что то, то уменьшите это время. Для примера в Slow.DSN это время установлено 10mS.
Рисунок 4

[Halex07]

3.5. Параметры симуляции.
Перейдем к разбору параметров окна System =› Set Simulation Options…Кстати, туда можно попасть и сразу из окна Animated Circuit Configuration (Рис.4), нажав кнопку SPICE Options. Это окно предназначено для настройки параметров симулятора ProSPICE. Окно содержит пять вкладок: Tolerances (допуски по точности), MOSFET (параметры МОП транзисторов), Iteration (количество шагов в вычислениях), Temperature (температурные параметры), Transient (параметры переходных процессов), DSIM (параметры симуляции цифровых цепей).
Здесь остановимся на тех значениях, на которых акцентировали внимание разработчики Лабцентра в стандартном HELP по ProSPICE в разделе ADVANCED TOPICS =› SIMULATOR CONTROL PROPERTIES. Для остальных я просто приведу расшифровку назначения. Если кому то этого покажется мало, то рекомендую найти любую книжку по любому из пакетов программ: Electronic Workbench, Multisim, Microcap, OrCAD ну или наконец по самому PSpice. Дело в том, что параметры SPICE симуляции для всех этих программ обозначаются практически одинаково. В конце этого параграфа я размещу список книг в которых они описаны точно.
• Вкладка Tolerances (Рис.5). На этой вкладке представлены параметры, определяющие с какой точностью ProSPICE производит вычисление решений. При очень высокой точности может потребоваться больше времени для моделирования и в ряде случаев решение может не иметь сходимости вообще.
ABSTOL – абсолютная ошибка расчета токов;
VNTOL – допустимая ошибка расчета напряжений;
CHGTOL – допустимая ошибка расчета зарядов;
RELTOL – допустимая относительная ошибка расчета напряжений и токов;
PIVTOL и PIVREL – абсолютная и относительная величины элемента строки матрицы узловых проводимостей;
GMIN – минимальная проводимость ветви цепи – определяет утечки обратно смещенных полупроводниковых переходов и других точек схемы с высоким импедансом. В ряде случаев уменьшение этого значения может помочь получить сходимость для схем, которые при стандартных параметрах по умолчанию не имеют решений, однако при этом понизится точность вычислений. Проводимость меньше установленного здесь значения принимается равной нулю;
TRANGMIN – минимальная переходная проводимость;
RSHUNT – допустимое сопротивление утечки для всех узлов относительно общей шины.
• Вкладка MOSFET (Рис.6). На этой вкладке сосредоточен ряд параметров, определяющих в SPICE геометрические размеры MOSFET элементов при условии, что они расположены на подложке интегральной микросхемы. Именно поэтому здесь даны значения в метрах. Здесь наиболее значимо то, что установкой галочек можно задавать значения для старых версий моделей SPICE или для новых SPICE2.
DEFAD – площадь диффузионной области стока, м2;
DEFAS – площадь диффузионной области истока, м2;
DEFL – длина канала полевого транзистора, м;
DEFW – ширина канала, м.
• Вкладка Iteration (Рис. 7).
Integration Method – определяет каким методом SPICE вычисляет точки сходимости решений. Возможны два варианта: GEAR – метод Гира или TRAPEZOIDAL – метод трапеций. Первый считается более новым и точным и применен по умолчанию, хотя и требует больше машинного времени. Здесь замечу, что в столь популярном сейчас по соседству Multisim 10 по умолчанию используется метод трапеций. Три последующие опции определяют количество шагов, которые SPICE применяет для вычисления каждой операционной точки.
MAXORD – максимальный порядок (от 2 до 6) метода интегрирования дифференциального уравнения;
SRCSTEPS – размер приращения напряжения питания в процентах от его номинального значения при вариации напряжения питания (используется при слабой сходимости итерационного процесса);
GMINSTEPS – размер приращения проводимости в процентах от GMIN (используется при слабой сходимости итерационного процесса);
ITL1, ITL2 и ITL4 – максимальное количество итераций (шагов) соответственно в режиме DC, передаточных функций при переходе к следующей точке в режиме DC, при переходе к следующему моменту времени в режиме Transient;
Ну и наконец три флажка установка которых может в ряде случаев ускорить процесс вычислений:
NOOPITER – перейти непосредственно к вычислению GMIN;
COMPACT – сжатие вычислений LTRA. Применим только для линий с потерями LOSSYLINE и заключается в том, что похожие по значениям точки не просчитываются, а принимаются идентичными, что позволяет сократить время вычислений.
BYPASS – включен по умолчанию и позволяет обойти при вычислениях неизменяемые элементы.
• Вкладка Temperature (Рис. 8 ). Здесь всего два параметра:
TEMP - глобальная температура компонентов, применяемая ко всем элементам моделируемой схемы, которые имеют ее в своих параметрах, а это: резисторы, диоды, полевые и биполярные транзисторы. Будьте внимательны: параметр учитывается только для аналоговых компонентов. Если перевести те же резисторы и диоды в режим DIGITAL, он не просчитывается! Кроме того, для каждого из этих компонентов можно установить параметр TEMP индивидуально в его свойствах.
TNOM – номинальная температура, при которой проводились измерения термозависимых параметров модели (во загогулина, понимаишь!), ну или проще стандартная при которой как бы снимались параметры. Этот параметр также можно устанавливать индивидуально.
Ну и у Р. Хайнемана отмечается, что поскольку по умолчанию обе температуры равны +27 градусов по Цельсию легко догадаться, что SPICE «родился» в штате Калифорния, а не в Сибири (это так, к слову - для расширения кругозора).
• Вкладка Transient (Рис. 9).
NUMSTEPS – количество шагов, применяемое при анализе переходных процессов
TRTOL – допуск на погрешность вычисления переменной – наиболее полезный на этой вкладке параметр. Если результаты моделирования имеют остроконечные всплески или наблюдается перерегулирование, то можно попробовать уменьшить этот параметр.
TTOL – временной разброс при анализе смешанных (аналого-цифровых) схем;
TMIN – минимальный шаг по времени при анализе аналоговых схем.
• Вкладка DSIM (Рис. 10). В седьмых версиях имеет всего два изменяемых параметра.
Random Inicialisation Values (случайные значения при инициализации) определяет каким образом устанавливаются значения для цифровых примитивов, которым в свойствах прописано значение, а это в частности модели микросхем памяти, установка для которых INIT=RANDOM заполняет их при старте в зависимости от установленного здесь переключателя либо Fully Random (случайными), либо Pseudo-random (псевдослучайными) последовательностями из заданного диапазона от 1 до 32767. Если вы используете для микросхемы памяти загружаемый файл, но он заполняет ячейки не полностью, то при установленном INIT=RANDOM последовательностями заполнятся оставшиеся свободными ячейки.
Propagation Delay Scaling (масштабирование задержек распространения) определяет установки для всех временных свойств цифрового моделирования, которые не заданы строго в свойствах конкретных моделей. По умолчанию для этих свойств установлен множитель Scale all values by constant равный 1. Установка Pseudo-random или Fully Random позволяет задать диапазон от нижнего Lower Scalling Limit до верхнего Upper Scalling Limit значения, в котором будет изменяться этот множитель по псевдослучайной в том же числовом диапазоне что и выше или полностью случайной последовательности. Это позволяет приблизить моделирование к реальности и исключить проектные недоработки, связанные с повторяющимися временными процессами не имеющими места в реальных условиях.
Ну, вот мы и прошлись по всем вкладкам параметров симуляции, и остался незатронутым один пункт, повторяющийся на всех вкладках. В последних версиях Протеуса внизу этого окна для удобства пользователей введен выбор трех предустановленных наборов параметров. По умолчанию всегда стоит Default Setting (Рис. 5). В большинстве случаев для моделирования этого более чем достаточно, однако иногда имеет смысл изменить предустановки. В наличии имеются еще две:
Setting for Better Accuracy (установки для наилучшей точности) – но при этом увеличивается время вычислений и нагрузка на ЦП компьютера;
Setting for Better Convergence (установки для наилучшей сходимости решений) – здесь соответственно все наоборот.
Для того, чтобы загрузить установки необходимо выполнить действия в последовательности по Рис. 5. Обращаю ваше внимание, на то, что загрузка (Load) действует сразу на все вкладки, относящиеся к аналоговой симуляции. Естественно температура и DSIM при этом не модифицируются. Для возврата к «заводским» установкам от Лабцентра снова загружаем Default. Ну и еще – эти настройки сохраняются в ISIS, а не в проекте! Поэтому, уйдя из дефолтовых настроек, при последующем закрытии/открытии ISIS не забудьте проверить – что Вы там назначили и не пора ли возвратить Default на место.
Ну и в заключении этого параграфа как и обещал – список литературы с моими пояснениями. Ссылок не даю, поскольку на файлообменниках они часто меняются, но в сети эти книжки «гуляют».
Разевиг В.Д. «Схемотехническое моделирование с помощью программы Micro-Cap» 2003 г.
К сожалению, безвременно ушедший Всеволод Данилович больше не порадует нас своими шедеврами. Если я когда-нибудь и напишу что-либо подобное, то буду считать, что жизнь прожита не зря. В любой его книге по косточкам разобран описываемый предмет. Например из этой я частично «списал» описания параметров симуляции SPICE (стр. 62-65).
Короновский А.А., Храмов А.Е. «Применение Electronics Workbench для моделирования электронных схем» Учебно–методическое пособие. Саратовский Госуниверситет, 2004.
Как видите, даже старенький Electronics Workbench перекликается с Протеусом, а все благодаря SPICE. На стр. 17-18 те же описания параметров Spice, как впрочим и Multisim:
Хернитер М. «Multisim 7 Современная система компьютерного моделирования и анализа схем электронных устройств». 2006 г.
Хайнеман. Р. PSPICE «Моделирование работы электронных схем». 2005 г.
Петраков О М. Создание аналоговых PSPICE моделей радиоэлементов. 2004 г.
Последней книги нет в сети, я пользуюсь бумажным вариантом. Но аналогичный по названию цикл статей выходил в журналах «Схемотехника» в 2002 г. В них же в районе 2005 г. был и цикл по цифровым моделям. Для тех, кто решил попробовать самостоятельно создавать SPICE модели последняя книга и статьи будут наилучшим подспорьем в работе.
Рис. 5, 6, 7, 8, 9, 10

[Halex07]

4. Создание моделей компонентов в ISIS.
Чтобы больше не грузить Вас голой теорией, мы на время отложим теоретические основы в сторону, поскольку они так или иначе всплывут в этом разделе и будут рассмотрены, как говорится: «по ходу пьесы». Займемся более насущными проблемами, тем более, что форум уже перегружен вопросами по теме создания моделей.

4.1. Создание графических моделей компонентов.
Итак в разделе 3.2 мы кратко классифицировали типы моделей. Для начала создадим No Simulation Model. Почему именно ее, а не сразу микропроцессор Intel Core Duo? Да потому что любая модель компонента в ISIS должна иметь как минимум хоть одно графическое отображение, а иначе как ее разместить в проекте? Ну и потом любая, даже не симулируемая в ISIS модель при ее создании проходит все этапы, присущие даже самой сложной модели микроконтроллера и нам необходимо с ними познакомиться. Для начала необходимо создать графическое изображение модели с набором выводов (ножек, пинов – называйте, кто как хочет). Открывем новый проект и начинаем рисовать. В первую очередь необходимо нарисовать тело компонента. Рисование осуществляется с помощью элементов 2D графики. На рисунке показано какие фигуры из какого режима создаются (Рис.11). Обратите внимание, что я использовал режим рисования COMPONENT – чтобы не нарушать общий стиль графики компонентов в ISIS, но при желании можно воспользоваться любым другим из предустановленных или создать свой. Напомню, что стили графики представлены в меню Template =› Set Graphic Styles… Если надо создать свой жмем кнопку New и задаем название и параметры линий, цвета и т.п. (Рис. 12).
СОВЕТ 1. Если необходим стандартный графический элемент, то зачастую нет необходимости создавать его с нуля. Например, тот же символ операционного усилителя можно взять из библиотеки символов. Процедура напоминает добавление компонентов, но в другом режиме. Выбираем в левом меню режим S и далее по пунктам практически, как и с компонентами (Рис. 13). Замечу только, что пока Вы не начали активно создавать собственные компоненты, пользовательская библиотека USERSYM пуста, и выбрать стандарные символы вы можете только из библиотеки SYSTEM. Поместив его в селектор символов на шаге 5 всегда можно добавить его в поле проекта оттуда как и обычный компонент.
СОВЕТ 2. Если в библиотеке компонентов уже имеется готовый, похожий на тот, что Вам необходим то воспользуйтесь функцией Decompose (пиктограмма с молотком в верхнем меню или через меню по правой кнопке мыши), чтобы «разобрать его на запчасти» и использовать необходимые графические элементы для своего компонента. Не бойтесь испортить существующие библиотеки. Если Вы не применяли «превентивных» мер к своей копии программы, то они по умолчанию защищены от записи. К тому же, «разобранный» компонент уже не является компонентом библиотеки, а представляет собой чистейший набор графики и текстовый скрипт с описанием его свойств. Для примера я «разобрал» ОУ 741 (Рис. 14).
Внутри тела компонента вы вольны помещать любые элементы графики – линии, текст. Так например у того же ОУ 741 линиями начерчены символы прямого и инверсного входов. Здесь только одно примечание – не забывайте, что для того чтобы они были видимыми – само тело должно быть помещено на задний план (меню Edit =› Send To Back или через Ctrl+B). Соответственно при размещении линий и текста желательно в селекторе выбирать стиль COMPONENT, чтобы все выглядело единообразно. Ну уж если кому то нравится разрисовывать свои творения всеми цветами радуги, то и это не воспрещается.
Итак, после того как тело компонента со всеми прибамбасами нарисовано необходимо установить маркер выравнивания ORIGIN. По этому маркеру наш будующий компонент будет привязываться к сетке в проекте. На рисунке 14 он установлен в центре тела, хотя раньше разработчики программы рекомендовали ставить его по концу левого верхнего вывода, а для активных компонентов (например индикаторов) левый верхний угол тела – потому что отсчет положения изменяющихся в процессе симуляции элементов (тех же светящихся сегментов индикатора будет вестись по нему). Но для обычных компонентов – микросхем и т.п. положение не так существенно, так что можно лепить куда хотите, но помните о привязке к сетке. Для установки маркера можно воспользоваться левым меню («прицел» ниже S, либо через всплывающие меню правой кнопки мыши PLACE =› MARKER =› ORIGIN.
Ну и последним этапом создания графического изображения является размещение выводов компонента. Переходим в левое меню Device Pins Mode и выбираем в селекторе нужный нам тип вывода для размещения. Как правило, в большинстве случаев достаточно DEFAULT – т.е. простого прямого вывода, ну может еще INVERT – вывод с кружком. Замечу, что графическое изображение и назначение вывода в данном случае еще никак не связаны. И даже если вы воткнете на будущий вывод питания символ вывода INVERT – это не значит, что оно у вас изменит полярность, ну или что-то еще в том же духе. Пока речь идет ТОЛЬКО о графическом изображении. Если кому то покажется мало имеющихся в селекторе по умолчанию шести типов выводов, может добавить туда из имеющейся библиотеки SYSTEM. Процедура все та же. Находясь в режиме Device Pins Mode, двойным щелчком в поле селектора (или одинарным по буковке P) входим в библиотеку и добавляем из имеющихся двух десятков в селектор тот, который понравился. Когда он Вам там надоест щелкаем правой кнопкой по нему и задаем Delete. При этом элемент будет убран из селектора, а не из библиотеки!!! Впоследствии вы снова можете его достать.
При размещении выводов обратите внимание на тонкое перекрестие в виде Х – это внешний конец вывода, к которому будут позиционироваться провода, поэтому он должен быть направлен наружу. Если необходимо повернуть или отразить вывод воспользуйтесь соответствующими опциями в меню правой кнопки мыши. Когда выводы расставлены по местам, можно приступить к их нумерации и описанию назначения. Для нумерации при большом количестве выводов проще всего воспользоваться функцией меню Property Assignment Tools. В строке Sting задаем PIN=NUM# и задаем начальное Count равным 1. Об этом режиме я уже рассказывал. Вот с наименованием, несколько сложнее, поскольку выводы, как правило имеют уникальные имена. Хотя, для всевозможных многоразрядных портов и тут можно применить NAME=(что-то там)#. При небольшом количестве пинов их проще отредактировать вручную. Двойным щелчком по выводу входим в его свойства и задаем в соответствии с рисунком 15.
Здесь пожалуй остановимся чуть подробнее. В окне Pin Name вводится наименование вывода. Желательно, чтобы оно отражало физическую суть вывода, но в тоже время было не очень длинным и обязательно уникальным (не повторяющимся больше в этой модели). Если планируется, что это имя будет видимым, то оно должно вписываться в отведенном для этого месте и не наползать на другие. Ну про Default Pin Number и так ясно, что необходимо, чтоб он совпадал с номером вывода того корпуса, который будет впоследствии принят по умолчанию. Забегая вперед, замечу, что для одного компонента может быть назначено несколько корпусов.
Особо хочу остановиться на группе флажков, которые я обозначил как Видимость:
Draw Body? – вот она та пресловутая видимость вывода, которая позволяет присоединять к нему проводники. Она нам очень потребуется в дальнейшем, чтобы суметь подключиться к выводам компонентов скрытым по умолчанию, т.е. у которых отсутствует галочка в этом поле. Мы можем их увидеть в сером цвете, установив через меню Template =› Set Design Default галочку Show Hidden Pins, но по настоящему активными, т.е. доступными для использования они станут, когда в этом месте для них будет стоять галочка. Соответственно галки Draw Name? и Draw Number? Делают видимыми имя и номер вывода, а Rotate… поворачивают их на 90 градусов против часовой стрелки. Ниже расположено окно выбора электрического типа вывода. На рисунке у меня открыт вывод плюса питания ОУ, поэтому ему строго назначен тип PP – Power Pin. Если при создании компонента вы затрудняетесь в определении электрического типа, то просто оставьте PS – принятое по умолчанию. Поясню маленький нюанс: Для ISIS здешнее назначение в высшей степени безразлично, а вот ARES при разводке дорожек примет данное назначение, как руководство к действию и в зависимости от этого произведет трассировку, например для Power Pin более широкими дорожками. Ну и внизу данного окна имеются кнопки позволяющие ускорить редактирование Previous и Next – переключают окно на следующий по номеру Pin Number вывод, ОК и Cancel – стандартные подтверждение и отмена
На рисунке 16 приведен вид селектора в режиме расстановки выводов, а также графическая модель ОУ 741 перерисованая в формат принятый в Российской технической документации. Я здесь просто разобрал стандартный 741, нарисовал свое Body, перетащил выводы с разобранного к новому, для выводов питания включил галку Show Name, а графику вывода 2 заменил на INVERT. Во вложении проект в котором проделана эта работа, но еще не создана новая модель.
Рисунок 11, 12, 13.
Рисунок 14, 15, 16.

[Halex07]

4.2. Пять этапов или пять составляющих окон создания модели функции Make Device.
Как и у В.И. Ленина «Три источника и три составляющие части марксизма», так и любая модель ISIS имеет правда не три, а пять составляющих этапов при создании. Мы очень часто будем проходить через них, поэтому настала пора знакомиться. Итак, я закончил тем, что нарисовал (именно нарисовал) графическую модель операционного усилителя в проекте, но если я даже захочу использовать ее для простой прорисовки схемы, то не смогу, она все еще состоит из отдельных элементов. Для того, чтобы поиметь хоть какую-то пользу мне необходимо скомпоновать ее в единое целое и поместить в библиотеку, чтобы в нужный момент доставать оттуда. Чтобы создать модель служит функция Make Device в верхнем меню или в контекстном правой кнопкой мыши. Но прежде чем давить на нее необходимо выделить те графические компоненты, из которых будет создаваться модель. При выделении будьте внимательны: охвачено должно быть все, в том числе и маркер ORIGIN. В режиме Selection mode обводим удерживая левую лапку мыши всю графику с небольшим запасом. Выделенные элементы примут красный цвет (Рис. 17). Далее щелкаем по правой кнопке мышки и выбираем опцию Make Device.
После чего открывается первое из окон создания модели Device Property (Свойства устройства, ну в данном случае правильнее перевести компонента) (Рис. 18 ) В этом окне обязательными для заполнения являются две строки – Device Name (наименование компонента) и Reference Prefix (Префикс под которым устройство будет заносится в список цепей). Я тут слегка погорячился ранее, заявив, что оригинальные библиотеки Протеуса защищены от записи, не учел «родной специфики», где используются взломанные программы. Поэтому, чтобы не испортить оригинал давайте назовем наш девайс не просто 741, а 741R, по аналогии с ГОСТами России. Ну и префикс ему прилепим не стандартный для ISIS – U, а тоже в соответствии с нашими стандартами – DA. После чего считаем первое окно заполненным и переходим ко второму, нажав кнопку Next.
Второе окно Packaging (Рис. 19 ) содержит информацию о назначенных нашему устройству корпусах. Конечно, можно бы назначить корпус и сейчас, но это никогда не поздно сделать, тем более что на этом примере я хочу показать назначение нестандартного корпуса и оставлю на потом. А пока идем в следующее окно.
Окно Component Properties & Definition (Рис. 20) скоро станет для нас одним из самых популярных, потому что именно в нем мы будем назначать характерные для того или иного компонента свойства, но на данном этапе оставим его пустым и перейдем к следующему.
Четвертое окно Device Data Sheet & Help File (Рис. 21) пожалуй самое бесполезное для нас на ближайшее время, если конечно кто-то не собрался создавать модели на коммерческой основе с последующим распространением в качестве стандартных.
Ну и наконец мы перешли к финальному окну создания модели, которое потребует от нас тоже некоторых завершающих «телодвижений». Во-первых в строке Device Category через раскрывающееся меню я выбрал для устройства категорию Operational Amplifiers (операционные усилители). Чуть ниже аналогичным способом Суб-категорию Single (одиночный). Ну и в качестве Device Manufacturer (производитель), воспользовавшись кнопкой New ввел нового производителя: ExUSSR, хотя и покривил душой (что-то не помню, чтоб в СССР производились именно 741, а не их «содранные» аналоги). Все эти сведения нужны Протеусу для того, чтобы поместить наш созданный девайс в определенный раздел библиотеки для быстрого поиска его в дальнейшем. Обращаю Ваше внимание, что все вновь созданные компоненты по умолчанию Протеус будет помещать в библиотеку USERDVC и впоследствии мы его там найдем и удалим, как лишний и бесполезный мусор.
Ну вот собственно и вся процедура создания модели для данного этапа. После нажатия кнопки ОК на последней пятой вкладке мы помещаем наше творение в библиотеки ISIS.
Рисунки 17, 18, 19.
Рисунки 20, 21, 22.

[Halex07]

4.3. Управление библиотеками Протеуса, или из простых «читателей» в «библиотекари».
Прошу обратить особое внимание! Не зря я назвал этот раздел FAQ для «продвинутых». Со следующей информацией в этом параграфе надо обрашаться осторожно, чтобы потом не клясть себя за кривые руки, а меня за то, что не предупреждал. Если вы повредите «родные» библиотеки программы, потом придется ее переустанавливать.
Итак, мы создали модель 741R, пусть пока и бесполезную в работе, но необходимую, чтобы понять изложенный ниже материал. Если теперь войти в библиотеку компонентов и в окне поиска по ключевому слову набрать 741R – то вот нам и наша модель (Рис. 23).
Как видим, мы получили то, что хотели – не симулируемую модель, для которой отсутствует корпус, и находится эта модель в библиотеке USRDVC, куда Протеус по умолчанию помещает все пользовательские модели. Теперь мы можем использовать ее в своих проектах в новом начертании, но работать она в симуляторе не будет и при попытке запустить симуляцию с ее участием, мы получим в логе сообщение об ошибке:
No model specified for DA1
Simulation FAILED due to partition analysis error(s)
Так что единственная польза от нашей модели в том, что можно использовать ее для рисования принципиальных схем. Давайте рассмотрим теперь какие физические изменения внес Протеус при создании нашей модели, а для этого воспользуемся менеджером библиотек. Заходим в меню Library и выбираем Library Manager…
При первом открытии появится предупреждение ISIS о том, как размеры окна менеджера библиотек могут быть изменены и сохранены. Если кого-нибудь раздражают лишние советы – сразу поставьте галку Don’t display this massage again. Для тех, кто не дружит с английским поясню, что окно менеджера не содержит привычных кнопок развернуть/свернуть в верхнем правом углу. Поэтому, для изменения размеров необходимо растягивать его мышью за края. Чтобы сохранить измененные размеры надо, щелкнув правой кнопкой мыши в верхней полосе окна (в той, где находится заголовок) выбрать опцию Save Window Size. Итак, подтвердив кнопкой ОК, что мы ознакомились с сообщением попадаем в окно менеджера (Рис. 24).
В левом окне менеджера по умолчанию открывается первая по алфавиту (а в данном случае начинающаяся с цифры) библиотека 74ALS, а в правом наша библиотека USRDVC с сиротливо расположившимся в нем 741R. Между двумя окнами расположены кнопки редактирования выбранных библиотек с большим черным треугольником-стрелкой показывающей направление проводимых операций. Дополнительно Source (источник) и Dest’n (приемник) обозначены над окнами. Обратите внимание, что оригинальная 74ALS обозначена как Read Only – только для чтения, о чем я и говорил раньше. Кроме того, внизу соответствующих окон отображается информация о количестве компонентов в библиотеке и наличии свободного места в ней. Например, в пользовательской USRDVC пока наш единственный ОУ и 999 свободных мест. Если выбрать элемент кликнуть мышкой по элементу в левой или правой библиотеке, то в зависимости от того, где вы щелкнули мышкой – направление и соответственно Source/Dest’n меняются местами. За этим тоже надо следить. Теперь познакомимся с назначением кнопок. Кнопки редактирования между панелями:
• Order – порядок развертывания раскрывающегося списка библиотек при клике по треугольничку с направлением вниз. По умолчанию принят алфавитный от 0 до 9 и от A до Z. Нажатие этой кнопки вызывает окно, позволяющее изменить порядок перемещать одну выбранную библиотеку в списке, либо после нажатия All изменить порядок на обратный – Reverce или отсортировать по алфавиту – Sort.
• Select All и Unselect All – позволяют соответственно выделить или снять выделение со всех элементов в окне выбранной библиотеки.
• Copy Items, Move Items – соответственно копируют, перемещают выделенные элементы в направлении стрелки (из Source в Dest’n).
• Delete Items – удаляет выделенные элементы. Будьте осторожны с этой опцией!!! Обратный процесс невозможен.
• Rename Item – переименовывает выделенный элемент.
• Information – очень полезная кнопка, выводит информацию о выбранном элементе. Для примера на Рис. 25 показано выведенное окно для родного, Протеусного ОУ 741.
Теперь перейдем к рассмотрению кнопок управления библиотеками в нижней части:
• Dump Library – позволяет скопировать в буфер обмена или сохранить в текстовый файл информацию о выделенных элементах библиотеки. Если хотите сохранить информацию о всех элементах предварительно воспользуйтесь кнопкой Select All.
• Delete Library – удаляет выбранную библиотеку полностью. Также будьте внимательны с этой кнопкой, хотя в данном случае перед удалением Протеус вас предупредит, и вы можете отказаться от удаления.
• ADI Library, Pack Library, Backup Library – первая предлагает добавить информацию из файла .ADI, вторая создает для выбранной библиотеки файл .TMP, а третья - .BAK. Откровенно замечу, я и сам не знаю, для чего они нужны. Могу только предположить, что для «унутреннего потребления» сотрудниками Лабцентра, т.к. утилит, которые потом откроют эти файлы я не знаю.
• File Atribute – устанавливает или снимает при повторном применении атрибут Read Only (только для чтения) для выбранной библиотеки.
• Create Library – ну вот и та опция, позволяющая создать собственную библиотеку, из-за которой и вклинен весь этот материал. После нажатия на эту кнопку открывается папка Library с предложением задать имя новой библиотеки. Зададим, например, произвольное имя My_Lib, после нажатия сохранить Протеус предложит еще одно окно с предложением задать количество элементов в этой библиотеке – по умолчанию 100, но вы можете изменить его по своему «вкусу». И уже после окончательного подтверждения будет создана новая библиотека.
Но естественный вопрос – а для чего она нужна? Ведь есть же для сохранения USRDVC. Да, есть и у каждого пользователя Протеуса. Создав свою библиотеку с оригинальным именем, вы получаете возможность сохранять вновь создаваемые элементы в ней (Рис.26), ну или копировать/перемещать в нее элементы из USRDVC. Это позволяет передавать и переносить файлы библиотек на другой компьютер не боясь при этом затереть файлы USRDVC на нем. Ведь у другого пользователя там могут храниться свои элементы. Физически это выглядит так:
При создании библиотеки My_Lib в папке Library Протеуса создаются два файла: My_Lib.LIB – непосредственно библиотека и индексный файл My_Lib.IDX. Вот они и подлежат переносу в соответствующую папку другой копии Протеуса. Кроме того, чуть позже при создании моделей мы будем создавать и файлы в папке MODELS, содержащие их описания для симулятора. Они также копируются в соответствующую папку другого компьютера для переноса моделей. Вот так возможна передача разработанных моделей другому пользователю.
Ну и в заключении данного материала хочу предостеречь наиболее рьяных пользователей от чрезмерной эйфории. Казалось бы ну вот, теперь возьмем и начнем таскать библиотеки из копии в копию программы. Да, но только собственноручно созданные, а не «родные» Протеуса. Не забудьте, что большинство оригинальных библиотек программы обладают глубоко эшелонированной защитой. И простым копированием тут не обойдешься. Хотя с некоторыми моделями этот вариант и проходит. Так, автору этих строк в недалеком прошлом удалось перенести модель часиков DS1307 из демо-версии 7.3 в более раннюю, где она безнадежно глючила и тем самым благополучно закончить отладку незавершенного проекта. Но это частный случай, так что эксперименты – на свой страх и риск. И не забывайте делать резервные копии, а то…
PS Чуть не забыл... Все, что здесь изложено касательно компонентов применимо и к библиотекам символов. Для то чтобы попасть в другие библиотеки надо вызвать менеджер библиотек находясь в режимах 2D Graphic Simbol Mode(в левом меню), Terminals Mode или Device Pins Mode.
Рисунки 23, 24, 25, 26.

[Halex07]

4.4. Netlist Compiler – список цепей. Основа для ARES и других приложений.
Настала пора рассмотреть – каким образом ISIS хранит информацию о нарисованной схеме и передает ее в ARES или другие сторонние приложения. Если кто-то считает, что в графическом – так как нарисовано, то глубоко заблуждается. Как и все другие CAD-ы Протеус для обмена информацией о схеме создает текстовый список цепей. К сожалению, единого общепризнанного стандарта на такие списки не существует (у P-CAD свой, OrCAD - тоже, даже у столь популярного Eagle свой формат), и поэтому специалисты Лабцентра разработали свой собственный. Информация о разработанной схеме помещается в файл с расширением .SDF – Schematic Description Format (формат описания схемы) c помощью встроенного в ISIS компилятора цепей, ну или соединений в другой транскрипции перевода. Формат достаточно компактный и после небольшого навыка легко «расшифровываемый», что весьма пригодится нам в дальнейшем. Для начала «соберем» небольшую схемку (я использовал типичный мультивибратор на таймере 555 Рис. 27).
Все примеры будут во вложении к данной теме – это пример Ex1. Размещенный по умолчанию терминал питания принимает значение +5V по отношению к земле. Все элементы схемы, которые я применил здесь имеют PCB (т.е. корпуса) за исключением светодиода. Для того чтобы назначить корпус ему воспользуемся следующим способом.
Двойным кликом по светодиоду или через правую кнопку мыши (Edit Properties) входим в окно Edit Component. В строке PCB Package (шестая сверху для «любителей» русифицированных версий) пока у нас стоит значение (Not Specified) т.е. не назначено. Справа от этой строчки щелкаем по маленькой кнопке со знаком вопроса и попадаем в библиотеку корпусов ARES (Рис. 28 ). Там мы ведем себя абсолютно так же, как и в библиотеках ISIS – вводим ключевое слово LED для поиска. Подходящий корпус только один – его и назначаем нашему светодиоду. Обратите внимание, что данное назначение действует только в пределах данного проекта. Если вы начнете новый проект в ISIS и добавите тот же LED-YELLOW из библиотеки, он опять будет иметь значение (Not Specified).
Я старался использовать все элементы с PCB, поскольку в этом и следующем параграфах нам так или иначе придется пересечься с разводкой платы в ARES для понимания материала. Итак, все компоненты у нас с PCB, хотя для списка цепей это и не требуется, давайте скомпилируем его. В верхнем меню выбираем Tools =› Netlist Compiler и попадаем в окно выбора опций компиляции (Рис. 29 ).
Пока оставляем все переключатели в нем как есть, чтобы сформировался стандартный SDF Протеуса нажимаем OK, после чего открывается окно просмотра скомпилированного SDF файла (Рис. 30). Из этого окна мы можем скопировать текст в буфер обмена - кнопка Clipboard, сохранить в стандартный ASCII текстовый файл – кнопка Save As, либо просто наплевать на все и закрыть окно Close. Вот именно такой файл каждый раз формируется автоматически, когда мы передаем информацию о «нарисованной» нами схеме в ARES для создания печатной платы.
Рассмотрим структуру этого файла. Я приведу его полностью, а не так, как на рисунке ниже. В начале файла следует чисто описательная информация, заканчивающаяся датой создания Created и датой последней модификации Modified. Все, что выше берется из окна, вызываемого через меню [B]Design =› Edit Design Properties[/B], если вы его конечно заполнили, как например я в данном случае. Иначе здесь кроме дат, вставляемых автоматом, информации не будет. Далее следует несколько разделов, начинающихся со знака звездочки - *. Разделы *PROPERTIES (свойства) и *MODELDEFS (назначения для моделей) пока пусты. Они получают информацию из одноименных текстовых скриптов, размещенных в проекте. Позже, при создании MDF-моделей мы познакомимся с ними поближе.
*PARTLIST – список составляющих. В этом списке перечислены все компоненты, входящие в нашу схему с указанием их свойств. Каждая строка начинается с позиционного обозначения компонента, далее через запятые следует информация об его номиналах, корпусе, применяемой модели и т.п. Думаю, что не обязательно быть сотрудником спецслужб, чтобы без особого труда «расшифровать» эту информацию. Достаточно заглянуть в свойства любого из этих компонентов, чтобы обнаружить ее там.
*NETLIST,7 – ну вот это и есть собственно список цепей или соединений. В данном случае цифра 7 после запятой указывает на количество узлов (цепей) в списке.Каждая цепь начинается со знака решетки - #. Далее следует номер узла этой цепи в списке и количество подходящих к узлу проводов (подключенных выводов элементов). Ну и далее сам список подключенных выводов. Давайте для примера разберем первую цепь #00001,3. Число 3 указывает, что к узлу подключены три вывода компонентов, которые перечислены ниже. Это:
U2,IP,7 – расшифровывается как – микросхема U2 – таймер555, вывод микросхемы номер 7, тип вывода IP (Input – про типы мы уже проходили при создании графической модели);
R2,PS,1 – R2 –резистор, вывод 1 (в данном случае у модели резистора выводы обозначены просто как 1 и 2, впрочем как и у большинства моделей двухвыводных компонентов: резисторов, кондесаторов, катушек и т.п.), тип вывода PS (пассивный).

ISIS SCHEMATIC DESCRIPTION FORMAT 6.1
=====================================
Design:   Ex1 учебный проект
Doc. no.: №1
Revision: первая
Author:   Halex
Created:  13/12/09
Modified: 13/12/09

*PROPERTIES,0    

*MODELDEFS,0    

*PARTLIST,7    
C1,TANTALUM4U735V,4u7,EID=9,PACKAGE=ELEC-RAD20
C2,POLYLAYER100N,100n,EID=4,PACKAGE=CAP30,PINSWAP="1,2",VMAX=12V
D1,LED-YELLOW,LED-YELLOW,BV=4V,EID=7,IMAX=10mA,PACKAGE=LED,ROFF=100k  ,RS=3,TLITMIN=0.1m,VF=2V
R1,MINRES200R,200R,CODE=M200R,EID=6,PACKAGE=RES40,  PRIMTYPE=RESISTOR
R2,MINRES120K,120k,CODE=M120K,EID=3,PACKAGE=RES40,  PRIMTYPE=RESISTOR
R3,MINRES1K,1k,CODE=M1k,EID=2,PACKAGE=RES40,PRIMTY  PE=RESISTOR
U2,NE555,NE555,EID=1,ITFMOD=555ITF,PACKAGE=DIL08,T  TOL=10u

*NETLIST,7    
#00001,3
U2,IP,7
R2,PS,1
R3,PS,2

#00002,2
U2,OP,3
R1,PS,1

#00004,4
U2,IP,2
U2,IP,6
C1,PS,+
R2,PS,2

#00005,2
U2,IP,5
C2,PS,1

#00006,2
R1,PS,2
D1,PS,A

GND,5,CLASS=POWER
GND,PR
U2,PP,1
C2,PS,2
D1,PS,K
C1,PS,-

VCC/VDD,5,CLASS=POWER
VCC,PT
VCC/VDD,PR
U2,IP,4
U2,PP,8
R3,PS,1

*GATES,0

Как видите весьма простой и доходчивый способ записи списка. И при небольшом навыке его можно запросто читать, как букварь. Я же в данный момент хочу заострить ваше внимание на двух последних узлах, которые начинаются отнюдь не с решетки и имеют в своем описании типа CLASS=POWER. Это и есть наши цепи питания GND и VCC/VDD. В данном случае это терминалы питания, присвоенные проекту по умолчанию, и описанные в разделе меню Design =› Configure Power Rails.
Следующий за ними раздел *GATES мы рассмотрим позднее, а пока сосредоточим свое внимание на шинах питания. Я в том же проекте (Рис. 27) присвою нашему верхнему терминалу питания лэйбл +15V. На Рис. 31 представлены два аналоговых графика для разных значений. Посмотрите внимательно на амплитуды сигналов таймера.
Это называется как в известной комедии - «легким движением руки». Но и это еще не все. Сформируем опять Netlist с помощью компилятора. Ниже приведено только окончание нового листа.

#00006,2
R1,PS,2
D1,PS,A

+15V,4,CLASS=POWER
+15V,PR
U2,IP,4
U2,PP,8
R3,PS,1

GND,5,CLASS=POWER
GND,PR
U2,PP,1
C2,PS,2
D1,PS,K
C1,PS,-

*GATES,0

Обратите внимание у нас напрочь исчез узел VCC/VDD, зато появился аналогичный +15V. Наиболее сообразительные уже догадались, что именно он и будет передан через SDF в ARES для обработки. Для тех? кто еще не понял к чему я веду – усложняем задачу (пример Ex2). В нем я вернул таймеру питание VCC/VDD, подключил светодиод через транзисторный ключ и запитал его от терминала +15V (Рис. 32). Кроме того, я ввел в схему три единичных терминала из библиотеки Connectors ISIS, имеющих свои PCB и подключил их к соответствующим питающим терминалам: GND, VCC/VDD (без обозначения) и +15V. Они мне потребуются в ARES.
Снова сформировал список цепей и получил в конце его следующее:

+15V,3,CLASS=POWER
+15V,PR
J2,PS,1
R1,PS,1

GND,6,CLASS=POWER
GND,PR
J3,PS,1
U2,PP,1
C2,PS,2
C1,PS,-
Q1,PS,3

VCC/VDD,6,CLASS=POWER
VCC,PT
VCC/VDD,PR
J1,PS,1
U2,IP,4
U2,PP,8
R3,PS,1

Обратите внимание, что узлов питания в SDF стало три! И три отдельных цепи питания будут переданы в ARES для обработки. Соответственно они будут и разведены как три отдельные цепи на плате. Так можно продолжать и далее до бесконечности. Просто хочу отметить, что я не «рисую» цепи питания, а просто нахально добавляю их в схему с нужным мне вольтажом. Но я оставлю дальнейшие рассуждения на следующий параграф, а здесь необходимо закончить с Netlist, чтобы больше к нему не возвращаться.
Вернемся к рисунку 29 параметров Netlist Compiler… До сих пор мы там ничего не трогали, чтобы формировался стандартный SDF, но давайте посмотрим – что там еще можно изменить и для чего.
В левой части окна расположены четыре переключателя.
• Output – вывод. По умолчанию стоит Viewer (просмотрщик), поэтому и открывается окно. Если поставить в File(s) будет сразу формироваться файл без окна просмотра.
• Mode – режим. По умолчанию стоит Phisical (физический), т.е. информация в списке содержит как имя вывода компонента, так и его номер. Этот режим считается обязательным для ARES и в большинстве случаев передачи в сторонние программы. Если поставить Logical, то информация о номере вывода формироваться не будет.
• Scope – область видимости. По умолчанию Whole Design – весь проект. Но иногда надо сформировать список только для текущего листа многолистового проекта, тогда выбирается опция Current Sheet.
• Depth – глубина захвата. По умолчанию и наиболее подходящая в большинстве случаев Flatten (сглаженный). В этом случае объекты содержащие дочерние листы будут заменены в списках их содержанием. Если выбрать This Level, то информация о содержании дочерних листов в списках соединений не появится.
В правой части окна расположен переключатель режима компилятора. По умолчанию формируется стандартный для Протеуса формат SDF-файла. Однако, разработчики Лабцентра позаботились о том, чтобы информацию можно было передавать и в сторонние программы. Вопрос о том, насколько совместимыми окажутся форматы компилируемых файлов я оставлю для самостоятельного исследования наиболее дотошным пользователям, а здесь только перечислю режимы, которые заложены в переключателе Format.
EEDESIGNER – создается файл формата EE Designer III. Информация о корпусах как в Boardmaker. При компиляции используется Phisical режим.
MULTIWIRE/EAG – создается файл формата Multiwire, также используется для передачи в небезизвестный Eagle. Поклонники «клювастого» могут поэкспериментировать. При компиляции используется Phisical режим.
SPICE – формат говорит сам за себя. Также может быть использован для передачи списка в PSpice. При необходимости выходной файл формата .LXB переименовывается в .LIB. При компиляции используется Logical режим. Для передачи в более старые версии Spice под DOS используется формат SPICE AGE, расположенный чуть ниже в списке форматов.
TANGO – формат используется для передачи например в Protel. При компиляции используется Phisical режим.
Ну и остальной ряд форматов для передачи в одноименные программы, о некоторых из которых я и сам ничего толком не могу сказать. Это Vutrax, Futurenet, RACAL и т.д. Я надеюсь, что те, кому понадобятся такие форматы, самостоятельно разберется, прочитав HELP. Я же на этом заканчиваю рассмотрение компилятора списка цепей и плавно перехожу в Configure Power Rails, как продолжение данной темы с развитием примеров приложенных к этой теме.
Рисунки 27, 28, 29
Рисунки 30, 31, 32

[Halex07]

4.5. Configure Power Rails или питания «видимо не видимо».
Итак, чуть выше мы разобрали, что терминалов питания можно навешать сколько угодно всяких и разных. И задумываться про это особенно не стоит. В первой части FAQ я уже упоминал про окно Configure Power Rails (конфигурация шин питания), которое вызывается через верхнее меню Design, а заодно и разберемся со всеми видами электропитания в ISIS раз и навсегда. Как я уже отмечал, при создании нового проекта Протеус по умолчанию вводит три шины питания: VCC/VDD=+5V, GND=0V и VEE=-5V. Это при условии, что стоит флажок в соответствующем окне внизу (Рис. 33).
При этом первые две шины не надо даже именовать. Достаточно поставить в схеме терминал питания POWER из левого меню или терминал земли GND и присоединить к ним соответствующие выводы компонентов в проекте, и они автоматически присоединяются к соответствующим шинам питания. Это для тех компонентов у которых выводы питания есть. А как быть с теми, у которых они скрыты? Почему-то наши пытливые умы упорно желают пририсовать видимые провода к этим выводам. Кроме как чисто физического удовлетворения от вождения мышью по ковру, по моему личному мнению здесь никакой пользы нет. Но специально для Вас – любой каприз. Давайте сначала обозначимся к чему можно «прорисовать» провода, а к чему нет. Все очень просто - воспользуемся опцией меню Template =› Set Design Defaults… и поставим в ней галочку Show Hidden Pins? (показать скрытые выводы). Я это уже описывал в начале FAQ, но приходится повторяться. Теперь, с установленной галкой можно зайти в библиотеку компонентов ISIS и пошариться там. У всех компонентов, которые имеют скрытые выводы питания они проявятся серым цветом в окне предпросмотра (Рис 34).
Таким образом, можно сразу определить – можно сделать их видимыми и активными или нет. А точнее сказать видимыми мы уже их сделали, но вот если поместить такие компоненты в проект, то подвести провода к этим серым выводам мы все-таки не можем, они к ним «не припаиваются». Этому горю легко помочь, вот только как бы эта услуга не оказалась «медвежьей».
Для начала три не очень «лирических» замечания.
Замечание первое. Это замечание касается микроконтроллеров AVR. Заходим в HELP по этим микроконтроллерам, заглядываем в раздел General Model Limitations (основные ограничения модели) и видим там фразу: Power supply voltage changing is not supported. Для англоязычной публики вопрос отпал сразу, для остальных - корявый машинный перевод: «Изменение напряжения источника питания не поддержано».
Замечание второе. Это замечание касается многоэлементных логических микросхем, столь популярных у начинающих: типа двухвходовых И, инверторов и т.п. Можете сразу пробежаться в библиотеках с включенным флажком Show Hidden Pins и убедиться, что у них нет ни видимых ни невидимых ног питания (как у удава в мультике). Это дело поправимое, но об этом чуть позже и совсем не тем способом, который Вы ожидали лицезреть.
Замечание третье. Пожалуй, самое серьезное. Все, что я писал красным цветом в предупреждении к материалу о менеджере библиотек остается в силе и здесь. Сейчас мы начнем библиотеки «шерстить и в хвост и в гриву», поэтому позаботьтесь заранее о защите от записи оригинальных, если не хотите все испортить. Особенно это касается владельцев нелицензионных копий программы. О том, как поставить защиту писалось в материале двумя постами выше. Кто позабыл – бегом туда. За Ваши «кривые ручки» я ответственности не несу. Связано это с тем, что нам придется мэйкать (Make Device) модели под их оригинальными именами и желательно, чтобы дубли не заменили «родные» модели.
Ну а теперь перейдем конкретно к «оживлению» выводов питания. Берем навскидку любую подхоящую для этих целей модель. Мне приглянулся счетчик 74HC161. Тут я отстреливаю сразу двух ушастых, поскольку это схематичная MDF модель, а именно из-за них и придется сохранять дубли с тем же именем. Обвешал я его тестовыми примочками из библиотеки ISIS Debugging Tools, прилепил тактовый генератор, и получилось то, что вы видите на Рис. 35 и в прилагаемом примере Ex1_Pow. Т.е. пока модель работает.
Затем, рядом я поставил точно такую же микросхему и применил к ней опцию Decompose: или через верхнее меню (кнопка с молотком), или через правую кнопку мыши. У разобранной на запчасти модели для верхней и нижней ног питания я зашел в свойства и поставил флажки - как на (Рис. 36). Если кому-то хочется, чтобы подсвечивалось еще и имя – можете включить и третий флажок, не возбраняется.
После этого с помощью левой кнопки мыши выделил область, обязательно(!!!) захватив текстовый скрипт (Рис.37), и применил к ней функцию Make Device так, как мы делали при создании графической модели.
А теперь самый ответственный момент – все пять окон мы проходим, ничего не изменяя!!! Даже название в первом окне необходимо оставить то же. В последнем окне перед нажатием ОК необходимо убедиться, что наша модель будет сохраняться в USRDVC, ну или созданной Вами личной библиотеке. Вот собственно и вся процедура. Теперь у Вас в библиотеке ISIS будет две модели – одна в родной библиотеке 74HC, а другая в USRDVC – вот она то и окажется с активированными выводами питания (Рис. 38 ). Кстати, в селектор после Make… она сразу подставится автоматом. Ее я применил в примере Ex2_Power. Для тестирования приложен аналоговый график, чтобы увидеть уровни сигнала по напряжению.
На Рис. 39 два графика для двух микросхем из Ex2 при разных уровнях питания и разных частотах тактовой Clock. На графиках видно, что уровни по напряжению разные, что и требовалось доказать этим примером. Теперь объясню, почему потребовалось не изменять имя модели. Дело в том, что для большинства схематичных моделей часть свойств прописана в текстовых скриптах, находящихся в MDF-файлах, а там четко прописано имя модели. Вспомните предыдущий материал – скрипт *PROPERTIES – речь о нем. Если при создании модели мы изменим хотя бы букву в имени, то скрипт работать не будет, и мы получим ошибку при симуляции. Позже, при создании собственных MDF, мы к этому еще вернемся.
Теперь давайте заглянем в Configure Power Rails в тех проектах, где мы добавляли свое питание с помощью терминалов прямо на схеме, например в последнем Ex2_Power. Да ведь наши +3V сами там прописались в раскрывающемся списке. Вопрос – а зачем тогда нужно это окно? Ну, во-первых, если Вы делаете простой проект с одиночным питанием, то можно заранее изменить значение вольтажа например, для VCC/VDD на нужное и потом «не париться» с указанием вольтажа у терминалов питания, а просто ставить без наименования их в схему. Во-вторых, когда терминалов наставлена туча, да еще на нескольких листах то проще менять питание здесь, чем метаться по всем листам, разыскивая нужные терминалы. Ведь можно для терминалов в схеме назначить не конкретное напряжение, а буквенную аббревиатуру, например: HV (я сократил фразу Higth Voltage), а в окне Configure Power Rails для HV присвоить конкретное значение, допустим +300V. Теперь, для того чтобы изменить значение на +330V достаточно войти в окно и Configure Power Rails заменить значение. Все терминалы, с именем HV соответственно тоже поменяют значение напряжения.
Ну и в заключение данного материала хочется отметить, что на все, что здесь говорилось о визуализации можно «наплевать и забыть» в хорошем смысле этой фразы. Кроме морального удовлетворения от «изнасилования» моделей я не вижу в этом никакой пользы. Ну, увидели мы выводы питания на схеме – а «оно нам надо»? Обратимся к примеру Ex3_Power. В нем я вернул оригинальную модель счетчика, а на выход Q0 прилепил инвертор 4049. Счетчику я вообще все сместил и землю и плюс питания, а инвертору только плюс питания. Заметьте, инвертору, у которого нет видимых ног питания!!!
Теперь переходим к самой процедуре на примере инвертера. Входим в его свойства Edit Properties и нажимаем справа кнопку Hidden Pins. В открывшемся окне вводим для Pin VDD текст так, как на Рис. 40 и давим ОК. Затем заходим в окно Configure Power Rails и в нем проделываем операции в соответствии с цифрами на Рис. 41
Аналогичным образом я поступил и со счетчиком, только у него еще и для GND назначил Power_3V. После таких процедур внизу у моделей подсвечиваются внесенные изменения для питания, а на графиках видно, что изменения функционируют в полном объеме (Рис. 42). При этом я не трогал сами модели и добился нужного результата. Ну вот теперь, кажется, разжевал все до мелочей – глотайте. Все, о чем здесь говорилось, касается источников питания постоянного тока. О питании переменного тока поговорим ниже.
Рисунки 33, 34, 35.
Рисунки 36, 37, 38.
Рисунки 39, 40, 41.
Рисунок 42.