Query | Resources to BSIM Released Models and Equivalent MOSFET LEVELS

[rohitya...@gmail.com]

Hi,

The Xyce reference guide is a good start but not comprehensive enough. I am curious to understand as what are the major difference between the foundry default hspice models vs Xyce one.

I have not been able to find any resources as how are the levels determined by the commercial simulators? As per the documentation available for bsim3 at http://bsim.berkeley.edu/models/bsim3/ for any release does not specify the level for the MOSFET. I would be grateful if someone could point me to the right resource where I can find the bsim released version and corresponding MOSFET model.

Also, I see the implemented models in the Xyce source for MOSFET which is almost 20K+ lines, I am not sure if these source code files were generated or manually written. Is there a way to integrate the models written in openmodelica language into the Xyce at the time of compilation to extend the models? I have successfully been able to create small scale models using ADMS guide https://xyce.sandia.gov/documentation/XyceADMSGuide.html. But the veriloga language is not similarly powerful and easy compared to the Modelica.

Hope to hear someone soon.

Regards,

Rohit

[xyce-users]

There is no definitive guide to the differences between Xyce models and HSPICE model implementations.  HSPICE has numerous instances of standard SPICE models that have proprietary extensions.  Few of these are explicitly documented as extensions, and one simply has to look at the original, open-source code released by the model authors to work out for oneself how HSPICE has extended it --- in many cases one can at least see which parameters of the HSPICE model were not part of the original model release and conclude that HSPICE must have added some model equations to support those new parameters.  Being closed-source, it is not possible to see exactly what HSPICE has done.  Worse, we have found that some proprietary extensions have even been made to the legacy SPICE MOSFET models levels 1-6, and we are unable to support those extensions either.

The definitive releases of BSIM code are all collected along with their thorough technical documentation, at the BSIM web site at Berkeley, http://bsim.berkeley.edu/.  We document only differences between the implementations in Xyce and those described in the release documents at Berkeley for the same version we implement (which is not often the very latest version available).

In the case of legacy models such as the BSIM3, BSIM-SOI 3.x, and BSIM4, the models were originally released in SPICE3F5 source code format, intended to be dropped directly into a SPICE3F5 source tree and recompiled.  For those models, the entire thing needed to be ported into Xyce source code via a laborious, manual process.  All of the other MOSFETs in the "OpenModels" directory of Xyce (i.e. MOSFETS level 1, 2, 3, and 6) are similarly direct, manual ports of the code from SPICE3F5.  Because of the extreme labor-intensive nature of porting SPICE3F5 C code into Xyce C++ code, we have not seldom revisited these C models when the BSIM group releases a new version (which has thankfully become very infrequent for these old C implementations).  That is why our BSIM3, BSIM-SOI 3.x, and BSIM 4 models represent somewhat older versions of the Berkeley release. 

The BSIM 3 in Xyce is BSIM 3.2.2, which is several releases behind the latest 3.3.0 release of 2005 --- the effort to port BSIM3 to Xyce was tremendous and we do not envision the need for an updated version of this model to rise to the level necessary to justify expending that level of effort again. 

Our BSIM-SOI 3.x model is BSIM-SOI 3.2, mercifully the last of the BSIM-SOI 3.x line --- and the effort to port that version to Xyce was orders of magnitude higher than porting BSIM 3. 

Our BSIM 4 model is version 4.6.1 from 2007.  It was not as big a deal to port to Xyce as the BSIM3 and BSIM-SOI 3.x were, but it was still difficult and error-prone. It was first attempted in Xyce beginning in 2006 by porting the 4.5.0 model, and when that effort languished it was taken up again almost a year later and updated to the version 4.6.1 that had been released in between.  Even then, errors in the original port remained, and the last bug in the port was not actually fixed until this past February.  Again, the effort required to port this model from the original SPICE3F5 C implementation to Xyce was significant enough that updating it even to the last version of 2013 is not likely to happen unless real business needs dictate doing so.

We have endeavored to make the versions we have ported to Xyce be strict implementations of the versions as provided and documented by the BSIM group, and have not added any extensions --- what physics the original authors put into the model remains the only physics in the implementation in Xyce.  We are completely unable to support HSPICE extensions to these models, as there is no way to know exactly how they have extended the models.

The source code in the ADMS directory has all been machine generated using the Xyce/ADMS Verilog-A compiler.  The original Verilog-A source code for these models is generally available through the web sites we link to in the reference guide.  The actual Verilog-A source code we used to generate the models is always present in the utils/ADMS/examples subdirectories of the Xyce source tree.  We have frequently needed to modify these models to get them to compile with ADMS, and when we have done so the differences are always documented in a "README_Xyce" file in the same directory as the Verilog-A source code.

Because models in the ADMS directory are machine generated using ADMS, it is usually easier for us to update them to more recent versions when they are released.

There is no current translation option from any language other than Verilog-A into Xyce-compatible source code.  There is no reason someone couldn't write one just as we have done for Verilog-A, but we are not working on it and are unaware of anyone outside of Sandia working on it.  Veriliog-A has become the industry standard for writing compact models, and maintaining a compiler to support that language has been hard enough.

