Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MOSFET model missing parasitic diode #243

Closed
xrvo opened this issue Aug 15, 2018 · 19 comments
Closed

MOSFET model missing parasitic diode #243

xrvo opened this issue Aug 15, 2018 · 19 comments

Comments

@xrvo
Copy link

xrvo commented Aug 15, 2018

The MOSFET model has behaves as though it doesn't have a body diode - in effect allowing the MOSFET to block current in both directions between Source and Drain. All real MOSFETs have a parasitic diode and can only block current in one direction (not both).

Here is an example (from https://www.falstad.com/circuit/circuitjs.html):
image

I tested this circuit in LTspice and the MOSFETs did behave as though they have a parasitic diode - that is they didn't have this issue.

As a side note: the default Beta parameter is way too low for real world transistors. It should be 1000x higher, or around 80, not 80m.

@pfalstad
Copy link
Collaborator

Someone filed an issue about that a while ago, but it got accidentally closed. Working on it.

This website suggests 100 for a typical beta value: https://electronics.stackexchange.com/questions/270393/industry-values-for-beta-%CE%B2-in-bjt-current-amplification

@xrvo
Copy link
Author

xrvo commented Aug 16, 2018

Those beta values are for BJTs :)

I found beta=80 gave me Rds-on values that are in line with real MOSFETs, but you may find a better source for this. For instance, a beta of 80 gives me Rds=8 mOhm (@ I=1A, Vds=±3.1V).

Typical ranges for Rds are hard to define, since they vary from 0.4 mOhm to over 50 Ohms, but ranges in 3 - 15 mOhm are very commonplace for popular MOSFETs.

@pfalstad
Copy link
Collaborator

Arrghh.. Ok I'll make it 80.

@pfalstad
Copy link
Collaborator

Actually now that I think of it, I did base the default value of beta on a real device. 80 seems way too high.

Take this one for example: http://eelabs.faculty.unlv.edu/docs/datasheets/ZVP3306a.pdf

In the simulator, using a p-MOSFET with beta of 27m and a threshold of -2.5 V gives me values that seem to match the graphs pretty well (looking at the saturation characteristics on page 2). I don't know how common this device is, but they're still making it at least. What device would be more typical?

@xrvo
Copy link
Author

xrvo commented Aug 17, 2018

It would be hard to give you an unbiased answer to your question, because I can just choose a datasheet from an outlier in order to prove my point, such as the IPT004N03L which has an Rds-on=0.4mOhm which would call for beta=700.

Instead, here's my logic:

  • There are signal MOSFETs and power MOSFETs
    • The tradeoff between real-world signal and power MOSFETs are the gate and input capacitances, which govern how quickly they can switch. Thus signal MOSFETs have higher Rds-on (lower betas) but switch faster, and power MOSFETs have lower Rds-on (higher betas) but switch slower.
    • Real-world signal MOSFETs have high Rds-on, thus low betas around what you suggest 27m.
    • Real-world power MOSFETs have low Rds-on, thus high betas or around 80
  • We have to choose between a power MOSFET and signal MOSFET as the default. Here are two use cases:
    • Signal MOSFET: I'm looking to simulate a high-frequency circuit. Currently, MOSFET capacitances are not modeled in circuitjs so the difference between signal and power MOSFETs doesn't matter. I also don't realistically care about the beta because switching big currents quickly in real circuits is hard to do due to parasitic capacitances and inductances.
    • Power MOSFET: I'm looking to simulate a high-current DC circuit. I care about low Rds-on (high beta) and don't care about capacitances. I'm looking at using a real world MOSFET with a low Rds-on, which gives us a beta around 80
  • Between the two cases above, the high frequency (signal MOSFET) case doesn't care about the beta, and the high-current (power MOSFET) cares to make sure it's high. Thus, it's better to bias the default beta towards a power MOSFET and set it to around 80.

Anyway, here's an example of a popular and fairly inexpensive power MOSFET: CSD13202Q2 (Rds-on: 7.5 mOhm)
Or a popular through-hole MOSFET: IRF3205 (Rds-on: 8 mOhm)

@pfalstad
Copy link
Collaborator

Makes sense. But here's an example of a circuit that doesn't work with a high-beta MOSFET: http://tinyurl.com/ycco5knb Not sure if there are more, that was just one of the first examples I tried. Most of the sample circuits make more sense with a signal MOSFET. They would work with a power MOSFET but would have unrealistically high currents.

