Conflict in Error amp priorities in simulation vs datasheet

Hi all,

I’m simulating the LT8708 in LTspice and I’m seeing behavior that appears to contradict the datasheet “Error Amp Priorities” (Table 3). I am injecting a small current as mentioned in  Dynamical Current Limit Control of LT8708 to control current limit dynamically. I note that forcing the imon/fb pins directly is not the intention of the macromodel as stated in RE: LT8708 datasheet clarifications , which i am pretty sure im not doing. Im using this part in CCM Conduction mode, as can be seen from the simulation, RVSOFF remains high, the part is definitely switching (not in a “no switching” state).

I would like to draw your attention to the 19-20ms mark, I injected a small current in imon_inp to command higher current (that should cause the IMON_ON to take over and increase Vc to limit negative current on output side (since it has highest priority according to datasheet)

However, what i see is:

VC pin is bottomed out (~0.7 V) and appears to be “trying to decrease” (i.e., pulled low / clamped at minimum)

IMON_ON > 1.21 V

IMON_OP ~ 0 V (so < 1.209 V)

IMON_INN < 1.21 V

IMON_INP > 1.209 V

FBOUT < 1.207 V

FBIN tied high (> 1.205 V)

I think this is inconsistent with Table 3, since the highest-priority condition is:

If IMON_INN > 1.21 V OR IMON_ON > 1.21 V, then VC rises.

In my case IMON_ON is above 1.21 V, so I’d expect VC to be driven up, not bottomed out low. Lower-priority conditions (e.g. IMON_INP > 1.209 V → VC falls) shouldn’t be able to override the top-priority row unless that error amp is disabled.

However, since I’m in CCM, RVSOFF high, and switching is active, I don’t think the “4* no switching occurs → amps disabled” condition from Table 4 applies.

Questions

Is there any datasheet-described operating condition (still in CCM, RVSOFF high, switching active) where IMON_ON > 1.21 V would not cause VC to rise?

Could this simply be a known limitation/bug in the LTspice LT8708 macromodel (priority/enable logic not fully implemented)?

Also, the lt8708 model is completely broken in the latest LTSpice version, I have tested the model to respond similarly in ltspice versions from the earliest version released with the model (some 2018 version LTSpice XVII) all the way to LTSpice 24.0.12.  

PS. I didnt know that newer LTSpice versions breaks older models (LT1999 is also broken in 24.0.12 but ive substituted it with behavioural voltage sources instead)

Attached simulation files:
OCPtest.asc