Divergence at large negetive gate bias for N type transistor

[Qiusong Chen]

Hello Juan:

While simulating the ferroelect transistor, I run into divergence at large gate negetive bias. Please check the picture below. I have tried different structure, like top contact of source and drain, but get the same result, just converged around -14V. 

For the ferro transistor, I have to set a large gate bias(-40V) in order to overcome the coersive field. Can you gave me some advice to imporve it?

Best regards,

QS.C

[Juan Sanchez]

Hello,

Thank you for sending me the interesting plot.  I am glad to see your progress.   Assuming you have a contact on the back of the device, I would be concerned about the the space charge region encroaching onto it.  This may cause issues with the boundary conditions.  For example, enforcing a zero net charge (ohmic) boundary condition may be difficult enforce in the depletion region.  Please consider a combination of:

heavily doping the body contact,

making the bulk of the device much thicker

adding heavy doping near the contact.

Regards,

Juan

--
You received this message because you are subscribed to the Google Groups "DEVSIM TCAD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/0314c3b2-88db-46ea-a8a2-33c4f0321f39%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

Thanks for gave me such valuable advices.  

In this device, I have set a heavy dopping for the source and drain contact, and tried different thickness of silicon layer. But for my simulation, there is an essential step to analysis negetive drain bias. Uder the negetive drain bias, there will form a posistive bias in the body P_N junction, and large body current. So in order to avoid current from body contact, I removed the body contact. Is this make the space charge region expand to the top body boundary and then make it hard to converge?

Regards,

QS.C

On Monday, July 29, 2019 at 11:50:55 AM UTC+9, jsanchez wrote:

Hello,

Thank you for sending me the interesting plot.  I am glad to see your progress.   Assuming you have a contact on the back of the device, I would be concerned about the the space charge region encroaching onto it.  This may cause issues with the boundary conditions.  For example, enforcing a zero net charge (ohmic) boundary condition may be difficult enforce in the depletion region.  Please consider a combination of:

heavily doping the body contact,

making the bulk of the device much thicker

adding heavy doping near the contact.

Regards,

Juan

On Wed, Jul 24, 2019 at 3:48 AM Qiusong Chen <chenq...@gmail.com> wrote:

Hello Juan:

While simulating the ferroelect transistor, I run into divergence at large gate negetive bias. Please check the picture below. I have tried different structure, like top contact of source and drain, but get the same result, just converged around -14V. 

For the ferro transistor, I have to set a large gate bias(-40V) in order to overcome the coersive field. Can you gave me some advice to imporve it?

Best regards,

QS.C

--
You received this message because you are subscribed to the Google Groups "DEVSIM TCAD" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dev...@googlegroups.com.

[Juan Sanchez]

Hello,

I have not tried this type of simulation before.  So the following is speculation.  I suggest:

1. Use extended precision

2. Check the mesh for proper refinement

3. Have the body contact with only the Potential fixed and without electron or hole boundary conditions (potential equation only contact)

My intuition is that not having a body contact is making the bias "float", much like an SOI transistor.  Having some form of fixed potential on a body contact may make the simulation more likely to occur.

Another alternative would be to have an ohmic body contact, and ramp it to a large negative bias which is more negative than the drain.  This may reduce current coming from the body.

Regards,

Juan

To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/ff89edcd-5b03-45d1-87ae-ae06e33bfa80%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

In order to get a stable off-state current, all of my sumulation work have adopted the extended precision. And I have tried different meshes but cann't inmporve the results obviously. 

So there is just one left method: optimize the boundary conditon. As you advice me to set the body contact with only the Potiential fixed, I fell it is similar with the Silicon-Oxide interface, and  the inserted Air layer will make the device more realistic. So can I use a Silicon-Air interface replace the body contact, and move the body contact to the orther side of Air layer? 

Best regards,

QS.C

To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/ff89edcd-5b03-45d1-87ae-ae06e33bfa80%40googlegroups.com.

[Juan Sanchez]

Hi,