I could go either way on this.. But I was planning to convert all the examples to high-beta MOSFETs, and I'm definitely not going to do that now. It does seem to make more sense to have user-created MOSFETs be the same type as all the MOSFETs in the examples.

@xrvo
Copy link
Author

xrvo commented Aug 17, 2018

I had a look at your example. When you change the MOSFET gain, it looks like the reciprocal signal disappears, but it's actually still there at a lower amplitude. Try changing the gains again and reset your graph scales or reset the whole simulation.

Another example, the CMOS crystal oscillator, works better with high gain MOSFETs.

The ones that get a bit weird are the first ones: n-MOSFET and p-MOSFET because the currents get higher than what you would see in a breadboard circuit.

@pfalstad
Copy link
Collaborator

Yes, the reciprocal signal is there but it's measured in microvolts.

The CMOS crystal oscillator is better? It's using 200 W of power...

What if we keep the default but remember the setting of beta so that when you create a new MOSFET, it uses the same beta as the last one you created? And we could add some documentation showing typical values for power mosfets vs. signal.

@xrvo
Copy link
Author

xrvo commented Aug 17, 2018

Whoops, yes it does use quite a bit of power! haha Looks like there would be some unintended consequences from to this change.

Yes, your first suggestion would be great. Would all components behave this way, or just the MOSFETs? I notice myself changing the diode Vf a bit as well if I'm using Schottky diodes so maybe some of the other components may benefit as well. Or do it across the board for consistency? Your call.

The alternative is eventually you expand your component selection to have power MOSFETs / signal MOSFETs, as well as diodes / Schottky diodes. But this would take away from the simplicity of the component selection - which is a nice quality at the moment compared to some more detailed simulators with huge parts catalogs.

@pfalstad
Copy link
Collaborator

Yes we could do that for BJTs and diodes as well. We already do something similar for logic gates, remembering the last output voltage and schmitt trigger setting.

I did want to keep the component menu simple. Also we'd need to have different keyboard shortcuts for both n and p versions of power mosfets, and all the good options are taken.

@sharpie7 sharpie7 reopened this Aug 26, 2018
@sharpie7
Copy link
Owner

sharpie7 commented Aug 26, 2018

If we go down this route at least we should add any parameters (eg mostfet beta) that get cloned from previous values to the hover information panel so that they are visible on the component. Maybe we should highlight non-default values in that panel too.

@sharpie7
Copy link
Owner

Though, on reflection my preference would be that if a user clones a component using the duplicate option from the menu then it clones the values, but if they place a new component from the component menu it has the default values. This seems to me to have much lower risk of nasty surprises.

@herrmanthegerman
Copy link

What about adding a drop-down menu to the "edit component" menu offering preselected beta values, e.g., minimally that would be

  • small signal mosfet (beta = 27m)
  • power mosfet (beta = 80)
  • manual
    When the user selects "manual", the existing "beta" field gets enabled an the user can enter a custom value.

Further, the preselected beta values could be different for n-channel and p-channel mosfet.

I struggled to simulate a simple circuit that ran 2 Amps through a mosfet until I changed beta. I think that offering different beta values upfront points the user that this property might be crucial in getting a correct result.

NB: now that the discussion has shifted from discussing parasitic diode, what about adapting the subject?

@Felthry
Copy link

Felthry commented Nov 1, 2018

What exactly does beta mean in the context of FETs, anyway? I don't know that I've ever seen the symbol used for a FET.

Perhaps there should be a manual that explains the different parameters of every component? I could provide the copy for most of that. Actually, I'm going to make this a separate feature request when I get back from class in a few hours.

@pfalstad
Copy link
Collaborator

pfalstad commented Nov 1, 2018

@E3V3A
Copy link

E3V3A commented Feb 26, 2019

Yeah, as I'm trying to understand the MOSFET behavior better I must agree with @Felthry that perhaps we should not use Beta values at all for describing MOSFETs, but rather Rds_on or something else that you guys would know far better than me. What I do know, is that in most Datasheets I've looked at in the last few days, there is not a single mention of any "Betas", so it's continued usage for these parts will undoubtedly be a constant source of confusion.

@pfalstad
Copy link
Collaborator

Rds_on varies with gate voltage so it's not a great parameter to use internally. We could have a worksheet to calculate beta given Rds_on and Vgs.

@E3V3A
Copy link

E3V3A commented Feb 26, 2019

https://cleanroom.byu.edu/MOSFET_calc
(But I don't know what equations and assumptions they make there.)

@pfalstad
Copy link
Collaborator

Closing this since the original issue is fixed and the discussion it morphed into is also apparently resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants