Xyce parser is very slow

[Mehmet Cirit (Ceridli)]

1. If the model file is a little bit complex, with a lot of bins and corrections to model 

parameters.  For an inverter it is about 60 seconds to parse, and a few seconds for

analysis. It is just the reverse of what is expected. For a flipflop 90 second is  spent parsing the netlist and the models, a few seconds for analysis and simulation.

2. If there are too many .param definitions and expressions,  I get the following failure:

Device model XXXX.YY: Cannot convert parameter ZZ to a numeric from {...}

even though the same model is used successfully, and visual inspections shows

everything it contains has a numeric value.

3. These are simple circuits, parsing time should be less than a second. If you want to avoid model evaluation, probably it is a good idea to add an option for it to read command from stdin  'like read xyz.sp, run > xyz.out' . Then you can hash common

files between the runs, and not keep parsing them again and again.

4. Also, I don't see anything to help with DC non-convergence.  I am using version 7.5.  It seems to ignore dc convergence settings and options. If I add 'noop' to .tran line,

it seems to be finishing though.

[xyce-users]

Hi Mehmet,

thanks for the feedback.  We're aware that the parser is slow for complex PDKs and we've been working to improve it.  There is some work on this topic happening right now, actually.

Regarding the second issue "Device model XXXX.YY: Cannot convert parameter ZZ to a numeric from {...}".    In my own experience, a large number of param definitions doesn't by itself cause this to happen.    This usually happens because a particular parameter has been assigned a non-numeric type in the device metadata.  A common example is the VERSION number for a model, which is type "string" in most Xyce models, rather than "int" or "double".

For both of the above issue (slow parsing and nonconvertible params) it would be helpful to us if you could provide an example.   Would that be possible?  (I know there may be IP issues).

Regarding DC convergence, there are some options available.  You might check chapter 8 of the user guide, on "homotopy and continuation methods".

thanks,

Eric

[Mehmet Cirit]

Thanks for quick response. Good to know that you are working on it. I encountered this message under two circumstances: in a parameterized subcircuit where parameter is initialized as

p1=p

instead of p1='p' when p itself is a subcircuit parameter.  The other case is what I described before, it refers to an expression in the .model statement. Expression has all numeric value parameters, no strings. I will check again if any of them have an assignment without quotes.  I remember seeing a similar message with 1.0e+00 assignment in some contexts, but not always. It is dependent on some unknown context.   

Probably it is a bad idea to assume that there may be some string variables in these model equations, or allow them. You can not differentiate an expression with a string variable. ar

It may be good to keep track of the parameter scope based on where they are defined in the hierarchy, and allow them to trickle

down unless they are overridden by a local definition. Probably your global_param definitions may conflict with different PDK's.

I will look at the user manual once gain for dc convergence issue.

Thanks

--
You received this message because you are subscribed to the Google Groups "xyce-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/009a52b4-8b70-47ce-835e-970950509a5cn%40googlegroups.com.

--

http://www.linkedin.com/in/mehmetcirit

Dr. Mehmet A. Cirit                    Phone:  (408) 647-6025

Library Technologies, Inc.        Cell:       (408) 647-6025

19959 Lanark Lane                   http://www.libtech.com

Saratoga, CA 95070                 Email: m...@libtech.com

[xyce-users]

Hi Mehmet,

Thanks for the context.  Regarding the subcircuit pararameters, we've only very recently allowed subcircuit parameters to depend on each other.   That got added in April of this year.   If setting p1='p' with quotes works but p1=p without quotes doesn't work, that may simply be a circumstance where the parser requires that delimeter.  There are exceptions to this in the parser, which allow some expressions to be expressed without quotes, but possibly this isn't one of those cases (yet).  I'll check this.

Regarding the .MODEL parameter, I am guessing your issue may be caused by that particular parameter being declared as a non-double type.  Most likely integer, but possibly a string.  In my previous comment, I guessed it was a string but now I'm thinking an "int" is more likely.  For .MODEL parameters, Xyce isn't assuming that there are strings inside of expressions. It is asserting that setting a string-typed or int-typed parameter via an expression isn't valid.  

To give a little more explanation, Xyce doesn't attempt to infer the "type" of a parameter from the netlist.  The "type" of a model parameter is set inside the Xyce source code in the model parameter metadata for a given model, such as the BSIM3, or whatever.  The vast majority of .MODEL parameters  are of double-precision type.  Occasionally, however, some are integers and even less frequently some are declared as strings.    Usually string parameters are obvious, such as filename parameters.

Anyway, like I said, your problem with the .MODEL parameter may be an integer type parameter, rather than a string type parameter.  Expressions use double-precision variables (or std::complex<double>) .  So setting an "int" parameter equal to an expression is problematic as it involves casting.  So, by default parameters of type int also cannot be set via expressions.      This is a code design choice that may be too restrictive, and we might want to reconsider it.

It is possible to force Xyce to have exceptions to this, so some integer type parameters are settable via expressions.  But at the moment this is done on a case-by-case basis.  So if your problem is related to an int parameter, that is one possible solution.  The other is to simply change the type in the model source code from int to double.  I am guessing you don't want to share IP, but are you willing to say which parameter in which model is triggering the error?

Regarding parameter scope, we do keep track of it, and local parameters override parameters from higher levels of the hierarchy.    There are some precedence rules that change if you are running with --hspice-ext all (but not related to hierarchy).    If a parameter of the same name appears more than once in the same netlist, the choice of parameter is dependent on the precedence rules.

Anyway, hopefully this all made sense.

thanks,

Eric

[Kevin Cameron]

Netlisting and parsing from an environment like schematics is a big waste of time, if anyone is interested in running Xyce as a live OpenAccess database instead, do get in touch.

Regards,

Kev.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/75993186-88a1-4fce-967f-f5dc147d97fcn%40googlegroups.com.