Are you using the ramp function from the Python modules?  They are supposed to reduce the bias step if a simulation fails to converge.

In addition, you may want to increase the relative_error on the solve statement.  For example, increasing from 1e-10 to 1e-8.  The relative_error and absolute_error can both be problem specific.  I usually set the absolute_error to a really high number on focus on the relative_error.  The relative_error is essentially the change in the solution variable update between iterations.

relative_error = abs(x1-x0)/(1e-10 + x1)

where x1 is the solution as a result of the iteration, and x0 is the previous value.

The boundary contact may or not help.  I do not think it would be an issue to move the body contact to the other side of the air layer.

Regards,

Juan

To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/d9fb6fc6-542d-4f7c-b433-c2b784124ab1%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

I used a modified ramp function to increase the bias, and the  minimum bias step is 0.1. 

For the  relative_error, I set the value of 10-e10, then the sumulation can converge at low negetive bias. But it became divergency while I increase the negetive gate bias to surpass the coersive field.

While I reverse the bias to positive, that make the silicon_oxide interface go into electron accmulation regime, I get a "Overflow" error. The detail is listed below. For most situations, the divergence will raise the devsim.error, and the write_devices function will export the last convergence result. But now, the exported data is a divergence picture. Please check it. 

Best regards,

QS.C

There was a floating point exception of type "Invalid, Overflow"  during LU Factorization

devsim_py3.error: DEVSIM FATAL

The above exception was the direct cause of the following exception:

Traceback (most recent call last):

    devsim.solve(type="dc", absolute_error=abs_error, relative_error=rel_error, maximum_iterations=iterations)

SystemError: <built-in method flush of _io.BufferedWriter object at 0x7f887dd16b48> returned a result with an error set

To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/d9fb6fc6-542d-4f7c-b433-c2b784124ab1%40googlegroups.com.

[Juan Sanchez]

Hi,

The failure is from a Floating Point Exception during the matrix factorization process.  DEVSIM is coded to terminate immediately after printing the failure message.  I suppose that this fatal eror could be changed to a warning, and that the simulation would stop with an error that could be treated as non convergence.  Please let me know if you think this would be helpful.

From the plot of the last converged result, the electron densities look highly non physical.

If you have any non doped areas, I would suggest using a light doping in order to possibly help convergence.  Perhaps on the order of 1e10 /cm^2.  This technique has helped in the past, before the extended precision options were added.

The generation-recombination model might be creating problems.  Perhaps you could adjust the electron and hole lifetimes, so that this model causes less trouble.

Also consider lowering the minimum bias step to 0.01 or 0.001.  10mV is half of a kT/q, and that may help prevent divergence.

These are just suggestions.  Please let me know if these help, or if you are able to come up with an even better solution.

Regards,

Juan

To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/29b404b7-4854-4dcd-935b-393ad97288c3%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

Thanks for you kindly advices. I will try them and report the results to you.

Today, I used 10 hours to verfied the difference between  ferro and non_ferro Oxide reigon. The results is that the non_ferro model can converge even increase the positive gate bias to 200V. But for the ferro model, it will get a non physical result just exceed 20V. The main difference of these two model is in the equation of Potential. Because for the ferro model, I inserted a element_model of "Polarization". So the equation is: 

 equation(device=device, region=region, name="PotentialEquation", variable_name="Potential",   edge_model = "Displacement", element_model = "Polarization", variable_update = "default"). In you example file of mos/mobility, the update method for oxide region is "log_damp". So whether the detail of the Potential equation lead to the last non physical result?

For the "Floating Point Exception",  for the ferroelectric mos, I need sweep the gate bias with a closed loop. Then I can get a hysteretic transfer curve. So I always turn the bias sweep back to the start bias while get a error message of "Convergence failure". But if the error message is "Floating Point Exception", it always divergence even I reduce the gate bias value. I think it may be resulted by the last non physical result of "Floating Point Exception". So I hope there is a method to avoide(or judge) this non physical result, then turn the gate bias back from the previous  physical result .

Best regards,

