Hello all-

I'm trying to use the ISL70444SEH model and a basic circuit to confirm that the model works correctly before moving on to anything more complicated. I'm having issues with the simulation. The sim fails to run and I get the error "Time step to small, etc....".

Any help is appreciated.

Here are the files

You forgot the .TRAN statement, and your .INC command references the wrong filename.? Those are minor but not insignificant omissions.? I get suspicious whenever it is obvious that you did not simulate using the files you uploaded.

There were other error messages, referring to the diode .MODEL statements.? I think the cause of those is the "LEVEL=2" in each of those .MODEL statements.? I don't know what those are supposed to do, but I think LTspice probably does not know what to do with the "LEVEL=2" and it gets confused by what comes after.? Removing "LEVEL=2" does not fix the "time step too small" error.

"Time step too small" errors are among the more troublesome ones to afflict SPICE users, worldwide.? You should get some help by reading the "FAQ" file in our group's archives:

/g/LTspice/files/z_yahoo/FAQ/faq_17-2.txt

Read it and find the section about "time step too small" errors.? It has several things you can try.? None of them are guaranteed.? If there was a foolproof solution to "time step too small" errors, we wouldn't have them anymore.

In your circuit, I found that ".options cshunt=1e-14" seemed to tame it.? YMMV ("your mileage may vary" -- your results might differ from mine).

Andy

This happens sometimes where there are signals with fast edges (aka zero rise or fall times), discontinuities or indeterminate derivatives. An indeterminate derivative happens at a corner. See if you can simplify the simulation by doing an .op and stepping a parameter.

开云体育

On 05/07/2023 23:57, mliccione89@... wrote:

I'm trying to use the ISL70444SEH model and a basic circuit to confirm that the model works correctly before moving on to anything more complicated. I'm having issues with the simulation. The sim fails to run and I get the error "Time step to small, etc....".

Any help is appreciated.

It helps if you upload a schematic that actually runs. You have a ".lib ISL70444SEH.lib" directive in the schematic, but the model file you uploaded is "ISL70444SEH.cir" and there are no analysis directives.. However, when I change the .lib directive to match the file name and add a .tran directive, I don't get initially "Time step to small, etc....". Instead, I get "Analysis failed: Iteration limit reached", and there are a bunch of errors in the ErrorLog, concerning the diode models. I am running LTspice 17.1.9, you may have a different version.

I made minor changes to the model file and added ".options cshunt 1e-14", and the analysis now runs fine. I have uploaded a working schematic to Files > Temp.

You should note that although the datasheet says "unity gain stable", the circuit is barely stable with 8dB peaking at unity gain. I added a bit of compensation to help a bit with that.

Thanks Tony et al. I did totally flub the initial file upload. I've moved on to using this opamp for my intended purpose, as a TIA that can pass pulses from a photodetector. I'm not getting what I expect to see at the output of the TIA. Perhaps this opamp is not fast enough?

Here are the files

mliccione89 wrote, "I'm not getting what I expect to see at the output of the TIA."

What did you expect to see?

It looks to me like you are sending very narrow (~ 2 ns wide) pulses into the TIA.? How much bandwidth is required to pass a 1 ns risetime?? The rule-of-thumb is at least 350 MHz.? How much bandwidth does the ISL70444SEH have?? Its datasheet claims that its GBP is 19 MHz typical -- which is much less than what you would need to maintain a reasonable likeness of your pulses with their 1 ns rise and fall times.? Perhaps it is acceptable to live with the lost rise and fall times, but I think the pulse widths are just too narrow to expect them to be faithfully reproduced by such a "slow" op-amp.

There are faster op-amps.? But it gets challenging to work with extremely fast op-amps.

Consider starting slow in your simulation (much wider pulsewidths at I1 and I2), and then watch at what point the output waveform can't keep up.

Andy

FYI -

Op-amp GBP or bandwidth is only one consideration.

Also there are the effects of the external components, such as the feedback capacitor, the output load, gain-peaking, etc..

Also slew rate.? The ISL70444SEH has a slew rate spec of 60 V/us, so you must count on it taking 25 ns just to move the output by 1.5 V, which has nothing to do with the amp's bandwidth.? It is a nonlinear phenomenon.

Andy