In general, model levels for MOSFET models other than the original handful of models present in SPICE3F5 are arbitrary and differ from simulator to simulator.  The BSIM 3 model, for example, is the level 9 model in Xyce, but it is the level 8 model in PSPICE (or at least it was once), and may be the level 49 model in HSPICE.  There is no gold standard for model levels, as in general these model levels are not determined by the model authors, but rather by simulator implementer.  There is not even a portable mechanism in Verilog-A to make a model be a certain model level --- every simulator has its own mechanism for defining the model level, and some tricks that some model authors have tried to use to recommend a level (e.g. by creating a model parameter named "LEVEL" and testing that it is the expected value) is not portable across simulators and does not in fact work in Xyce (though when an author does this, we try our best to make our model level be the same one envisioned by the author, as for example the newly-implemented DIODE_CMC model that is the level 2002 diode model in the Xyce development version (and the upcoming release 7.2)).

If the model author has not mentioned an expectation that a model will be implemented as a specific model level, we have often just made up a level on the spot based on the version number of the model's release (not an ideal arbitrary choice).  Sometimes we are guided by another simulator's choice, but even that doesn't always work.  For example, when BSIM-SOI 4.x was added to Xyce, we first chose "LEVEL=70" for it, because that is what HSPICE uses.  Then we learned that HSPICE's level 70 model implements BSIM-SOI 4.5.0, and we had implemented 4.6.1, which turns out to have a bug that makes it unusable in some use cases and certainly not backward compatible to level 4.5.0.  It is not possible in Xyce to use the extra "VERSION" model parameter to select different versions of a model (e.g. you can't use "level=70 version=4.5" in Xyce --- every version must have a unique level number).  Hence we were forced to implement a second BSIM-SOI 4.x model level 70450 to gain access to the 4.5.0 release.

From time to time we have tried to provide "alias" model levels so that model cards for HSPICE or PSPICE may be used without modification, but this is not always possible (for example, it may be that two different simulators use the same model level for completely different device models).

XDM has been written to understand at least some of the mappings between model levels of other commercial simulators and those in Xyce, and to make appropriate translation of model cards.  For example, the BSIM-SOI 4.6.1/4.5.0 issue is known to the XDM developers as a compatibility issue, and so when XDM encounters a MOSFET model card of level 70 in an HSPICE netlist it translates it to a level 70450 MOSFET model card for Xyce.  What it can't translate it leaves alone for the user to fix.

[Rohit Yadav]

Thanks a lot for the detailed information. You have pretty much confirmed what I expected. I have no issues with VerilogA, it been working fine, there is no reason to change it. 

I was primarily confused by the level number of the models, now that you clarified it makes sense. It is fairly arbitrary in nature how commercial EDA chooses it and Xyce is trying to follow it as much as possible. 

I certainly have been able to find information about the Mosfet models and their purpose from the Hspice documentation. I can easily compare the missing parameters which in general so far have been in agreement with what XDM dumped as a warning during translation.

Thanks,

Rohit

--
You received this message because you are subscribed to a topic in the Google Groups "xyce-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xyce-users/hqsP6cIPROE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xyce-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/5061058c-38ed-4254-8080-ca1f3859bb61o%40googlegroups.com.

[camer...@gmail.com]

Hi Rohit,

There is a history to SPICE and how it works, one of its problems is that the device models used to be built in as compiled C code, and there was a tendency to try to do it with a single model for all device sizes across all processes so you get 20k+ line models (with hundreds of parameters). The idea with moving to behavioral languages like Verilog-A is that you can just deliver the model for you process along with the PDK and not worry about other people's. Unfortunately the thinking stuck with the one-model-for-all-cases approach.

Given that we are modeling Silicon transistors, Verilog-A is perfectly sufficient, but ADMS is a bad approach to implementing it - it fits with the old compiled-in model approach, and really you need to push the compile to elaboration time.

Secondly, if you have a behavioral language capability you want to model at the block level and not the transistor level, which you can easily do if you are using cell-based design.

So if you have HSPICE and its models available, the best thing to do is use it as a reference for creating block-level models for use in Xyce. There's an AI technique for doing that in here -

Wiley: Adaptive Inverse Control: A Signal Processing Approach, Reissue Edition - Bernard Widrow, Eugene Walach

Regards,

Kev.

[rohitya...@gmail.com]

Hi Kev,

Thanks for the response. I am curious if you have a sample project implementing such a macro model using the methodology discussed in the book mentioned above.

Regards,

Rohit

[camer...@gmail.com]

Unfortunately I have not had the opportunity to give the methodology a go. I came across it at a talk Bernard gave for the IEEE back in the recession (a decade ago).

The guy responsible for LTspice had given a talk about various aspects of LTspice, in which he mentioned that he had incorporated ESL & ESR into his capacitor model, which makes power-electronics modeling more efficient (eliminating some nodes). I was wondering if there was a general technique for collapsing devices models together, but my friends who worked on HSPICE didn't know how to do it. IMO that's still a possibility, but my math skills are not up to it. When I saw Bernard's talk I realized that what his neural-network approach was doing was just what I needed - a reduced order approximation to something too complex to understand properly.

For modeling digital circuits it works quite well because you can use ATPG to create test vectors for training the neural network. The neural-network itself can be an event-driven model that doesn't need to go into the analog solver, which is why I did this - http://cameron-eda.com/2020/06/03/rolling-your-own-ams-simulator/

Another interesting Stanford guy is Boris Murmann - https://murmann-group.stanford.edu/ - but they don't seem to do much cross-functional stuff there. Here's a talk where you can see some of the overlap in the math -

https://www.youtube.com/watch?v=kg6XFWeHfjg

Kev.