# Proper way to demonstrate reverse recovery time of a diode using SPICE simulation

After encountering a nice example from an answer of this question, I wanted to simulate the same circuit in LTspice to compare the reverse recovery times of two diodes 1N4148 and 1N4007 by a 5V 100kHz square wave source:

If I don't verify/set Trise and Tfall for the squarewave i.e if I use the default settings, I get the following plots for diode currents I(R1) and I(R2):

The above current plots doesn't tell me anything.

But if I set Trise and Tfall as 0.00000001 which is the 1/1000 of the square wave period, I get the following plots for the diode currents:

As you can see the fast recovery time of 1N4148 can be seen very explicitly.

What is the proper way to check reverse recovery time in LTspice/SPICE? I mean what should be the rise and fall times relative to the squarewave period?

And how is that measured in real(the one we see in data-sheets)?

• Well the rise time shouldn't be longer than the recovery time.
– user16324
Commented Mar 26, 2018 at 20:10
• Woow great point. I think this means then one better check this reverse recovery time from the data-sheet and then simulate(?). The default rise/fall settings of LTspice are not revealing this recovery time. Commented Mar 26, 2018 at 20:13
• @user16307 If by "default" settings for rise/fall times you mean that you set them to zero, then you're in for a surprise, as LTspice sets them at 10% of Ton. For a 5us Ton, they will be 0.5u, which means the total pulse (50%rise->50%fall) will be Ton+10%Ton=5.5us. The solution is to impose values for Trise/Tfall, but there's no need to exaggerate. For example, a 0.1% of Tperiod will suffice in most of the cases. Here, Tperiod=10u, Ton=5u => Trise=Tfall=10n (your values, congratulations), and also account for 50%rise->50%fall: Ton=Ton-Trise=5u-10n=4.99u. Commented Mar 27, 2018 at 7:35
• @aconcernedcitizen I found your comment very helpful. Can you write it as an answer so I can select it? Commented Mar 30, 2018 at 16:39

In LTspice, setting the rise and fall times of a pulse source to zero will not mean that they will be null, as that will be both a physical impossibility, and a machine problem -- a low and a high cannot coexist in the same time. So, LTspice circumvents this by setting them to 10% of the Ton.

In your case, you have Tperiod=10u and Ton=5u, which means that Tfall/Trise will be 0.1*Ton=0.5u. This also means that the total pulse width, calculated from the time it reaches 50% of the rising time, until 50% of the falling time, gets to be Ton+(Trise+Tfall)/2=5u+(0.5u+0.5u)/2=5.5u.

The solution is to impose values for Trise/Tfall, but in a sensible way. For example, a 0.1% or Tperiod will, in most cases, suffice, while also not be a burden to the solver, by creating unnecessary steep transients that may cause slow downs around those points, or even failures in the form of timestep too small. Adapting this to your requirements: 0.1%*Tperiod=10u/1000=10n (the values you have chosen, congratulations). Now, to account for the total pulse width (considering Trise=Tfall): Ton=Ton-Trise=5u-10n=4.99u. If, for example, Trise=2*Tfall=20n, then the pulse width would have been 5u-(10n+30n)/2=4.98u.

Of course, nobody says you can't set Trise=Tfall=1ps, or less. LTspice will comply, but, as mentioned, you may regret it.

One last thing to mention: LTspice uses a modified nodal analysis for its matrix solver, so that means it's working with conductances (1/R), rather than resistances (R), which also means that voltage sources, with their default (machine) zero resistance, may cause problems (as mentioned by the manual, see the E-sources, bottom). LTspice's solution for this is the parasitics, Rser and/or Cpar, but Rser is the one that matters. When set, it will be converted, internally, into a current source, thus having much higher chances of convergence. For your case, it's unlikely this will be needed, but it's not a bad thing to remember. Also, since you manually inserted series resistances, this will, most probably, not be necessary.

So, with these in mind, you can test your diodes as you see fit. You may want to impose a tight(er) timestep, while also only using a period, or two (no need for more). .opt plotwinsize=0 may also be of a help in studying short periods of time with the waveform viewer.

• I wanted to add this, but forgot: there may be times when very tight rise/fall times may be needed, so specifying Rser together with Cpar may help by smoothing out a bit the transient in a solver-friendly manner. For example, say you need 100ps and don't want to have more than 0.1 Ohms output resistance. Then Rser=0.1 and Cpar set it to about half, or a third, or less (but not very much less) the time constant: 100p/(0.1*3)=333p. Commented Mar 30, 2018 at 19:50

A common test circuit for measuring the reverse recovery times of diodes is shown here:

If you want to compare two different diodes, do not put them both in the same circuit. Put in a second power supply, pulse generator, etc. and only have the oscilloscope common to both circuits (each test circuit gets its own channel/trace). You may also have to adjust the supply voltages depending on the diode. The one below is designed mainly for higher power didoes, not the 1N4148.

This is usually what is used to obtain the values included in the diode datasheets.

• Interesting but that 25V DC supply is in parallel to the pulse generator through resistors. I didn't get the use of that DC source. Commented Mar 26, 2018 at 20:19
• The polarity of the pulse generator is opposite that of the DC supply. The DC supply is there to pre-bias the diode in the forward direction. The pulse generator puts it in reverse-bias, with a lower voltage. Commented Mar 26, 2018 at 20:25
• Interesting, where is that diagram from? Commented Mar 26, 2018 at 20:26
• That particular image is from avtechpulse.com/appnote/av1010 . The circuit can be found all over the place though. Commented Mar 26, 2018 at 21:38