QS.C

To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/29b404b7-4854-4dcd-935b-393ad97288c3%40googlegroups.com.

[Juan Sanchez]

Hi,

"log_damp" may help with the update of the Potential variable.  It ensures that the update from the last iteration does not cause a large increase in the solution variable that may lead to divergence.  It is something like:

V(n) = (sign(update + V(n-1)) /0.0259) * log(1 + abs(update)/0.0259)

See this for more information:

https://github.com/devsim/devsim/blob/master/src/Equation/Equation.cc#L130

So if the update in potential  is many kT/q, this keeps the solution from going too far away from the previous solution to reach convergence.

If a solve fails, the simulator is supposed to restore the previous values of the solution.  It is possible that there may be a bug in DEVSIM, or that the last converged solution was not physical.  Please make sure you are restoring any previous polarization variables to the values attained in the last converged solution.

Please check what happens when you scale back the effect of the polarization?  Does this extend the range of biases you can use.

Perhaps for each bias point, you can ramp up the polarization.

For example:

set_parameter for polarization factor to half value (0.5)

solve

set_parameter for polarization factor to full value (1.0)

solve

Another guess is to make sure that all of the derivatives to the models are correct.  If you remove the derivatives for polarization, does the simulation do worse?

Regards,

Juan

To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/86c39ed7-3ad3-4fbd-8610-f752004b785b%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

While I replace the update_type with "log_damp", it actually prevent the non-physical convergence results. So this improvement keep my scripts  on running while the "Convergence failure" happenning. I think the reason for the divergence aftter a non-physical result is what you judged. I have not write scripts to restore the polarization parameters in the last converged solution. So the non_physical convergence will generate new and non-physical paramaters, then make it divergence while it sweep back. 

For the derivatives of my ferro models, I have tried manually assembling and generate the derivatives by the function "CreateElementModelDerivative2d". Both of them get the same results of divergence at high bias. While I remove the derivatives of polarization, it raise error message as follow: There was a floating point exception of type "Invalid"  during LU Back Substitution. Matrix solve failed.  

I have tried the method of scale back the polarization effect to half  of typically physical value, or even more. It acturally improve the range of biases I can use. But for my simulation work, it's better to use the value from experiments. So I prefer to get a method to improve the astringency. 

Best regards,

QS.C

   

[Juan Sanchez]

Thank you for the update. I am glad to see you are able to make
progress. It sounds like the derivatives are correct, but the
magnitude of the solution updates were causing the issue.

My idea about scaling the polarization effect, is that you might be
able to ramp the polarization effect from 50% to 100% at each bias
point. It sounds like such an approach may not be useful.

Regards,

Juan

> --
> You received this message because you are subscribed to the Google Groups "DEVSIM TCAD" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/516e4499-7df2-406f-aa86-b3156b9ab1d2%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

Sorry fo reply so late. For these two days, I have tried a lot of methods to improve the convergence bias range, including change the lifetime, ramp the polorization gradually. Although these methods expand the tolerance bias range, it hard to reach the demand to surpass the coercive field. 

During these works, I found that the convergent range of gate bias increasing with drain bias.  It sames that the reason of divergence is located around source and drain contact. Is the lower drain voltage expands the area of space charge region in the vicinity of drain contact ? 

Then, after increasing the intrinsic carrier density form 1e10 to 1e12(per. cm3),  the gate bias tolerance improved much more and reach my expectation. But what I want to simulate is organic semiconductor. It intrinsic carrier density is much less than Silicon.

 

Best regards,

QS.C

> To unsubscribe from this group and stop receiving emails from it, send an email to dev...@googlegroups.com.

[Juan Sanchez]

Hello,

I am glad to hear that you are seeing some progress.

As for the intrinsic density idea, I had used that in the past to
overcome difficulties with numerical precision. If it is not
physical, the higher doping cannot be used.

Perhaps some of these suggestions may help:

If there is an effect on the drain bias, is it possible that refining
the mesh in the lateral (between source and drain) direction may help?

