Artist: some variable names get mapped into _gpar0, _gpar1 .

[Sylvio Triebel]

Hello,
I found that names of design variables, which are member of hnlInvalidParamNames
will be mapped into something like _gpar0, _gpar1 ...
(e.g. names like "out", "on", "tc" or "off", ...)

However, it seems to work fine within Artist, but not with Ocean scripts.
The problem seems to be, that in the input.scs the names of the circuit body
are mapped, but the design variables, changed by Ocean (in the header)
are not mapped. So spectre will end with a error.....

Seems to be a bug? Or do I missing something? Some special Ocean function?
There is no much information about this...but it happens from time to time..

Thanks,
Sylvio

 

[JoRobins]

I was just looking at this very issue the other day and what I figured
out was that somehow if you have a design variable with the same name
as a net name in the schematic that you are trying to simulate, and you
try to netlist with spectre the variables get renamed to _gpar0 etc. I
had to basically change the variable name to some other string which
was different from any netname and then renetlist. You could try this
workaround to get it to work in Ocean. This is probably not a bug but a
"feature" - maybe there are simulators out there which could get
confused between a netname and a variable...

After I ran into the above problem, I also tried changing the netname
instead. Somehow that didn't help probably because spectre somehow
remembered something about the old netlists/variables.. I suspect that
if I had deleted the original simulation directory with the old
netlists, maybe that could have worked....

Jose

 

[Andrew Beckett]

On 29 Nov 2005 20:33:52 -0800, "JoRobins" <wulf_homme@hotmail.com> wrote:

I was just looking at this very issue the other day and what I figured
out was that somehow if you have a design variable with the same name
as a net name in the schematic that you are trying to simulate, and you
try to netlist with spectre the variables get renamed to _gpar0 etc. I
had to basically change the variable name to some other string which
was different from any netname and then renetlist. You could try this
workaround to get it to work in Ocean. This is probably not a bug but a
"feature" - maybe there are simulators out there which could get
confused between a netname and a variable...

After I ran into the above problem, I also tried changing the netname
instead. Somehow that didn't help probably because spectre somehow
remembered something about the old netlists/variables.. I suspect that
if I had deleted the original simulation directory with the old
netlists, maybe that could have worked....

Jose

This mapping is a consequence of the fact that spectre used to have a single
name space (before IC5032) and net names, instance names, model names, parameter
names had to be distinct. So the netlister was set up to map them. When spectre
was changed to allow multiple name spaces, the mapping was not turned off.

PCR 712483 was for turning off the mapping, and has been implemented in
ICOA5251. I asked recently whether we could get it turned off in
an IC5141 USR - but it's not been committed yet.

That said, it shouldn't matter - provided you access things using the schematic
names. OCEAN and ADE handle the mapping and so you should not generally
need to refer to the netlist names.

Regards,

Andrew.

 

[Sylvio Triebel]

Hi Jose,
Thanks, but I could not reproduce this behavior.
E.g. a supplu voltage with parameter net01 (net01 exists in the schematic)
works fine, both in Artist and with Ocean.
Are you sure that the netname was not something like "input","out","p" or
"sense" ? Those are also members of hnlInvalidParamNames...
See below what I got as value of this variable.

Hmm..., my solution is currently to provide an additional check and it will complain
about such reserved names befor you will fall in this trap...

Sylvio

JoRobins wrote:

I was just looking at this very issue the other day and what I figured
out was that somehow if you have a design variable with the same name
as a net name in the schematic that you are trying to simulate, and you
try to netlist with spectre the variables get renamed to _gpar0 etc. I
had to basically change the variable name to some other string which
was different from any netname and then renetlist. You could try this
workaround to get it to work in Ocean. This is probably not a bug but a
"feature" - maybe there are simulators out there which could get
confused between a netname and a variable...

After I ran into the above problem, I also tried changing the netname
instead. Somehow that didn't help probably because spectre somehow
remembered something about the old netlists/variables.. I suspect that
if I had deleted the original simulation directory with the old
netlists, maybe that could have worked....

Jose

\i hnlInvalidParamNames
\t ("altergroup" "calculate" "correlate" "else" "end"
\t "ends" "for" "global" "ic" "if"
\t "inline" "local" "march" "mismatch" "model"
\t "nodeset" "output" "parameters" "paramset" "plot"
\t "print" "process" "save" "sens" "statistics"
\t "subckt" "to" "truncate" "vary" "temp"
\t "tnom" "scalem" "scale" "export" "int"
\t "library" "function" "endfunction" "real" "integer"
\t "input" "return" "FUNCTION" "montecarlo" "pwr"
\t "analogmodel" "abs" "acos" "acosh" "asin"
\t "asinh" "atan" "atan2" "atanh" "cos"
\t "cosh" "exp" "hypot" "log" "log10"
\t "max" "min" "pow" "sin" "sinh"
\t "sqrt" "tan" "tanh" "ceil" "floor"
\t "fmod" "absin" "absolute" "absout" "all"
\t "allglobal" "alllocal" "allpub" "autodc" "awb"
\t "backward" "bert" "bilinear" "both" "breakdown"
\t "brief" "brk" "bsim" "bulk" "cdsspice"
\t "child" "continue" "correlations" "conservative" "dc"
\t "debug" "delta" "detailed" "dev" "diff"
\t "dptran" "eng" "error" "euler" "exp"
\t "fatal" "file" "finish" "float" "forward"
\t "freq" "full" "fwd" "gear2" "gear2only"
\t "gmin" "gnd" "hspice" "in" "indifferent"
\t "input" "insist" "inst" "inversez" "isdb"
\t "lateral" "liberal" "list" "log" "logfile"
\t "lvl" "lvlpub" "max_only" "max_v_only" "meyer"
\t "min" "mismatch" "models" "moderate" "n"
\t "no" "node" "nodes" "nodes_and_terminals" "none"
\t "nonlinear" "normal" "nowhere" "npn" "npnv"
\t "nutascii" "nutbin" "off" "on" "only"
\t "oppoint" "out" "output" "overlap" "override"
\t "p" "parent" "pnp" "pnpl" "pnpv"
\t "pointlocal" "poly" "process" "psfascii" "psfbin"
\t "ptran" "pulse" "pwl" "quit" "rampup"
\t "rawfile" "relative" "rev" "sat" "sci"
\t "screen" "selected" "sigglobal" "sine" "source"
\t "sources" "spectre" "spice" "spice2" "spice3"
\t "spiceplus" "status" "std" "steps" "subth"
\t "subthresh" "suggest" "sum" "sweep" "tabular"
\t "tc" "terminals" "time" "timedomain" "title"
\t "trap" "trapgear2" "traponly" "triode" "turbo"
\t "vertical" "vt" "warning" "waveless" "wsfascii"
\t "wsfbin" "yang" "yes" "z"
\t )

 

[JoRobins]

Sylvio, I guess maybe I was talking about something different, (but
maybe kind of related?). I am not familiar with this particular issue
of "keywords" being used as variables.

Regards,
Jose