The ability of ngspice to support commercial CMOS processes is a very important point that could convince many circuit designers to start using ngpsice and increase its user base.
Foundries release their device models in process design kits (PDK) which almost always come in two flavors: spectre and hspice. This short guide explains how to convert commercial hspice models so that they can be used in ngspice.
Importing hspice models into ngspice may be intimidating for a regular user. In fact, trying to use the hspice models directly may throw hundreds of errors which may discourage most of the people rather quickly. However, just a very limited number of modifications in the model files are commonly necessary to have everything working. This is my recommended procedure:
1) First check that the device models in the PDK are supported by ngspice. Sometimes the exact model level is not supported, but it may be that the required model is backwards compatible with an existing model. If the required model is not supported, then there is no need to spend more time.
2) First, study the model’s directory and identify the files that need to be included in the spice simulation. If documentation is not available, a good starting point is to check how the libraries are handled by the commercial tools. Typically there are files that set global parameters, library files that set specific parameters for corner conditions, files that set “skew” parameters including Montecarlo, and files with the individual device models. In fact, only very few model files need to be directly included in the spice simulation file.
The recommendation here is don’t test all the model files at the same time. Start with the top hierarchy files which set global parameters, comment the others files, and check if ngspice throw errors. For instance, start with something like this:
If parameters are missing, search for the file that has those parameters and include it in the simulation.
3) Hspice and ngpsice handle some things differently. These are the typical things that throw errors and their workarounds:
First, you need to comment any veriloga model that is included as it can not be directly used. Hopefully these verioga models are for devices you wont need directly in your circuit block (ESDs, etc).
Hspice will forgive you when a library file with a single library is included and the name of the library is omitted. On the other hand, ngspice will throw an error. For example:
.lib 'myskew.lib' [Ok for hspice, but not for ngpsice]
.lib 'myskew.lib' mylib_name [Ok for ngpsice]
expressions with “agauss” need to be modified: all expressions using agauss must be between {} and quotation marks ‘’ inside the agauss function must be deleted. Example:
var_mc = agauss('-alfa',1,3) [ok for hspice, but not for ngpsice]
var_mc = {agauss(-alfa,1,3)} [ok for ngpsice]
4) Very seldom you may find errors due to parameters that are referenced in some expressions but that do not exist in any file. I believe these are leftovers from model maintenance and may (hopefully) be being treated as warnings in hspice. As they dont exist, one possibility is to create them and assign 0 value so that ngspice dont throw errors.
5) Hspice seems to change the behaviour of the agauss function when Montecarlo simulation is not needed and only return the mean value. The agauss function in ngspice will always return the mean value +- random value. Accordingly, some minor considerations need to be taken.
If the model contains Montecarlo parameters, it is important to locate the master switch parameter that enables/disables it. It is normally a factor 0 or 1 that is multiplied with expressions related to statistic variations. If it is enabled by default, all simulations will include random device mismatches, etc. My suggestion is to comment the line that initializes the master switch parameter and instead add a .param line with the switch in the spice simulation file. This makes very simple to enable/disable the Montecarlo expressions. For example, if it has been found that the file skew.inc contains all the MC models, and that the control switch is mc_sw.
Then comment the assignment line in the skew.inc file:
.param [asterisc]+ mc_sw = 1
and instead at the parameter at the header in the simulation file before the model libraries are included (test.sp)
.param
+ mc_sw = 0
.inc 'include.inc'
.inc 'cmos.lib' cmostt
Sometimes, there are also Montecarlo related expressions in the device files which are not controlled by the master switch. As mentioned before, it seems hspice changes the behaviour of the agauss function when Montecarlo simulation is not needed. There may be the need to some minor modifications to respond correctly to the master switch. For example:
Here threshold and beta mismatch are not controlled by mc_sw:
+ sigvth='kvt/sqrt(wnfl)'
+ sigbeta='kmb/sqrt(wnfl)'
+ mmvth0=agauss(0,sigvth,3) $ vth0 mis-match
+ mmbeta=agauss(0,sigbeta,3) $ beta mis-match
Here a small modification makes sure that mismatch is enabled only when mc_sw = 1
+ sigvth='mc_swkvt/sqrt(wnfl)'
+ sigbeta='mc_swkmb/sqrt(wnfl)'
+ mmvth0=agauss(0,sigvth,3) $ vth0 mis-match
+ mmbeta=agauss(0,sigbeta,3) $ beta mis-match
👍
1
Last edit: Saul Rodriguez 2017-06-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any tip for handling (commercial hspice) diode-models at level=6?
On aguass() expressions, wish I'd seen above sooner, though I didn't yet verify Saul's tip (must have tried everything else but that). My work-around was rewrite agauss() expressions, factoring out a boolean master-switch multiplier like from:
diode level=6 is the juncap2 diode model from NXP (http://www.nxp.com/wcm_documents/models/other-models/juncap/juncap2.pdf). Unfortunately we don't have that for the moment.
Holger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The ability of ngspice to support commercial CMOS processes is a very important point that could convince many circuit designers to start using ngpsice and increase its user base.
Foundries release their device models in process design kits (PDK) which almost always come in two flavors: spectre and hspice. This short guide explains how to convert commercial hspice models so that they can be used in ngspice.
Importing hspice models into ngspice may be intimidating for a regular user. In fact, trying to use the hspice models directly may throw hundreds of errors which may discourage most of the people rather quickly. However, just a very limited number of modifications in the model files are commonly necessary to have everything working. This is my recommended procedure:
1) First check that the device models in the PDK are supported by ngspice. Sometimes the exact model level is not supported, but it may be that the required model is backwards compatible with an existing model. If the required model is not supported, then there is no need to spend more time.
2) First, study the model’s directory and identify the files that need to be included in the spice simulation. If documentation is not available, a good starting point is to check how the libraries are handled by the commercial tools. Typically there are files that set global parameters, library files that set specific parameters for corner conditions, files that set “skew” parameters including Montecarlo, and files with the individual device models. In fact, only very few model files need to be directly included in the spice simulation file.
The recommendation here is don’t test all the model files at the same time. Start with the top hierarchy files which set global parameters, comment the others files, and check if ngspice throw errors. For instance, start with something like this:
.inc './include.inc'
[asterisk].lib './design.inc' noityp
[asterisk].lib './cmos.lib' cmostt
[asterisk].lib './capacitor.lib' captyp
[asterisk].lib './resistors.lib' restyp
If parameters are missing, search for the file that has those parameters and include it in the simulation.
3) Hspice and ngpsice handle some things differently. These are the typical things that throw errors and their workarounds:
First, you need to comment any veriloga model that is included as it can not be directly used. Hopefully these verioga models are for devices you wont need directly in your circuit block (ESDs, etc).
Hspice will forgive you when a library file with a single library is included and the name of the library is omitted. On the other hand, ngspice will throw an error. For example:
.lib 'myskew.lib' [Ok for hspice, but not for ngpsice]
.lib 'myskew.lib' mylib_name [Ok for ngpsice]
expressions with “agauss” need to be modified: all expressions using agauss must be between {} and quotation marks ‘’ inside the agauss function must be deleted. Example:
var_mc = agauss('-alfa',1,3) [ok for hspice, but not for ngpsice]
4) Very seldom you may find errors due to parameters that are referenced in some expressions but that do not exist in any file. I believe these are leftovers from model maintenance and may (hopefully) be being treated as warnings in hspice. As they dont exist, one possibility is to create them and assign 0 value so that ngspice dont throw errors.
5) Hspice seems to change the behaviour of the agauss function when Montecarlo simulation is not needed and only return the mean value. The agauss function in ngspice will always return the mean value +- random value. Accordingly, some minor considerations need to be taken.
If the model contains Montecarlo parameters, it is important to locate the master switch parameter that enables/disables it. It is normally a factor 0 or 1 that is multiplied with expressions related to statistic variations. If it is enabled by default, all simulations will include random device mismatches, etc. My suggestion is to comment the line that initializes the master switch parameter and instead add a .param line with the switch in the spice simulation file. This makes very simple to enable/disable the Montecarlo expressions. For example, if it has been found that the file skew.inc contains all the MC models, and that the control switch is mc_sw.
Then comment the assignment line in the skew.inc file:
.param
[asterisc]+ mc_sw = 1
and instead at the parameter at the header in the simulation file before the model libraries are included (test.sp)
.param
+ mc_sw = 0
Sometimes, there are also Montecarlo related expressions in the device files which are not controlled by the master switch. As mentioned before, it seems hspice changes the behaviour of the agauss function when Montecarlo simulation is not needed. There may be the need to some minor modifications to respond correctly to the master switch. For example:
Here threshold and beta mismatch are not controlled by mc_sw:
+ sigvth='kvt/sqrt(wnfl)'
+ sigbeta='kmb/sqrt(wnfl)'
+ mmvth0=agauss(0,sigvth,3) $ vth0 mis-match
+ mmbeta=agauss(0,sigbeta,3) $ beta mis-match
Here a small modification makes sure that mismatch is enabled only when mc_sw = 1
+ sigvth='mc_swkvt/sqrt(wnfl)'
+ sigbeta='mc_swkmb/sqrt(wnfl)'
+ mmvth0=agauss(0,sigvth,3) $ vth0 mis-match
+ mmbeta=agauss(0,sigbeta,3) $ beta mis-match
Last edit: Saul Rodriguez 2017-06-24
Saul,
many thanks for your valuable information.
Maybe we open another forum "Tips and Tutorials" to increase visibility of such postings.
Holger
Any tip for handling (commercial hspice) diode-models at level=6?
On aguass() expressions, wish I'd seen above sooner, though I didn't yet verify Saul's tip (must have tried everything else but that). My work-around was rewrite agauss() expressions, factoring out a boolean master-switch multiplier like from:
to a ternary:
Last edit: Sto 2017-10-27
diode level=6 is the juncap2 diode model from NXP (http://www.nxp.com/wcm_documents/models/other-models/juncap/juncap2.pdf). Unfortunately we don't have that for the moment.
Holger
This is awesome!!!!