Also note that you can have different convergence criteria for each
region of the device. So the relative_error criteria can be different
for the Potential in the ferroelectric and the semiconductor region.

Is it possible to run the simulations by initializing the coercive
field in one direction? Maybe then you can run a second set of
simulations with the coercive field in the opposite direction.

Are the source and drain contacts too wide, and may be interfering
somehow with getting a good solution? I would make sure they are only
contacting a heavily doped well region and that the netdoping does not
change sign. Also check that the contact nodes do not overlap a space
charge region.

Regards,

Juan

> To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/1458df61-b024-4526-8160-6d6c374bcf26%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

Thanks for gave so many advices. I will verify them one by one.

As you say that  we can set different convergence criteria for each 
region, but I can't find any clue in the manual. Can you gave me some hints!

I have tried to refine the channel near the source and drain contact,  it just limited improvement. And for the width of contact, the results show that the convergence range of gate bias increase with the source and drain contact width. I fell this is related with zero value Neumann boundary condition on the left and right  side.

Best regards,

QS.C 

> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/1458df61-b024-4526-8160-6d6c374bcf26%40googlegroups.com.

[Juan Sanchez]

On Fri, Aug 9, 2019 at 10:42 AM Qiusong Chen <chenq...@gmail.com> wrote:
>
> Hello Juan:
>

> Thanks for gave so many advices. I will verify them one by one.
>
> As you say that we can set different convergence criteria for each
> region, but I can't find any clue in the manual. Can you gave me some hints!

I am sorry I gave you incorrect information. You can only set the
convergence criteria on the solve command.

However, if you add info=True to the solve command it will return a
data structure with the error data for each region. For example in
cap2.py, you can add a solve command like this:

x=solve(type="dc", absolute_error=1.0, relative_error=1e-10,
maximum_iterations=30, info=True)
print(x)

and get this:

Iteration: 0

Device: "MyDevice" RelError: 1.63727e-16 AbsError: 5.85103e-17

Region: "MyOxRegion" RelError: 9.88350e-17 AbsError: 5.85103e-17

Equation: "PotentialEquation" RelError: 9.88350e-17 AbsError: 5.85103e-17

Region: "MySiRegion" RelError: 6.48917e-17 AbsError: 5.13942e-17

Equation: "PotentialEquation" RelError: 6.48917e-17 AbsError: 5.13942e-17

{'iterations': ({'devices': ({'absolute_error': 5.851032644837866e-17,
'name': 'MyDevice', 'regions': ({'absolute_error':
5.851032644837866e-17, 'equations': ({'absolute_error':
5.851032644837866e-17, 'name': 'PotentialEquation', 'relative_error':
9.883501087583641e-17},), 'name': 'MyOxRegion', 'relative_error':
9.883501087583641e-17}, {'absolute_error': 5.1394205664116416e-17,
'equations': ({'absolute_error': 5.1394205664116416e-17, 'name':
'PotentialEquation', 'relative_error': 6.489167381013541e-17},),
'name': 'MySiRegion', 'relative_error': 6.489167381013541e-17}),
'relative_error': 1.6372668468597183e-16},), 'iteration': 0},),
'number_of_equations': 12}

You can then decide to do extra iterations for specific regions by
doing additional solve commands.

>
> I have tried to refine the channel near the source and drain contact, it just limited improvement. And for the width of contact, the results show that the convergence range of gate bias increase with the source and drain contact width. I fell this is related with zero value Neumann boundary condition on the left and right side.

You may be able to get contacts to wrap around the side of the device.
You would need additional regions in the mesh to the left and right of
the device. You can then use a bounding box that captures surface
nodes on the top and the sides of the semiconducting region.

For example, in cap2d.py, it is possible to have a contact around the
"m1" and "m2" metal regions, by having specifying a box in the
add_2d_contact commands.

# must be air since contacts don't have any equations
add_2d_contact(mesh=device, name="bot", region="air", yl=y1, yh=y2,
xl=x1, xh=x4, material="metal")
add_2d_contact(mesh=device, name="top", region="air", yl=y3, yh=y4,
xl=x2, xh=x3, material="metal")

