gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Hierarchical name ordering


From: al davis
Subject: Re: [Gnucap-devel] Hierarchical name ordering
Date: Sun, 20 Jan 2008 01:21:21 -0500
User-agent: KMail/1.9.7

On Saturday 19 January 2008, a r wrote:
> On Jan 19, 2008 8:47 PM, al davis <address@hidden> 
wrote:
> > 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
> >
> > ?
>
> That's hspice's (and spectre's) way of restarting the
> simulation with some changes to the circuit. "different
> subcircuit" is a new simulation title. Any cards that follow
> ".alter" override cards from the previously defined circuit.
>
> That was just an example. I thought you are familiar with
> this syntax, sorry.

sort of ...  I have seen several variants of "alter".  It looks 
like you are referring to something derived from Spice-2, where 
the line is just plain ".alter" with nothing else.  It might 
have worked to put comment text following the word "alter", but 
I don't remember.

Spectre and Spice-3 do it different.

Gnucap does it more like Spectre, but the syntax is different.  
It doesn't quite work the way I want, but that will get better, 
eventually.  It's a matter of deciding what to do first.

The old Spice-2 way is derived from the idea that order doesn't 
matter, except ......

I guess you could say there is an implied "alter" when you need 
it.  This is a syntax issue.  The functionality you want is 
there.

>
> A number of:
> > Violates encapsulation, and really screws things up.
>
> I disagree. At testbench level encapsulation is no longer an
> issue. Sure, people want encapsulation but that's only true
> at design stage. Global parameters, global connections are
> almost always forbidden nowadays. However, people do want a
> full transparency of the design at evaluation stage. That's
> why I asked for probing internal net voltages in the first
> place.
>
> > 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.
>
> Why? You mean you want to continue the simulation after the
> circuit topology changes? That was not what I meant. It's
> rather "once the simulation ends, modify the circuit (in any
> way you like) and rerun previous analyses (or start some new
> ones)". I didn't propose doing such (or any) changes to the
> circuit on the fly.

In this case, think of those instances as compiled, using a 
shared library.

You can't do:
"delete X1.R1" because X1 is compiled.

You can do:
"delete bar.R1", which will change it for both X1 and X2.
(actually, it's "R1.bar", because of the reverse order that I 
asked about)  It works now.

If you could do "delete X1.R1", it would require the circuit to 
be already "elaborated", but topology changes trigger 
re-elaboration, which would clobber your change.

> Again, this was just an extension of our discussion on
> probing internal voltages. 

The capability to probe internal voltages is a good idea.  There 
is a technical issue with it.  The problem is that the node 
names don't exist.  There is a place for them and the mechanism 
for searching them is already there, but the physical list is 
not there.  It will be done eventually.

To do that now means something else gets put off.  That is why I 
suggested branch probes as a work-around.  

You can probe internal branch voltages, and lots of other 
internal data.  I am not aware of any other simulator that lets 
you probe as much internal stuff as gnucap does.

> If you don't like this scheme 
> there is no problem at all - starting many separate
> simulations will do fine.

I think it does what you need.  You are stumbling on syntax.  
The Spice-2 "alter" is a concession to the sorting that was 
done in the days of punch cards.  The Spectre alter is 
essentially what gnucap does.  It's only a syntax difference.  
Eventually, a plugin can be made to match the syntax.

> In fact the only benefit of 
> ".alter" or similar commands is that waveform viewers are
> usually smart enough to display results of such simulations
> as a set of waveforms (a sweep).

You can do that in gnucap too ..   When directing the output of 
an analysis to a file, use ">>" to append.  You can put 
multiple analyses in a single file, so you can plot a family of 
curves.

We really need a good waveform viewer, that is "smart enough" to 
do that.  I have been led to believe it can be done with some 
general purpose plotting programs, but "gwave" doesn't do it 
and is stalled, and "kjwaves" is going in a completely 
different direction that is not useful to advanced users.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]