PSPICE считается "industry standard" многими производителями компонентов и в связи с этим многие из них разрабатывают SPICE модели в PSPICE формате.
Причин этому несколько, не думаю что имеет смысл вдаваться в подробности почему именно PSPICE. Но вот так сложилось.
Мне PSPICE кажется не удобным. По нескольким причинам. Во первых он не всегда есть под рукой, так как входит в платный комплект Аллегро/Оркад.
Правда в последнее время стала доступной версия для TI, позволяющая обойти это ограничение. Но мне не нравятся и другие его ограничения.
Например, он не позволяет использовать больше одного параметра, который изменяется директивой STEP. По крайней мере так было в предыдущих версиях.
Мне не нравится то что надо иметь две библиотеки, одну для рисования схемы, другую для самой модели. И много других "мелочей".
Я предпочитаю использовать LTSPICE.
В принципе, перевести модель из PSPICE в LTSPICE не сложно. Естественно, модель должна быть открытой, зашифрованные модели можно использовать только в том совте для которого они зашифровывались
Берете модель которую дает производитель. Обычно это текстовый файл с расширением mod, lib или чем-то подобным. создаете символ для модели и используете его в своей схеме.
Подробнее о том как это делать - https://www.audio-perfection.com/spice-l...n-ltspice/
Иногда это работает. Но чаще всего появляются ошибки связанные с некоторой разницей в синтаксисе.
Очень часто это связанно с различной интерпретацией фигурных скобок {}. Тогда в лог файле появляется что-то типа:
Questionable use of curly braces in ".........
Error: undefined symbol in: ".........
Или же появляются проблемы со сходимостью, связанные с различием параметров определяющих точность вычислений и паразитных параметров, принятых по умолчанию.
Что может проявляться в том что при моделировании будет выскакивать ошибка с невозможностью уменьшить временной дискрет.
В принципе, использование фигурных скобок определено в LTSPICE не совсем очевидно.
То что в них вложено будет заменено значением результата вычисления. Но надо представлять где и как это можно использовать.
Соответственно, когда это использует PSPICE будет очевидно из модели которая выдает ошибки.
А как они используются в LTSPICE рассмотрим на примерах. В справке самого LTSPICE их немного
Например при использовании в .func и передаче параметров
Или:
Еще один пример правильного использования:
Результат из "error log":
capa_: capa=2.95e-012
Неправильный метод, выдаёт ошибки:
Ошибка:
Measurement "capa_" FAIL'ed
Я тут накидал несколько примеров чтоб показать что работает, а что выдает ошибки. И как можно просто проверить, что именно правильно работает
Они довольно просты и надеюсь не нуждаются в дополнительных пояснениях.
Что касается сходимости, можно попробовать изменить некоторые значения параметров, отвечающих за точность моделирования.
Например:
.options gmin=1e-10 -->сопротивление утечки, по умолчанию 1е-12
.options cshunt=1e-14 -->паразитная емкость каждого внутреннего узла, по умолчанию 0
.options abstol=1e-10 -->по умолчанию 1е-12
.options reltol=0.003 -->по умолчанию 0.001
Это во многих случаях поможет победить ошибку "time step too small convergence fail"
За кадром конечно остались некоторые другие отличия, например некоторая разница в моделировании полевиков и интерпретировании их параметров.
Но это обычно не создает фатальных проблем и легко корректируется.
Причин этому несколько, не думаю что имеет смысл вдаваться в подробности почему именно PSPICE. Но вот так сложилось.
Мне PSPICE кажется не удобным. По нескольким причинам. Во первых он не всегда есть под рукой, так как входит в платный комплект Аллегро/Оркад.
Правда в последнее время стала доступной версия для TI, позволяющая обойти это ограничение. Но мне не нравятся и другие его ограничения.
Например, он не позволяет использовать больше одного параметра, который изменяется директивой STEP. По крайней мере так было в предыдущих версиях.
Мне не нравится то что надо иметь две библиотеки, одну для рисования схемы, другую для самой модели. И много других "мелочей".
Я предпочитаю использовать LTSPICE.
В принципе, перевести модель из PSPICE в LTSPICE не сложно. Естественно, модель должна быть открытой, зашифрованные модели можно использовать только в том совте для которого они зашифровывались
Берете модель которую дает производитель. Обычно это текстовый файл с расширением mod, lib или чем-то подобным. создаете символ для модели и используете его в своей схеме.
Подробнее о том как это делать - https://www.audio-perfection.com/spice-l...n-ltspice/
Иногда это работает. Но чаще всего появляются ошибки связанные с некоторой разницей в синтаксисе.
Очень часто это связанно с различной интерпретацией фигурных скобок {}. Тогда в лог файле появляется что-то типа:
Questionable use of curly braces in ".........
Error: undefined symbol in: ".........
Или же появляются проблемы со сходимостью, связанные с различием параметров определяющих точность вычислений и паразитных параметров, принятых по умолчанию.
Что может проявляться в том что при моделировании будет выскакивать ошибка с невозможностью уменьшить временной дискрет.
В принципе, использование фигурных скобок определено в LTSPICE не совсем очевидно.
То что в них вложено будет заменено значением результата вычисления. Но надо представлять где и как это можно использовать.
Соответственно, когда это использует PSPICE будет очевидно из модели которая выдает ошибки.
А как они используются в LTSPICE рассмотрим на примерах. В справке самого LTSPICE их немного
Например при использовании в .func и передаче параметров
Код:
.func myfunc(x,y) {sqrt(x*x+y*y)}
.param u=100 v=600
V1 a 0 pulse(0 1 0 1n 1n .5μ 1μ)
R1 a b {myfunc(u,v/3)}
C1 b 0 100p
.tran 3μ
.endИли:
Код:
* Описание схемы
.params x=y y=z z=1k*tan(pi/4+.1)
X1 a b 0 divider top=x bot=z
V1 a 0 pulse(0 1 0 .5μ .5μ 0 1μ)
* Сама subcircuit "divider" использованная в схеме
.subckt divider n1 n2 n3
r1 n1 n2 {top}
r2 n2 n3 {bot}
.endsЕще один пример правильного использования:
Код:
* Comment line : Calculate capacitance
* -------------------------------------
.param length = {3e-2}
.param width = {4e-3}
.param area = {length * width}
.param gap = {40e-6}
.param Eo = {8.85e-12}
.param Capa = { (Eo * gap) / area}
.MEAS Capa_ PARAM CapaРезультат из "error log":
capa_: capa=2.95e-012
Неправильный метод, выдаёт ошибки:
Код:
.param length = 3e-2
.param width = 4e-3
.param area = length * width
.param gap = 40e-6
.param Eo = 8.85e-12
.param Cap = (Eo * gap) / area
.MEAS Capa_ PARAM CapaОшибка:
Measurement "capa_" FAIL'ed
Я тут накидал несколько примеров чтоб показать что работает, а что выдает ошибки. И как можно просто проверить, что именно правильно работает
Они довольно просты и надеюсь не нуждаются в дополнительных пояснениях.
Что касается сходимости, можно попробовать изменить некоторые значения параметров, отвечающих за точность моделирования.
Например:
.options gmin=1e-10 -->сопротивление утечки, по умолчанию 1е-12
.options cshunt=1e-14 -->паразитная емкость каждого внутреннего узла, по умолчанию 0
.options abstol=1e-10 -->по умолчанию 1е-12
.options reltol=0.003 -->по умолчанию 0.001
Это во многих случаях поможет победить ошибку "time step too small convergence fail"
За кадром конечно остались некоторые другие отличия, например некоторая разница в моделировании полевиков и интерпретировании их параметров.
Но это обычно не создает фатальных проблем и легко корректируется.
Nobody Is Perfect