Regards,

Juan

> To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/7a69c921-df48-41de-9a8a-68d6e205a079%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

Sorry for relpy you so late!

For these days, I have check the textbook again, and find that the situation of divergence at low drain bias and high gate bais is in accumulation regime. But almost all the textbook just analysised the saturation process, in which the drain bias surpasses the saturate point. So it is high drain bias and low gate bias condition. I can't find any information about high gate bias condition.

For doing extra iterations for specific regions, there isn't a parameter about regions. So can you gave me some more details about it.

For the bounding box contacts, I will try it. But is there any differnece with line boundary contacts. 

Best regards,

QS.C

> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/7a69c921-df48-41de-9a8a-68d6e205a079%40googlegroups.com.

[Juan Sanchez]

Hi,

On Mon, Aug 12, 2019 at 8:37 AM Qiusong Chen <chenq...@gmail.com> wrote:
>
> Hello Juan:
>

> Sorry for relpy you so late!
>
> For these days, I have check the textbook again, and find that the situation of divergence at low drain bias and high gate bais is in accumulation regime. But almost all the textbook just analysised the saturation process, in which the drain bias surpasses the saturate point. So it is high drain bias and low gate bias condition. I can't find any information about high gate bias condition.

My intuition is:

If it is accumulation under the gate, you have an n-p-n diode between
the source in the drain. So maybe it is similar to a BJT transistor
with an open base.

If it is inversion under the gate, and a low drain bias, then you have
an n resistor between the source and the drain.

By increasing the drain bias, a depletion region is created between
the gate and the drain. Somewhere between the gate and the drain the
potential is high enough that this diode is reverse biased.

With the ferroelectric effect, are you increasing the amount of
inversion underneath the gate?

>
> For doing extra iterations for specific regions, there isn't a parameter about regions. So can you gave me some more details about it.

Attached is a function I wrote to attempt to solve to meet an error
criterion on the device.

To meet a convergence criteria for a region on a device:
region_solve(device=device, region="MySiRegion", absolute_error=1.0,
relative_error=1e-10, maximum_iterations=5)

To meet a convergence criteria for the PotentialEquation on a region
of a device:
region_solve(device=device, region="MySiRegion", absolute_error=1.0,
relative_error=1e-10, maximum_iterations=5,
equation="PotentialEquation")

It works by doing a solve with a very loose convergence criteria. It
then looks at the info returned from the solve command to check to see
if the specific region criteria is met.

>
> For the bounding box contacts, I will try it. But is there any differnece with line boundary contacts.

It will still be line boundary contacts. The bounding box helps find
the surface nodes. So you should see a line on the side and line on
the top of the device.

> To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/9854bcf4-fcd8-45a1-bdf1-3514aa4c9892%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

Thanks for send me your region_solve function. It well be very usefull for my ferroelectric FET simulation.

It's my mistake to judge as deplation regime at high gate bias. It is  inversion as you say. 

For my ferro FET, there is two part of displacement. One is normal displacement which have linear relationship with electric field. For most Ferro materials, the linear relative permittivity are almost large than 12 . The other part is polarization of ferroelectricity, and the typical magnitude of saturation polarization is about 6e-6 C/cm2 or more. So for the ferroelectric effect, it acturally increasing the amount of inversion underneath the gate. 

The FET can converge under the gate bias large to 120V without the ferro_region. The electron density and field intensity are up to 3.43011e+20/unit volume and 5.89326e+06V/cm at the insulator surface, respectively. But while replace the insulator with ferro property, it just converge under 20V. The value for them in the ferro-FET interface are 2.64195e+20/unit volume and 1.92559e+06V/cm. Is this mean that the electron density over the order of 20 is too large to converge for further increase the gate bias?

Best regards,

QS.C

> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/9854bcf4-fcd8-45a1-bdf1-3514aa4c9892%40googlegroups.com.

[Juan Sanchez]

