INA500: TINA_TI simulated TI Op Amp and TI Diff Amp's Vsat_low goes below lower supply rail

Hi Gerasimos - Do we know when a corrected model would be available?

Hey Jacob,

I'm not sure on the timeline here. I will sync with the other teams and let you know if they have a timeline for this. In the meantime I have this entered into our tracking system to make sure this gets corrected.

Best,
Gerasimos

Hi Peter & Jacob, 

What was the broader problem being solved via the simulation?
In the meantime, where you able to arrive at a solution or do you need us to help with evaluation of the INA500 & INA132 in a different way? 

All the best,
Carolina

Caroline,
The INA500A is used in many places in my design. In most circuit use cases, the signal output is kept ~100mV above the lower rail, so no big deal.
However, in the particular use case it does matter. I am simulating a INA500A pair used as an offset-corrector and full-wave-rectifier for a hall sensor (0A gives 2.5Vout).

In this FWR app, a pair of INA500A's are summed, where one is sending a half-wave and one is at Sat_low, depending on if the signal is > or < 2.5V. The two outputs are resistively summed for the output signal. This avoids the classic diode approach and its Vfwd limitations on output range and resistor matching hassles. The sat low value has some small effect (a few percent) on my full-scale signal. Generally, I do not need high fidelity down near zero, but it is that sat low is skewing the results due to the summing node action. I have also noticed that the Vsat low can have abrupt ~10mV steps with small load changes. This also seems unlike what I would be expected from an actual part.

My present work around is simply to test one direction at a time and use a simple 7mV source to replicate the other INA500A that nominally expected Vsat at that time.
(not -7mV, i.e., below Vee.) 

My work around will do fine for the next few weeks, but I do have a top-tier customer-facing CDR in about a month.
I would rather not have to explain my patch to the customer.

--Peter

Thank you for addressing these two (three) issues.
I will check it out ASAP.

Also, thank you for fixing the "1.080108MEG" typo (issue #3).


Till then, just a note:
This latest clamp and peaking fix, attached above, seems based on the Rev A model from Bali Ravi in 2019.
Shouldn't these both the clamp and gain peaking fixes be applied onto the latest Rev B 2024 version?

Regarding Rev A vs Rev B. I much prefer Rev A in that the net list follows a logical progression of circuit netlist flow, i.e., parts of a like net connection are grouped sequentially in the code. The Rev B, by contrast, seems to have been ran through some code-formatter that alphabetized the net components, thus jumbling the logical readability.

Does Rev B have any real improvements, or is Rev B was just a formatting "update"? 
I would be great if any substantive changes in the Rev B (including the fixes) were made into a style honoring the Rev A's netlist-readable-first component listing.

--Peter

Hey Peter,

So, that was a copy-paste error on my side. The core amplifier is based upon the TLV9041 amplifier, with some added resistors on die. The original model for the TLV9041 was used for the creation of the INA500 model. Consequently, this is why the swing outside the rail error is common to the INA500 and TLV9042 model. So this is a little bit of a peek behind Oz's curtain, luckily there's no phony wizard, just some innocuous IP reuse.

Rev B had an improvement to ease convergence in PSpice for TI, and I believe had another convergence aid added in to help convergence in more complex schematics. Even though this was a fix for PSpice for TI, we rolled out the change across all models for the purpose of standardization. There was no negative impact on the TINA-TI model, and we didn't want someone to copy-paste the netlist from TINA-TI into PSpice for TI or any other Cadence simulator and now start to have convergence problems.

Also correct that the netlist was run through a formatter that does move the components around, but prevents any repeat component names when converting a hierarchical schematic to a single netlist, and automatically appends the header to the netlist. It is a convenience for those generating the model, but does make the netlist a fair bit less legible.

I did try to make the same netlist fix in PSpice for TI, but it seemed to cause a convergence error. This will require some more debugging and poking around the model, but surely there is an answer somewhere.

Best,
Gerasimos