Моделирование

Среди канонических программ gEDA Suite есть две программы аналогового моделирования: ngspice и gnucap. (Чуть) более подробно:

• ngspice — это перенос/доработка классической программы SPICE 3f5 для платформы GNU/Linux. Она полнофункциональна, включает расширения XSpice (такие как конструкции SPICE 2 POLY) и фреймворк CIDER.
• gnucap — это новая, написанная с нуля программа схемотехнического моделирования. Она предоставляет возможность выполнения как событийного, так и сквозного моделирования. Это — плод труда Al Davis. Если вы хотите загрузить её, убедитесь, что скачиваете последнюю версию, которую можно найти по ссылке “development releases” (рабочие выпуски) на сайте gnucap.

Обе программы имеют только интерфейс командной строки, то есть взаимодействие с программой моделирования осуществляется набором команд в командной строке. Это значит также, что вам нужно изучить специфический для программы набор команд.

Если вы предпочитаете графический интерфейс, новое приложение gEDA gspiceui предоставляет хорошую графическую оболочку для работы с этими программами моделирования. Однако gspiceui не предоставляет полного цикла вида “от-схемы-до-вывода-моделирования” подобно LTSpice или PSpice. Точнее, она просто предоставляет графическое меню, помогающее управлять командами, нужными для выполнения моделирования с помощью ngspice / gnucap.

Проект tclspice был ответвлением основного маршрута разработки ngspice. Он был начат в 2002 году. В принципе, tclspice должен был бы экспортировать набор команд SPICE в API TCL, позволяя вам встроить SPICE-анализ в TCL-программу. Это определённо очень привлекательная цель, так как TCL — это мощный скриптовый язык, намного более мощный, чем скриптовые конструкции имеющиеся в самом SPICE. При использовании TCL, как можно себе представить, возможно написание сложных оптимизаторов схем, добавление в моделирование поведенческих элементов и, наконец, получение управления над графическим выводом SPICE.

Как оказалось, эта цель была достигнута частично — с помощью tclspice в самом деле можно сделать что-то вроде этого:

#! tclsh
package require spice
spice::codemodel /usr/local/src/tclspice-0.2.12/src/xspice/icm/spice2poly.cm

spice::source netlistname.cir
spice::tran 0.1ns 40ns
spice::run
spice::plot Vout
puts "Всё готово!"

К сожалению, в tclspice отсутствуют некоторые важные возможности, как например выдача кода возврата, который сообщит, работает ли в данный момент моделирование или оно завершилось ошибкой. Кажется и графическая функциональность тоже никогда не работала (по крайней мере для меня…, и разработчики согласны, что графика отвратительна). Трансляция переменных TCL в векторы SPICE и наоборот тоже, кажется, никогда не работала, опять, по крайней мере для меня. Наконец, в ngspice (по крайней мере) множество утечек памяти, что затрудняет выполнение длительного моделирования. Поэтому tclspice не соответствует данным изначально обещаниям: быть удобным скриптовым средством для выполнения SPICE-моделирования.

Действительная разработка проекта tclspice остановилась в 2004 году. Возможно когда-нибудь кто-нибудь снова возьмётся за него. Тем временем основная ветка разработки ngspice приобрела возможности tclspice, если они вам нужны (для них требуются особые ключи в конфигурации), и код там более свежий.

Существует очень мало моделей с открытым исходным кодом, предоставленных в общее пользование энтузиастами. Вот почему в пакетах gnucap и ngspice нет больших библиотек моделей. Если вы сваяли свою собственную, и вам хотелось бы внести свой вклад в проект, это может быть отличной возможностью (намёк, намёк…).

Хотя многие производители и предоставляют бесплатно SPICE-модели, они сохраняют проприетарную лицензию. Это значит, что данные модели не могут распространяться вместе с gEDA Suite. К тому же, в различных реализациях SPICE мнения насчёт правильного синтаксиса несколько различаются. Как следствие, некоторые модели, поставляемые производителями, необходимо корректировать для работы со специфической реализацией.