On Wed, Aug 14, 2019 at 9:56 AM Qiusong Chen <chenq...@gmail.com> wrote:
>
> Hello Juan:
>

> Thanks for send me your region_solve function. It well be very usefull for my ferroelectric FET simulation.
>
> It's my mistake to judge as deplation regime at high gate bias. It is inversion as you say.
>
> For my ferro FET, there is two part of displacement. One is normal displacement which have linear relationship with electric field. For most Ferro materials, the linear relative permittivity are almost large than 12 . The other part is polarization of ferroelectricity, and the typical magnitude of saturation polarization is about 6e-6 C/cm2 or more. So for the ferroelectric effect, it acturally increasing the amount of inversion underneath the gate.
>
> The FET can converge under the gate bias large to 120V without the ferro_region. The electron density and field intensity are up to 3.43011e+20/unit volume and 5.89326e+06V/cm at the insulator surface, respectively. But while replace the insulator with ferro property, it just converge under 20V. The value for them in the ferro-FET interface are 2.64195e+20/unit volume and 1.92559e+06V/cm. Is this mean that the electron density over the order of 20 is too large to converge for further increase the gate bias?

I speculate that having a large number of carriers near the interface
may require refinement. I suggest trying a mesh spacing (horizontal
lines) on the order of angstroms near the interface. Check to see if
the electron density near the interface looks like an infinitely thin
charge sheet. By zooming in, you should see a gradient in density
between the interface and the bulk of the device.

In the channel between the gate and the drain, you may want to do some
refinement so that the maximum electric field across each edge does
not go above a certain magnitude (1e4, 1e5, or 1e6 V/cm).

A method like Density Gradient or MLDA can add a quantum correction so
that there not as many carriers so close to the interface. However,
if the scale of the device would support the classical result of a
high density of electrons at the interface, this may not be necessary.
Please see

https://github.com/devsim/devsim_density_gradient

for more information.

To support a channel density of 1e20, you should be using the extended
floating point precision. For the potential (poisson) equation, hole
density more then 15 orders of magnitude below electrons cannot be
resolved in standard double precision. This is less important if
there is no hole conduction. Reducing or disabling the
generation/recombination terms in the continuity equations may help to
prevent issues with holes interfering with the solution. Please try
plotting the generation and recombination terms to make sure they are
not causing problems.

I imagine the (n*p - ni^2) term in SRH recombination could be
problematic when holes are not being well resolved.

> To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/679481de-166e-4c71-a918-e904af5502fe%40googlegroups.com.

[Qiusong Chen]

Hello Juan:

Thank you for pay some many patients on this topic.

The attached figure presents the electron density near the ferro-insulator interface at high gate bias. This is based on a refined mesh, in which the spacing of channel is reduced from 1 angstrom to 0.1 angstrom. Because of such tiny spacing, the equations to be solved increased from 113321 to 338737. Although taking 10 hours to ramp the bias, It caturally expand the biase range from 20V to 25.89V with the same set of parameters, and the maximum of electron density increased to 4e+21/unit volume. 

What I used to generate the mesh is Gmsh. From the manual of devsim, there is serval tools can be used to design mesh. So which would the better tool to generate a mesh with less number of nodes while we refine the channel?

All of my work is going under the extended floating point precision. And I have try to dissable the generation/recombination terms. It can prevent the overfellow error, but have no much effect on the bias range of converge. 

Form the results of refined channel spacing, I feel the method of Density Gradient or MLDA would solve my dilemma. This may take a long peroid because it's looked a little complicated. I will report the results after that.

Best regards,

QS.C

> To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/679481de-166e-4c71-a918-e904af5502fe%40googlegroups.com.

[Juan Sanchez]

Hello,

On Fri, Aug 16, 2019 at 10:11 AM Qiusong Chen <chenq...@gmail.com> wrote:

Hello Juan:

Thank you for pay some many patients on this topic.

