Xyce wish list

[xyce-users]

For the benefit of other readers of the group, please start a new thread on the group when you change the subject (using the "New Topic" button, or by creating a completely new email message without using the "reply" feature).  When you reply to an existing message on a different subject, the Google Groups interface files your message with the one you replied to, even if you changes the subject line.  It makes it very difficult to keep replies to the two different threads separate.  I have moved this discussion to its own thread to keep the discussion separate from replies to the lossy transmission line thread, but that means my reply isn't in the same thread as your original post.

As it happens, support of additional output variables was just added on the master branch about a week ago.  They are available if you build Xyce from source code pulled from the master branch on Github.

All models derived from Verilog-A now support output of all the variables their respective authors designated as output variables.

Documentation of this fact isn't in the latest published versions of the reference guide, but tables of all available output variables are now in the docs/Reference_Guide directory, and will be built into the next version of the reference guide.  Look for the files with "_OutputVars.tex" suffixes.  The tables are LaTeX tables designed for inclusion in the reference guide, but they are roughly human readable, too.

D_200_OutputVars.tex    M_108_OutputVars.tex    Q_234_OutputVars.tex
M_102_OutputVars.tex    M_110_OutputVars.tex    Q_504_OutputVars.tex
M_1031_OutputVars.tex   M_2002_OutputVars.tex   Q_505_OutputVars.tex
M_103_OutputVars.tex    M_77_OutputVars.tex
M_107_OutputVars.tex    Q_230_OutputVars.tex

This includes the JUNCAP200 diode, the PSP102 and PSP103 models, the BSIMCMG107, 108, and 110, the MVSG-HV model, the BSIM6, the FBH_HBT, HICUM, and MEXTRAM models.  If the author said it should be available for output, it is, as of last week.

Variables listed in these tables may be output using the N() notation on .PRINT lines.

BSIM3 and BSIM4, not being Verilog-A derived models, still have to have these output variables added by hand, and we have not done so.

There are no immediate plans to add any of the other items on your wish list, I'm afraid.

On Tuesday, April 21, 2020 at 7:20:04 PM UTC-6, Abderrezak Mekkaoui wrote:Dear All
Based on the documentation the only  internal accessible variables, for
a  BSIM3, BSIM4, and BSIM-CMG version 110 device,
  are gm (tranconductance), Vth, Vds, Vgs, Vbs, and Vdsat .
Is there a way to access more internal variables like gds, cgs, cgd, and
others?
Any future plans to make internal device variables universally accessible?
Other item in my wish list:
- Transient noise analysis
- Transient noise source (1/f + white)
- Photo-current injection inside the volume of a TCAD device
Kind regards
Abdreezak

[ngw]

For those wishing to use output variables in their own models, or modified version of standard models, this can be achieved by attaching the standard Verilog-A attributes to a global variable definition; this is a common approach used across many simulators.

(*desc = OPdesc, units = OPunit*) real OPvarname;

Its use appears to be strictly limited to true OP variables and therefore cannot be used for model or instance variables; please correct me if I'm wrong.

Thank you for this new feature.

[xyce-users]

The mere presence of either a desc or units attribute in the Verilog-A declaration of a variable designates it for output.  The variable can still be used for other things in your module.

Xyce/ADMS doesn't care what you do with it in addition to output.  I don't know if other simulators have other limitations on where this technique can be used, and the LRM doesn't have such a limitation.  I do note, though, that most models that use this technique have completely new variables that they set up as output variables, even if they just copy an existing local variable's value into it.

The only thing Xyce/ADMS does to distinguish between "true" output variables and those that are used more extensively is to skip outputting code for their assignments in the sensitivity functions, because if a variable is used for nothing but output it has no impact on sensitivity and need not be computed.  Those functions are already bloated enough.

Note, though, that some models have an absolutely enormous number of designated output variables, and this can be a problem.  The PSP model, for example, has something like 200 of them, most apparently there for debugging purposes.  BSIM models like to have debugging output defined this way, too.  This is not a great idea and can impact performance of the model, as all of these extra computations have to be performed each time the model itself is evaluated, even if the variables aren't being output.  It is best to limit the urge to populate your Verilog-A model with too many output variables.

This feature was not put into Xyce/ADMS until very recently, because most models that use the feature use the ddx() feature of Verilog-A heavily in their use of output variables (for example, to compute transconductance or capacitance).  That feature did not exist in Xyce/ADMS until a couple of weeks ago, and the output variable feature followed it fairly quickly.

[ngw]

One special case where output designation fails is when it is used on a model_.<variable>:

N_DEV_ADMS<module>.C: In member function 'virtual bool Xyce::Device::ADMS<module>::Instance::updatePrimaryState()':

N_DEV_ADMS<module>.C:<row>:<column>: error: '<variable>' was not declared in this scope

 <row> |  stoVec[li_store_<variable>] = <variable>;

       |                                ^~~~~

Given that Xyce/ADMS does not automatically create a copy of a model variable that is later modified within each instance, the only solution is to manually create a separate output variable and copy the model value into it in the manner you suggested.

