Xyce/ADMS limexp inconsistancy

[ngw]

Dear Xyce team and community,

I have recently ported a compact model I originally developed in hspice into Xyce via Xyce/ADMS; however, I am experiencing convergence issues when forward biasing the various device p-n junctions. I believe this has to do with different way that hspice and Xyce handle the limexp function when generating code; specifically hspice is compliant with the LRM-2.2 while Xyce appears not to be. Below is an exert for the LRM 2.4.0, however, I the same is true at least as far back as 2.2:

"The limexp() function is an operator whose internal state contains information about the argument on previous iterations. It returns a real value which is the exponential of its single real argument, however, it internally limits the change of its output from iteration to iteration in order to improve convergence. On any iteration where the change in the output of the limexp() function is bounded, the simulator is prevented from terminating the iteration. Thus, the simulator can only converge when the output of limexp() equals the exponential of the input...The apparent behavior of limexp() is not distinguishable from exp(), except using limexp() to model semiconductor junctions generally results in dramatically improved convergence. There are different ways of implementing limiting algorithms for the exponential. Other nonlinearities besides the exponential may be in behavioral models. The $limit() system function described in 9.17.3 provides a method to indicate these nonlinearities to the simulator to improve convergence."

Am I correct in thinking that the implementation of the Verilog-A limexp function produced through Xyce/ADMS is not consistent with the Accelera LMR?

In hspice one could use $limit with exp to create the same pnjlim limiting function already provided by limexp. Can the same be achieved in Xyce/ADMS and if so are there any examples where this has been done?

Interestingly, the Xyce/ADMS implementation of limexp, which makes exp linear above a certain limit, can be enabled in hspice as a global simulator .options (affects all models including those compiled from Verilog-A) with a user controllable value rather than a hard coded value; this is one of the things that needs to be changed in order to model wide band gap semiconductor p-n junctions, otherwise the limit kicks in too soon and the junction never conducts; e.g., SiC p-n junctions will not conduct heavily at room temperature until they are forwards biased by at least 3 volts. Is there a reason why a similar arrangement hasn't been adapted in Xyce as this seems like a more flexible and consistent arrangement.

Thank you for your time.

Kind regards,

Dr N. Wood

[ngw]

For reference, the aforementioned hspice .option is expmax and its default value is 80.

[xyce-users]

You are correct.  Xyce's limexp is patterned after all of the open-source ADMS templates that were available at the time we developed ours, all of which use the simple linearization method rather than the internal state described in the LRM.  Notable examples are those in ng-spice and Qucs. 

A few years later we did implement $limit() in a way that can be used to get pnjlim-style limiting into Verilog-A models, and our implementations of VBIC and MEXTRAM in utils/ADMS/examples use it, as does the "toy" diode model in utils/ADMS/examples/toys/diode2.va.  It is documented a bit in the Xyce/ADMS users guide.

There is no plan to revisit our limexp implementation at this time.

[ngw]

Thank you for the confirmation. I will have another look at diode2.va in more detail. Hopefully I can get my model working correctly in Xyce this evening.

On a related note, if Xyce runs into convergence issues at the end of a dc sweep, the start of the following dc sweep often ends up being totally wrong (this is not something unique to Xyce); as each value in a sweep by default uses the previous value you can end up with a string of completely wrong results. In hspice you can stop this default behaviour in favour of recalculating either every point or the first point in a nested sweep, thereby overcoming this problem; is there a Xyce .options setting for this behaviour?

Thank you again in advance.

[ngw]

Sorry for asking yet another question, but I noticed that most examples outside of Xyce suggest using:

vcrit = $vt * ln($vt / (sqrt(2.0) * Is));

while Xyce examples use:

vcrit = $vt / ln($vt / (sqrt(2.0) * Is));

My model does not work with the former, but it does with the latter, as per usage in diode2.va.

Thanks.

On Tuesday, 4 September 2018 08:19:22 UTC+1, ngw wrote:

[xyce-users]

I'm reasonably sure that the expression in diode2.va is just a typo.

The expression for vcrit as used just about everywhere for an argument in pnjlim is the earlier one in your note, and is the one used in most real models in Xyce.  Compare with Xyce/utils/ADMS/examplesvbic_r1.3_prerelease/vbic_1p3.va for a Verilog example, and the SPICE3F5 diode in Xyce/src/DeviceModelPKG/OpenModels/N_DEV_Diode.C.  Both of these define the critical voltage as vt*ln(vt/(sqrt(2*Is)) and use that in the pnjlim call.

[ngw]

I didn't think to check the C++ files too. You seemed to have made a typo now actually; you probably meant to say vt*ln(vt/(sqrt(2)*Is)). For some reason my model didn't work with this value, so I will have to dig deeper to find out why. It may also be the reason why I am getting inconsistent results compared with my earlier hspice simulations (actually a big difference so I'm a bit confused there).

[ngw]

The suggestion expression is now working; I was previously using the non-geometrically scaled value of IS. The difference with the hspice simulations was due to an inconsistent parameter value that I am now aware of.