The attached figure presents the electron density near the ferro-insulator interface at high gate bias. This is based on a refined mesh, in which the spacing of channel is reduced from 1 angstrom to 0.1 angstrom. Because of such tiny spacing, the equations to be solved increased from 113321 to 338737. Although taking 10 hours to ramp the bias, It caturally expand the biase range from 20V to 25.89V with the same set of parameters, and the maximum of electron density increased to 4e+21/unit volume. 

 What I used to generate the mesh is Gmsh. From the manual of devsim, there is serval tools can be used to design mesh. So which would the better tool to generate a mesh with less number of nodes while we refine the channel?

For the BJT example, I used a mesh refinement procedure based on the Electric Field.

https://github.com/devsim/devsim_bjt_example

It was based on the use of a background refinement mesh with Gmsh.  The background refinement mesh is explained in the documentation:

https://github.com/devsim/devsim_bjt_example/blob/master/doc/devsim_bjt_example.pdf

In principle, a similar procedure can be explored with the MOSFET and be used to greatly decrease the number of nodes required for the simulation.

Gmsh also has the concept of refinement boxes, which I have been less successful with.

If you are using the built-in mesher with devsim, the non-terminating mesh lines can add many nodes where they are not required.  With this mesher, setting both a positive (ps) and negative (ns) spacing offers a little more control.

The spacing between two mesh lines would then be logarithmically interpolated between the ps value of one mesh line to the ns value on the adjacent line.

All of my work is going under the extended floating point precision. And I have try to dissable the generation/recombination terms. It can prevent the overfellow error, but have no much effect on the bias range of converge.

I would suggest making sure that you do not need to make adjustment of the voltages with respect to the work function differences between the contacts and the semiconductor.  Such a work function difference may adjust what charge results in the channel inversion.

I would also check the velocity saturation model is being applied to the current densities.  For your material system, are there published models?  Employing the velocity saturation may give you more physical results.  It is unclear if such a model would help convergence.

Form the results of refined channel spacing, I feel the method of Density Gradient or MLDA would solve my dilemma. This may take a long peroid because it's looked a little complicated. I will report the results after that.

It can be complicated, I would focus on getting the classical simulation to work. 

Regards,

Juan

To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/102bd71c-b38a-4128-9269-c843e5c2cb62%40googlegroups.com.

[Qiusong Chen]

Hi! Juan:

Thanks for gave me so many valueable advices.

The physics model I used is based on the sample file in "examples\mobility".  It adopt the Omic contact from the simple_physics. Then I add the mobility saturation model form Klaassen and mos_physics packages. The output curves based on these models acturally present the typical type of mobility saturation. With out these models, the convergence range of gate bias reduce very much. 

Besides, I have reduce the mobility form 400 to 1, which is more suitable for organic semiconductors. This reduction of mobility also improve the convergence range, but can't fill my demand for overcoming the coersive field.

So, it seamed that there are just two way to improve my simulation: Density Gradient and mesh refine. As I also prefer to realise a classical simulation results, I will try the mesh refine first.

Best regards,

QS.C

Hello,

To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/102bd71c-b38a-4128-9269-c843e5c2cb62%40googlegroups.com.

[Juan Sanchez]

Hello,

It sounds like you have been thorough in what models you have selected for your simulations.  I spent a little time this weekend working on the refinement strategy I was thinking of for mos simulation.

I managed to put together a 2D mesh refinement example for a gmsh created structure.  This picture is of the original mesh and the final mesh following 4 refinement steps.

The example scripts are located here:

https://github.com/devsim/devsim_misc/tree/master/refinement

Please see:

run.sh

script to generate the result files.

The refinement is done at vg=5, vd=5, vs=0, vb=0.  The refinements are based on:

1. The logarithmic differences of the electron densities for each edge in the semiconductor.  

2. The difference in potential across each semiconductor edge.

3. The oxide refinement uses a background field to maintain the original mesh, but still results in some refinement.

The refinement criteria can be adjusted in:

refinement2.get_oxide_model_values

refinement2.get_silicon_model_values

The model is evaluated for each edge.  The model values refer to:

