开云体育

Universal Comparator


 

开云体育

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


 

开云体育

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

On 2025-05-18 18:29, Tony Casey via groups.io wrote:
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
--
Best wishes John Woodgate RAYLEIGH Essex OOO-Own Opinions Only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion

Virus-free.


 
Edited

Quite interesting.
?
Me, I tended to use one of LTspice's built-in Digital devices (diffschmitt, etc.) when needing a generic comparator, but they have disadvantages.? Yours is simpler and in many ways better.
?
Have you considered making the symbol load the model file automatically, the same way the UniversalOpAmp* symbols already do?
?
Would it help to make the SpiceLine attribute visible by default, to encourage setting those parameter values?
?
I also wonder if it is best having the output voltage swing between the V+ supply and (hidden) ground - as opposed to swinging between the two supply voltages.? How would a generic comparator behave?? Especially when it has no visible connection to ground?? [Edited because it was my mistake.]
?
Also there is the open-drain or open-collector option.? Should there be an alternate version that pulls down only?
?
Andy
?
?


 
Edited

On Sun, May 18, 2025 at 01:29 PM, Tony Casey wrote:
  • Rail-to-Rail Output
Oops, maybe you missed that one.? An easy oversight.
[Edited because this was my mistake.]
?
  • 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.
?
Andy
?
?


 

开云体育

On 18/05/2025 21:09, Andy I via groups.io wrote:
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


 

Regarding what I thought was the lack of rail-to-rail output drive:
?
I missed what was happening in your test circuit.? I missed the fact that your negative supply voltage V- was at 0V.? Oops.
?
And then when I thought I was setting V- to -5V, I actually set it to -(-5)V, which made it appear as if the comparator had failed.? Arrgh, I should give up and go home.? All is OK (except inside my brain).
?
The output impedance is 1 ohm, which should not be a big problem for many users.? But it can affect signals driven into power FETs that have significant input capacitance.? I believe 1 ohm is the default output impedance of LTspice's built-in A-elements.
?
Andy
?


 

开云体育

On 19/05/2025 12:39, Andy I via groups.io wrote:
Regarding what I thought was the lack of rail-to-rail output drive:
?
I missed what was happening in your test circuit.? I missed the fact that your negative supply voltage V- was at 0V.? Oops.
No, that was my oops. That was a quick test to see whether that revealed any unexpected behaviour. I hadn't intended to upload that version.
?
And then when I thought I was setting V- to -5V, I actually set it to -(-5)V, which made it appear as if the comparator had failed.? Arrgh, I should give up and go home.? All is OK (except inside my brain).
?
The output impedance is 1 ohm, which should not be a big problem for many users.? But it can affect signals driven into power FETs that have significant input capacitance.? I believe 1 ohm is the default output impedance of LTspice's built-in A-elements.
1 ohm is also the output impedance of the built-in opamp (the one with no supplies that requires '.lib opamp.sub'). The UniversalOpAmps' output impedance is much higher, because the switch elements that form the output have Ron=10, which also severely limits the maximum output current too, regardless what the Ilimit parameter is set to.

--
Regards,
Tony


 

Tony,
?
I believe that your UniversalComp has a bug.? The subcircuit's code includes this fragment:
if(V(out)>0,-Hys,Hys)/2
But that compares V(out) against global Ground.? That's not OK.
?
It sort of works (the end result is OK) as long as the two supply voltages straddle 0V = Ground.? But for example, if one were to use V+ = +25V and V- = +20V, then V(out) is always >0 and the if() statement above always chooses -Hys on both rising and falling edges.? And then there is no hysteresis.
?
It even fails in your test schematic just by changing V2 to -1mV (V- = +1mV).
?
Andy
?
?