The Designer's Guide Community Forum
Modeling >> Semiconductor Devices >> Verilog-A Convergence issues with diodes and big netlists

Message started by Camillo on Apr 6th, 2019, 1:48pm

Title: Verilog-A Convergence issues with diodes and big netlists
Post by Camillo on Apr 6th, 2019, 1:48pm

I would like to open a general discussion topic on issues I found while developing a model for multi-collector bipolar transistors in HV CMOS technologies, hoping some expert can give to me and generally to compact-model developers some hints.

There are many hints already published regarding how to write compact models that I tried to follow them up to my best, however few limitation points come from the available simulators (my experience is reduced only to one simulator) that generate always convergence issues.

1. We have functions like sqrt, pow and log that by definition have derivative discontinuity. Could I conclude that those built-in functions should be never used and we have to write our smooth functions with good derivative behaviour?

2. If we have a simple resistor parameter in the model that depending on the model card can be very high or very small, which is the best way of implementing it? With an alternate base if()...I()<+ V()/R ...else V() <+ I()*R or there are better ways?

3. limexp, I noticed it is implemented as an hard clipping of the exponential for very high value, which actually introduces a discontinuity. I never found any improvement in using it but neither any problem. What I think will be more useful for a diode model for example is the $limit function of verilog-A manual. Someone knows one simulator supporting this function?

4. gmin and gdev. Someone can explain to me the difference? Do you know when the simulator use the gdev homotopy?

5. Now a diode model is simple, it will converge. My problem is that I have a netlist of more than 5000 (!) of those verilog-A diodes connected together and there the problems start. With this big netlist the dc convergence is difficult because the diodes can be forward (my goal all over is to model BJT..) or reverse biased and I did not find an easy way to help the simulator to start from some potential nodes by propagating the boundary condition from the "pin-out" of the testbench. Any hint?

6. If I have a huge netlist and for some reason some of the verilogA device terminals are left floating the convergence is even worst. Is there any option in verilogA code or in the netlister to mitigate this problem (basically a recognition of a floating terminal)?

7. When talking about thousands of instances of a verilogA code, it is not more efficient for example to write the model in plain C? Someone has experience with the CMI interface of Cadence and how to have access to it?

Thank you for any support.

Best regards,

Title: Re: Verilog-A Convergence issues with diodes and big netlists
Post by Geoffrey_Coram on Apr 8th, 2019, 8:42am

You have a lot of questions; let me see if I can answer a few of them.

1. You do need to be careful with your use of sqrt, pow, log. However, "never" is too strict: you can certainly use them when the arguments are all constant (or at least not bias-dependent). You should be able to use sqrt as long as you are sure the argument is always positive -- if it's negative, the result is complex (which makes no sense), but also watch out for the argument being zero, because the derivative is not defined there.

2. This may depend on the simulator; I think I used one a while ago that would automatically reformulate V <+ ... to I <+ ... because it thought that was a better formulation. You may want to consider whether you can simply eliminate the resistor if it's too small.

3. limexp should not be implemented as a "hard clipping." If your simulator is doing this, you may want to write your own function to linearize the exponential at a breakpoint.

7. I got involved in Verilog-A years ago because someone told me that CMI was too hard to just use. And Verilog-A is pretty good, if you have a decent compiler (you're not looking to go to assembly language because of concerns about the C compiler - a good VA compiler shouldn't have issues with 000s of instances). Some simulators do have a special optimization that they can perform on compact models (like diodes or BJTs) written in Verilog-A; in particular, this can help with the memory usage if your model has a lot of parameters. This is simulator-specific, so you may need to as the vendor about whether .model cards are supported for Verilog-A instances.

Title: Re: Verilog-A Convergence issues with diodes and big netlists
Post by vam on May 21st, 2019, 12:40am

4. gmin and gdev
I thought gmin is added to parallel with a possible tiny resistor (most likely a junction), to avoid numerical errors when solving matrix. and gdev is to used to find the DC (OP) solution, that is, when the circuit can't get convergency in normal NR, try to add large gdev in the elastic path, then it might become easy to get the convergency since now the circuit almost works like a bias-independent resistor netlist. Then using this solution (or its extrapolation) as the initial solution, reduce gdev step by step, finally to 0, finally we can get the OP.
In my experience, gdev step in Spectre is much better than other simulator.

6. About the floating external nodes, you may try $port_connected() (VAMS LRM 2.3.1 6.5.6 Detecting port connections), but I am not sure whether the simulators support it well.

Title: Re: Verilog-A Convergence issues with diodes and big netlists
Post by vam on May 21st, 2019, 2:22am

7. About using VerilogA in the neslist,
a) I thought using VerilogA directly in the netlist is a good choise by comparing with writting a C model. Because the latter choise may need to get familar with CMI (set/get the parameters, bias-independent initialization, bias-dependent calculation and stamping), and it is an error-prone process.
b) But so far as I know, all the build-in VerilogA compilers of each simualtor didn't support the complex module (like bsimcmg, psp) well: it can't handle it and/or the performance is poor. For example, a VerilogA bsim4 might be 3X slower than a build-in bsim4. So if your verilogA codes are complex, and the instances number (which using this VerilogA module) are in large scale, and the simulation speed is important, then the VerilogA solution might be not acceptable.
c) Normally the parameters inside a VerilogA module are all instance parameters, so if you want to make part of them as model parameters and be shared between all the instances, you may:
1) using paramset (LRM 2.3.1 6.4 paramsets),  
2) using attribute (* type="instance" *) on a parameter, or attribute (*instance_parameter_list={} *) on a module.
Here should be noticed that: they are not all supported by the build-in compilers (and even more, none are supported), so you might check with the simulator vendor first.

Title: Re: Verilog-A Convergence issues with diodes and big netlists
Post by Geoffrey_Coram on May 21st, 2019, 5:18am

There was a time when Verilog-A was 100x slower than built-in for complicated device models like BSIM3 -- the simulators were interpreting on the fly, which was fine for the original concept of high-level analog behavioral models (eg, an amplifier with gain and maybe one pole). When simulators started compiling, the performance got within 10x; I worked with one vendor in particular to get that performance under 2x, actually close to 1.5x. We actually did some significant work on our internal compiler and got faster performance from Verilog-A than our built-in (see "Recent Achievements in Verilog-A Compact Modeling" by myself and Mengmeng Ding in the proceedings of the MOS-AK Workshop (Baltimore 2009); also, see work by Richard Shi's group at U Washington, e.g. "Rapid BSIM model implementation with VHDL-AMS/Verilog-AMS and MCAST compact model compiler" by L. Zhou et al., Proc 2003 IEEE SOC Conference.)

The Designer's Guide Community Forum » Powered by YaBB 2.2.2!
YaBB © 2000-2008. All Rights Reserved.