开云体育

All LTspice users should be familiar with UniversalOpamps. There are 7 different UniversalOpAmp models of increasing complexity capable of modelling almost any proprietary opamp to reasonable levels of accuracy in most regards, typically with superior convergence and speed within LTspice.

I see quite a few people using opamps to model comparators, despite the requirements being quite different. It occurred to me this might be because there isn't an equivalent universal comparator. So I set out to change that.

The UniversalComp is the simplest solution I could think of with just one B-source, and it features:

• Programmable Propagation Delay (trapped to prevent values <0)
• Programmable Hysteresis (trapped to prevent values <0)
• Rail-to-Rail Output
• Excellent convergence
• Blistering speed
• Infinite Common-mode Input Range

开云体育

Very helpful. It would be good to add a .ZIP of all the files to the folder.

All LTspice users should be familiar with UniversalOpamps. There are 7 different UniversalOpAmp models of increasing complexity capable of modelling almost any proprietary opamp to reasonable levels of accuracy in most regards, typically with superior convergence and speed within LTspice.

I see quite a few people using opamps to model comparators, despite the requirements being quite different. It occurred to me this might be because there isn't an equivalent universal comparator. So I set out to change that.

The UniversalComp is the simplest solution I could think of with just one B-source, and it features:

• Programmable Propagation Delay (trapped to prevent values <0)
• Programmable Hysteresis (trapped to prevent values <0)
• Rail-to-Rail Output
• Excellent convergence
• Blistering speed
• Infinite Common-mode Input Range

I have also made two symbols, with the inputs reversed for drafting convenience, that are otherwise pin-wise compatible with the opamp2 and UniversalOpAmp symbols. The model and a test schematic is also available in Universal Comparator.

--
Regards,
Tony

开云体育

Oops, maybe you missed that one.? An easy oversight.

?

• Blistering speed

I am inclined to agree with that.? But I will note that there are some LTspice users who feel its B-elements are much slower than the same circuit without the B-elements.? IIRC, Vlad (one of our group members, who has been quiet here lately) was one of those who had some opposition to B-elements when speed was critical.? I don't want to imply that there is anything wrong with them, but it's possible that a built-in "Digital" gate might be faster - although somewhat more cumbersome to use.

My (very) limited measurements suggest that the B-source is about 5-10% slower than an A-source, but that might vary considerably with processor and circuit complexity (I only tried on my Ryzen 9 machine, which is over twice as fast as my last one according to my previous tests). I also found that LTspice XVII was consistently around 20% slower than 24.0.12. This is all less significant than suggested by "much slower".

Your (other) comment about an open-collector (or open-drain) output had me thinking half the night. So far, I haven't come up with a simple way to make that an option using the present form of the transfer function without adding extra bits. It's a useful suggestion though, and the option should be available, as O/C comparators are fairly common and are practically useful, whereas the LM311-type O/C-O/E variant is almost unique anyway, so there's not much point in emulating it.

Whether or not to hard-code the ModelFile attribute is a thorny one. My personal feeling is that I don't like doing that with symbols and models that are not core LTspice ones, for the simple reason that all users will have the built-in ones, but for added symbols users should be explicitly prompted due to the issues we're familiar with in sharing schematics. Anyone that feels strongly about it can make their own versions.

--
Regards,
Tony