Re: Hierarchical name ordering

On Saturday 19 January 2008, a r wrote:
> What I would like to be able to do is:
>
> X1 (1 2) foo bob=2k
..  an instance "X1" of "foo" (whatever that is) with a 
parameter "bob" set to "2k"

> .alter different subcircuit
?

> X1 (1 2) bar bob=2k
..  an instance "X1" of "bar" (whatever that is) with a 
parameter "bob" set to "2k"

Is this in parallel with the previous X1?  Now you have two?  or 
do you want to replace it?

To replace it:
.delete X1
X1 (1 2) bar bob=2k

You can't change the type of an instance, other than by 
replacing it.

> .alter bob=5k

Do you mean:
.param bob=5k
?

You can do that, but the "bob" in "X1" is in a different scope, 
so it probably won't do what you want.

How about:
X1 (1 2) bar bob=x1bob

Now you can change the value of x1bob:

.param x1bob=5k

and change it again:

.param x1bob=10k

> .param X1.bob=5k

I am not sure if this should work.  It violates encapsulation.  
It probably will work eventually, because Verilog has a spec 
for doing it.  You can accomplish what you want with different 
syntax as I have shown.

> X1.R1 (a b) resistor_model r=bob w=2u

Violates encapsulation, and really screws things up.  X1 is an 
object of type "bar".  If you make this kind of change, it 
isn't a "bar" anymore.

You need to pass in parameters through the parameter list.

> .delete X1.R1

Violates encapsulation .. see above.

It is not known what a "bar" is, other than its connections and 
parameters.  It might be a subcircuit, might be a built-in or 
plugin C model, might be a compiled Verilog model, etc.  Might 
even be a pseudo-component used as a probe or measuring device.

Suppose I have:

X1 (1 2) bar bob=x1bob
X2 (3 4) bar bob=x2bob

X1 and X2 are structurally identical, and must remain so.  They 
share storage.  Some calculations are shared.  In future, they 
may share a cache.

> Of course, syntax is not an issue. I recall seeing commands
> like modify, merge and delete in the gnucap manual. Can I do
> something similar with them?

I think you can do it.  It looks like a syntax issue.

If you think of it like programming ..  "no globals", but there 
is a mechanism for passing parameters and asking for 
information.

> If not - ignore it. Interactive mode is not "must have"
> feature for me. 

It has interactive mode, more so than any other simulator I know 
of.  I consider it to be a "must have".

> There is plenty more important things: 
> expressions, more analyses, IO commands, veriloga and so on.

I agree.  My effort now is concentrating on the core, with the 
intent to move as much as possible to plugins.  I consider 
plugins to be user data.  Hopefully that will encourage others 
to get involved.