0: no refinement for this edge

1: refine nodes on edge by setting a mesh characteristic length of 0.5*EdgeLength

Regards,

Juan

To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/e92b23f4-8a31-4792-b9dd-3e25342a9ee0%40googlegroups.com.

[Qiusong Chen]

Hello Juan: 

Thanks for your patience focusing on this topic. 

In order to avoid additional error introduced by my mistake, I use a modified gmsh file to test the refine effect. Because what I,m care about is the affection of polarization of ferroelectric layer  on mos current, I expand the channel length. The results is listed  below. 

The table listed the divergence point while ramping the gate bias to 100V. In most case, it's failed on the error of "overflow". 

Maybe, I should test the unmodified gmsh file in you examples. I will test it and report to you.

Best regards,

QS.C

Table： divergence point while ramping the gate bias to 100V

Auto refine: mincl=1e-8

Drain Voltage	0	1st	2nd	3rd
-2	3.63	2.04
-5	0.47	0.17	0
-10	0.14	0
0.2	3.6	100	21.12	3.66
2	2.3	3.30	7.92	2.56
5	0	0.31

 

Auto refine: mincl=1e-9

Drain Voltage	0	1st	2nd	3rd
2	2.35	0.156	2.07	2.10
10	0	0	0	0.03

To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/e92b23f4-8a31-4792-b9dd-3e25342a9ee0%40googlegroups.com.

[Juan Sanchez]

Hi,

If I understand the table correctly, each column is a different number of refinements?

Can you please post the "overflow" message?  It would be interesting to know if the message is from the matrix factorization, or from the model evaluation.  If it is the model evaluation, it may be possible to change the models functions to prevent overflow.

There is a new prerelease of devsim, which makes it possible to catch more floating point errors by throwing an exception and not terminating the program:

https://github.com/devsim/devsim/releases/tag/v1.4.2%2Brc1

I have created a 2nd refinement strategy here:

https://github.com/devsim/devsim_misc/blob/master/refinement/mos2d_refine2.py

The run script is:

https://github.com/devsim/devsim_misc/blob/master/refinement/run2.sh

You can directly compare mos2d_refine2.py with mos2d_refine.py to see changes required for the new approach.

Refinement information is collected over a range of biases.  A callback function collects the refinement information for each bias point in the ramp.  These bias dependent refinements are merged before writing out the background mesh.

Perhaps a strategy of collecting refinement over a range of bias may help.  A background mesh can then be written at the last successful bias point to start over with a refined mesh.  You may also decide to change the refinement criteria for semiconductor and insulator here:

https://github.com/devsim/devsim_misc/blob/master/refinement/mos2d_refine2.py#L78

https://github.com/devsim/devsim_misc/blob/master/refinement/mos2d_refine2.py#L94

Regards,

Juan

To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/139b7200-6b2a-4263-bad2-8c83054eb16b%40googlegroups.com.

[Qiusong Chen]

Hi Juan:

I have to tell you what a serious mistake I have made. I forgot to assemble the current equation to gate contact in all of auto-refine script. After inserting these current equations, the convergence range of gate bias optimised much better. So I have to retest all of these script in the past week. I believe it will be a nice result.

Regards,

QS.C

[Qiusong Chen]

Hello Juan:

By fix the missing equation of gate contact, your refine script simulate the ferro-mos device fluently.  Please check the image below. Without the current equation on gate contact,  it always report the error of "overflow". I think this is come out from suspension boundary conditions of Electrons and Holes in gate silicon region.

Thanks for the help and guaidance from you.  Now, I can carry out the next step. Hope you can support me as before!

Best wishes,

QS.C

[Juan Sanchez]

Hello,

Congratulations on your successful simulation.  I am glad to see that things are starting to work with your device structure.

What is the node count for the mesh? 

Regards,

Juan

--

You received this message because you are subscribed to the Google Groups "DEVSIM TCAD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devsim+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/devsim/f2c696f8-7fdc-4d0e-8371-21402dde5232%40googlegroups.com.