Hi Andy. Thank you for your feedback. When I mentioned that I was not seeing what I expected at the output of the TIA, I should have been more precise. I am not sure I understand why there is so much undershoot.

Here are the latest files

That's not a huge undershoot, not compared to the pulse itself.? The undershoot is -125 mV and it lasts for less than 10 ns.? If you made the I1 pulsewidth wide enough so that the op-amp's output can follow it, you'll see that the normal output pulse plateaus at around +1.5 V.? So the undershoot peak amplitude is only about 8%, and its pulsewidth is quite narrow.? Change I1's pulsewidth to 1 us or more to see the full output pulse amplitude.

Where does the undershoot come from?? The extremely fast leading edge of I1 flows from the output pin through C9.? The op-amp can't respond in time, so the current through C9 drags the output pin down by 125 mV briefly.

Andy

Thank you for the explanation. Much appreciated.

mliddione89 wrote, "I see that you changed the .MODEL statements for "DESD" and "DN1". Would you mind explaining what those are, and why you changed the statements?"

Yes.? In an earlier reply (#147193), I wrote that there were two lines containing "LEVEL=2" that were causing LTspice errors.

When used as a .MODEL parameter, the LEVEL parameter can be used in SOME device models in SPICE, mostly with MOSFETs, and (rarely?) might be used with BJTs, and the LTspice-specific voltage-controlled switch models.? It's a way of having fundamentally different models (different component equations) inside SPICE, without using a new first letter for the component's name.

The lines that had LEVEL were these two diode model definitions:

I don't think I saw LEVEL with diode models before.? LTspice apparently doesn't like it either; but I guess there is a SPICE program somewhere out there that can use LEVEL with diodes, and your ISL70444SEH model may have been written with that SPICE program in mind.? The model says it is for PSpice but I don't believe PSpice uses diode model LEVELs so maybe it's from somewhere else.? I think HSPICE has diode LEVELs but it's been years since I used it.? When LTspice sees them, it gives us these errors:


So I deleted the "Level=2" parameter to see what would happen.? That makes the two diode types into regular SPICE diode models like you see everywhere else.? It does mean that whatever the "Level=2" was supposed to convey, is probably lost.? But I don't know what that would have been.? I thought it was better to make the model usable, than to junk it and tell you "you're out of luck."? Admittedly there is some risk, but I believe that risk is minimal.

Regards,
Andy

Thanks so much for the detailed explanation!

I actually ended up switching to the LTC6268-10 and found that I'm able to actually get some semblance of a response from that opamp at my smallest pulse width. I am not trying to exactly duplicate the pulse; I am trying to detect that there is a pulse at all so I am thinking (hoping) that this is a sufficient response.

Here's the circuit?if you are interested in continuing to follow this saga. There shouldn't be any other files required except for the LTSpice circuit itself.

When you have a command such as this on a schematic:

? ??.options cshunt=1e-14
? ? + noopiter
it is essential to have all three lines in the same SPICE Directive.? But in the schematic you uploaded, the second and third lines and the first line are in separate SPICE Directives.? You can't control how the lines are ordered in the SPICE Netlist (well, actually you can, but it is not how you'd expect, it depends on the order they were added to the schematic).? As a result, the "+ noopiter" and "+ gminsteps=0" come after and add to your ".tran" line, and that doesn't work.

That causes an error, and your simulation can't be run.

Remedy: put the "+ noopiter" and "+ gminsteps=0" lines in the ".options" line's SPICE Directive.

Andy

FYI -

The LTC6268-10's input voltage range just reaches the V- supply pin but does not go below it even a little.? So it's taking a risk, having the negative supply pin grounded, with the +IN pin also grounded.? In fact the voltage on the -IN pin reaches -0.66 V in the simulation, which is below the allowed input voltage range.

Andy

This schematic does not run, as uploaded. Andy explained why (.options lines split up). The "+" character at the start of a line, tells LTspice to append this line to the previous one. When these are not within the same directive block, they will be not be associated with the intended line, and be appended to some other line that they are not supposed to be associated with.

The .options... were put in the the original fixed schematic because of issues with the opamp model used in that schematic. They should not be used as a default in others, where it isn't necessary.

You also used the "startup" option in the .TRAN directive, but there seems to be no reason why it would be needed. Only use these things where necessary and for good reason. Here, there isn't one.