spicelib предоставляет средство получения моделей, скорректированных для gnucap и ngspice. Это набор скриптов, который доставит модели поставщиков непосредственно из исходного местоположения, что решает проблему их распространения. Затем подправит их для совместимости с gnucap и ngspice. spicelib можно загрузить со страницы http://www.h-renrew.de/h/spicelib/doc/index.html.

Нет. Лучшее, что можно сделать — использовать gspiceui.

Обычная последовательность разработки — gschem → gnetlist -g spice-sdb → [ngspice | gnucap]. Чтобы задать необходимые атрибуты для SPICE / gnucap, их нужно прикрепить к компонентам в своей схеме. Можно также добавить атрибуты с помощью gattrib.

Всё это очень подробно описано в HOWTO по схемотехническому моделированию с помощью gEDA и SPICE.

Некоторые SPICE-ресурсы помогут вам понять, как использовать spice-sdb.

Используйте драйвер spice-sdb. Он наиболее продвинутый и очень богат возможностями. Другие остались только по историческим причинам. Обратите внимание, что spice-sdb является расширением одного из других драйверов SPICE, так что, используя его, вы ничего не потеряете.

Да. Также можно начертить свою схему с использованием директив gnucap, находящихся в библиотеке символов в каталоге spice.

Лучше просто начертить схему, без директив, и запустить эту программу моделирования интерактивно.

Новички обычно хотят сделать одну принципиальную схему и для моделирования/проверки работоспособности проекта, и для разработки топологии. На первый взгляд это кажется заманчивым, так как проект топологии уже будет протестирован и проверен на работоспособность до его отправки на производство на FR-4. Однако дьявол кроется в деталях. Использовать одну и ту же схему для моделирования и разработки топологии обычно не получается по следующим причинам:

• Компоненты для моделирования и разработки топологии обычно совершенно различны. Например, для моделирования часто требуется, чтобы в схеме содержалось много устройств, относящихся к SPICE, таких как источники напряжения, зависимые источники, директивы SPICE и так далее. С другой стороны, для разработки топологии нужны компоненты, не используемые в SPICE, такие как соединители, логические устройства, и даже такие устройства, как регуляторы напряжения, для которых может и не быть модели SPICE, но они будут засорять список соединений SPICE, возможно вызывая недовольство генератора списка соединений и программы моделирования.
• Для некоторых настоящих электронных компонентов нет моделей SPICE, встроенных в программы. Есть множество компонентов, не имеющих моделей для SPICE, например, потенциометры, трансформаторы, термисторы, фильтры электромагнитных помех, логические элементы, кварцевые резонаторы, электронные лампы и так далее. Поэтому, если в вашем проекте используются какие-либо из этих компонентов, вам придётся для моделирования имитировать эти устройства, используя эквивалентные схемы. Это сильно осложняет использование для разработки топологии той схемы, что создана для моделирования.
• Обычно на самом деле нужно смоделировать поведение только какой-то части разработки. Например, вы можете захотеть смоделировать поведение фильтра или кварцевого резонатора, но вам не нужно (или вы не можете) моделировать работу источника питания, логики или других частей своего проекта. Если вы упорно будете настаивать на создании SPICE-моделей для этих отдельных частей схемы, то может быть вам придётся пройти множество трудных испытаний, — и сделать много ненужной тяжёлой работы, — чтобы найти или создать SPICE-модели для частей своей разработки, которые не так уж и важны.

Поэтому я (SDB) обычно рекомендую не слишком сильно пытаться использовать одну и ту же схему и для моделирования, и для разработки топологии. Если можно это сделать — здорово! Но обычно — нельзя.

Лично я склоняюсь к тому, чтобы создавать SPICE-модели только для критических аналоговых частей своих проектов. Поэтому проект побольше может содержать пару схем для моделирования аналоговых частей схемы с целью проверки их работоспособности. Кроме схем для моделирования, у меня будет и основная схема, используемая для разработки топологии.