real var_; // local variable

real var (* desc = "output variable" *);

analog begin

    @(initial_model) begin

        var_ = 1.0;

    end

    var = var_;

I could be wrong.

[xyce-users]

Thank you for pointing this out. 

Turns out that this is consistent with the LRM section 3.2.1 (Verilog-AMS LRM v2.4), which says that only module-scoped variables are supposed to be outputtable by adding those attributes:

3.2.1 Output variables
The standard attributes for descriptions and units, described in , have a special meaning for variables
declared at module scope. Module scope variables with a description or units attribute, or both, shall be
known as output variables, and Verilog-AMS simulators shall provide access to their values. SPICE-like
simulators print the names, values, units, and descriptions of output variables for SPICE primitives along
with voltages and currents when displaying operating-point information, and these variables are available
for plotting as a function of time (or the swept variable of a dc sweep).
For example, a module for a MOS transistor with the following declaration at module scope provides the
output variable cgs .

(* desc="gate-source capacitance", units="F" *)
real cgs;

Units and descriptions specified for block-level variables shall be ignored by the simulator, but can be used
for documentation purposes.

I had not considered the possibility that anyone might try to tag model scoped variables this way (that is, variables that are used both inside an @(initial_model) block and the main module block), and it is unfortunate that Xyce/ADMS doesn't refuse to do it, leaving it until the compilation step to fail.  I'll have to see what I can do about that.    The issue is that the templates that emit the code for storing the variable into the "store" vector assume that the variable they're storing are members of the instance class, and all the templates that handle output variables are trying to make sure that is true.  Somehow these model-scoped variables are confusing that process, and not being caught early enough.  I'll have to look into that.

In the meantime, this should do the trick:

  

real var_;  // any scope at all

real VAR (* desc = "output variable" *); // never used in @(initial_<anything>)

analog begin

                   ... var_ gets set somewhere ...

    VAR = var_;

In this case, VAR will always have the right value and be available for output, even if var_ is locally scoped or model scoped.  I have seen this pattern so many times in the various models we support that I never really thought about it, and it smells like exactly the sort of thing that might have grown up as a workaround to limitations like this in other simulator --- the variable is supposed to be module scope to be output, and perhaps it is hard to tell which other internal variables will be module scoped vs. something else, and it's easiest just to define clearly module scoped variables that are solely used for output purposes.  BSIMCMG is chock full of such things (like "IDS = devsign*ids" or even "RSGEO=RSourceGeo").  There's a lot of similar stuff in PSP and MEXTRAM, too.

Anyhow, this is wandering a little far afield of the original discussion, so I'll stop here.  Thank you for raising the issue.

[ngw]

Wouldn't global @(initial_model) variables, i.e., variables assigned inside the @(initial_model) block but also used outside of it, technically be module scope variables, too? If so, could you not argue that the following is LRM valid?

stoVec[li_store_<variable>] = model_.<variable>; 

[xyce-users]

Sure, one could argue that, and one might even be correct.   [Note; we're getting into the weeds here about Xyce implementation details]

I probably won't be leaping on the task of unwinding the logic needed to make it work in Xyce/ADMS, though.  It was hard enough to get even this working, and there are other priorities.  Getting it to this point was mostly a side effect of having addressed a number of other issues that were critical to those other priorities.

As a technical implementation detail, Xyce's notion of instance, model, and "module" scoping is very different from Verilog-A's, and a lot of messy hacks need to be done just to get them approximately aligned.  Most variables used in a module wind up being declared as variables local to the device's updateIntermediateVars function.  Those used in "@(initial_model)" or "@(initial_instance)" blocks that are *also* used inside updateIntermediateVars wind up having to be declared as either instance class members or model class members, respectively, so that they are available both in the processParams functions and updateIntermediateVars.   Note that @(initial_instance) and @(initial_model) are strictly ADMS constructs and are not part of the Verilog-A language at all, so it gets a little complicated to say what the "right" thing to do with them might be.

Pure output variables get tagged by ADMS as "GLOBAL_INSTANCE" variables, and as a result wind up being instance class members.  Regular variables that also happen to be instance class members for other reasons work fine as output variables.

I can unwind the logic with enough work and make sure that when these variables are getting copied out into the store vector I pull them from the model class if they happen to be model scoped as well.  It's not that it can't be done, it's just not going to be done right away.  I have to let some hair grow back after the efforts I've put into Xyce/ADMS these last few weeks as it is.  That will require time to let my scalp heal, first.

In the meantime, using the trick that every other model seems to have settled on is probably the best thing to work around it.  If I can make it so that the issue is flagged *before* the compilation step, I will at least do that.  But doing so may be just as much work as getting it fixed properly.

I'll try to document this limitation when I get around to updating the Xyce/ADMS users' guide for release 7.1.

[ngw]

Thank you for explaining in such detail. I understand the reasoning now. This is an insignificant limitation; I am being pedantic, as usual.