Next, you have defined a -2.5V supply (Vn), but used not it. Is it, by any chance, intended to be the opamp's negative supply? If so, you can't use +5V for the positive supply, because the datasheet says in the absolute maximum ratings section:

Supply Voltage V+ to V– ...........................................5.5V

With the opamp's V- supply pin grounded, the pulsed source the input voltage falls below the inverting input's minimum level and the ESD protection diodes are forced into conduction.

I reconfigured the circuit to use ±2.5V supplies, including biassing the photodetector from -2.5V.

The photodetector model is producing 5mA pulses. You feedback resistor is 1k, so potentially the output should reach 5V, which is, of course, is beyond the supply rail. Therefore, it can't. So, assuming you need the output voltage to be a linear function of the input current, we need to reduce the feedback resistor, so the opamp isn't clipping - I reduced it to 390 for a little margin. But...

The LTC6268-10 opamp is only stable for closed loop gains in excess of 10x. That's what the "-10" suffix means. I would refer you to page 13 of the datasheet for some stability considerations. In summary, at high frequencies, the feedback gain is approximately Cin/Cfb. Your photodetector seems to have a junction capacitance of 2p, requiring a feedback capacitor of <200f. This is probably lower than the internal capacitance of the opamp. I don't know which PD you have in mind. I checked out some very high speed InGaAs PDs (infra-red for LIDAR etc) from Marktech of the sort of speed (2Gbps) you seem to be looking for. They seem to have a higher junction capacitance than 2p - more like 12p...

Anyway, without treatment this TIA oscillates. It will take a quite a bit of tweaking to make it properly stable. With your original arrangement, it appears not to oscillate, but that is misleading because most of the time it is saturated on the rails.

What exactly is your requirement? Just picking the fastest opamp you can find isn't necessarily the right approach. FYI, substituting an LTC6268 (unity gain stable version) made the TIA stable without further tweaking, but it still had some ringing - changing the feedback capacitor to 5p6 seemed to be about the optimum, but on a real circuit that might not quite be so. It isn't, of course, as fast.

开云体育

On 14/07/2023 12:17, Tony Casey wrote:

Next, you have defined a -2.5V supply (Vn), but used it.

Next, you have defined a -2.5V supply (Vn), but *not* used it.

开云体育

On 14/07/2023 12:17, Tony Casey wrote:

changing the feedback resistor to 5p6 seemed to be about the optimum

...changing the feedback *capacitor* to 5p6 seemed to be about the optimum

It is possible (but maybe unlikely) that 'mliccione89' does not need this TIA to be linear.? Maybe all she/he wants to do, is to detect and observe pulses, in which case it might be OK that it is nonlinear.? If so,?then maybe it is OK to use the power supply voltages and the closed-loop gain that were used in the original schematic, where the amp is driven into saturation, and where the fact that it would oscillate doesn't matter when it's in saturation.? But if that were the case, I also want to suggest that the simulation might not be as accurate as you desire.? And maybe it's a waste of a good op-amp that is not being used as an op-amp.

Andy

Hi guys-

Thanks a ton for your continued support. Tony posed the question about what my requirements really are. Here are the most relevant:

• Overall, my goal is to have enough of a response so that I can detect when a pulse is missing, potentially by way of a comparator down the line. The pulse widths can range between 0.7ns wide and ~4ns wide and occur about every 15us.
• In my system I will have access to +/-5V supplies. I'm going to go back to looking for an op amp that can utilize these supplies.
• The photodetector will be biased at -5V to minimize junction capacitance.

A quick note, I do have a real photodetector identified with the properties I've entered into the simulation. You are correct to assume that it's an InGaAs detector.

As far as your comment about picking the fastest opamp and hoping for the best, I guess I am having a hard time grasping what the right approach is to selecting an opamp for this case. I hope the above helps.

Handling a pulse that is only 0.7 ns wide is certainly a challenge.? For SPICE simulations, if you were to use 1 ns rise and fall times, and if you say that the desired pulsewidth is 0.7 ns at the pulse's 50% point (which is likely how it is specified), then you need to subtract 1 ns from the intended pulsewidth, to come up with the "on" time ("Ton") of your SPICE current pulse source.? Obviously that doesn't work for a 0.7 ns pulsewidth!? So you must decrease the Trise and Tfall times of your PULSE source in SPICE.? For example: