Forum
Apr 12th, 2024, 8:11am
 Pages: 1
 Verilog-A Convergence issues with diodes and big netlists (Read 1881 times)
 Camillo New Member Offline Posts: 1 Verilog-A Convergence issues with diodes and big netlists Apr 06th, 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,Camillo Back to top IP Logged
 vam New Member Offline Posts: 3 Re: Verilog-A Convergence issues with diodes and big netlists Reply #2 - May 21st, 2019, 12:40am   4. gmin and gdevI 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. Back to top IP Logged
 vam New Member Offline Posts: 3 Re: Verilog-A Convergence issues with diodes and big netlists Reply #3 - 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. Back to top IP Logged
 Geoffrey_Coram Senior Fellow Offline Posts: 1998 Massachusetts, USA Re: Verilog-A Convergence issues with diodes and big netlists Reply #4 - 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.) Back to top If at first you do succeed, STOP, raise your standards, and stop wasting your time.   IP Logged
 Pages: 1