开云体育

I'm creating some subcircuits and would like to use some parameters of a model in further expressions, but only have to define the value once in the model itself. Is this possible in LTSpice? For example can I use the saturation current of a particular transistor model in a subsequent expression? eg:

?

* define a model with some parameters

.model npnmodel npn(is=1e-16 n=1.02)

?

* access one of the parameters in an expression somehow to calculate a derived value

* - the actual expression will be more complicated than just *2

.param val = {npnmodel(is)*2}

If I understand you correctly - yes, this is possible. But rather than try and describe it, I have uploaded one available solution - undoubtedly, there are others.

Param-to-subckt-to-model

BTW, it is not necessary to use braces when assigning a numeric value to a parameter.

开云体育

Thanks for the reply. I already know how to create a parameter and use this value in a .model statement of transistor / diode etc, which is what you have shown, but unfortunately this doesn't help with my question.

?

Is there a way to access a value defined in the .model statement of a transistor etc, and then use that value elsewhere in an expression?

?

Is there some syntax like: "getvalue(npnmodel, is)", or "npnmodel.is", or something similar to grab the already defined value out of a .model statement?

?

I scoured the LTSpice docos / online resources but and can't find anything like this, so I am guessing the answer is no, but I thought I'd ask here for an more official "no". I can workaround it in other ways, but having this sort of access would be really useful to prevent a bunch of manual text editing every time I want to try out a different model and calculate derived expressions from it.

I think your guess is correct. This isn't an "official "no". But since the Gummel-Poon model, for example, is public domain, it would in principle be possible to derive it from the actual characteristics. There is another issue: in most models, some of the parameters are not stated, so remain at their default value, which is often zero, but not always. Therefore they couldn't be extracted from the .model. I don't know for sure, but it's also possible that not all simulators have the same default values. I would think this is enough to deter you from this route, and probably why such a reverse look-up doesn't exist.

--
Regards,
Tony

开云体育

Inside each .model there will definitely be default values stored somewhere, which could be returned if one is not provided explicitly in the .model statement, so I don't see why this couldn't be done. LTSpice is great for how it handles arbitrary expressions and behavioural devices, so I'm sure it would be possible to do such a thing if the developers wanted to.

Many things are possible. Default parameter values for LTspice, at least, are listed in the Help, so you could create your own default intrinsic models if you wished - put them into the standard.xxx libraries. I think LTspice uses the last same-named model it encounters. In any event, I petty sure they cannot be accessed programmatically internally, although it would straightforward to do externally. Unfortunately, LTspice cannot invoke arbitrary external code. Many years ago, long before its acquisition by ADI, LTspice had features that were used internally by LTC, but not documented or even acknowledged. Some were completely removed after being "discovered", or at least hidden more deeply, similar to the binary format of proprietary models that are supplied, but cannot be read. You need to remember that LTspice is proprietary software. If you want a SPICE that you can customise, Ngspice is open source - you could add features of your own to your heart's content. Similarly, the original SPICE code from Berkeley is public domain and freely available - an "up to date" buildable version for Linux can be found here:

I've no doubt it could be done in LTspice, but unless it's facilitated by one of the other ongoing enhancements to V24.1.x, good luck wishing for it. AFAIK, no one has ever requested it.

At least for now, you're stuck with a workaround.

--
Regards,
Tony