Re: Fw: Contributions (was Re: disallow distributed switch branches)

Kevin Cameron wrote:
> 
> Geoffrey.Coram wrote:
> > Kevin -
> > I was somewhat sympathetic to your request to easily be able to
> > short a pair of nodes, knowing only the hierarchical path to them:
> >
> >    V(a.b.x,a.b.y) <+ 0.0;
> >
> > It seems like a reasonable thing to want to do.
> >
> > However, this causes too many problems in other areas because of
> > the fact that it's an OOMR.  If I have a bipolar transistor model
> > that's been compiled previously, and then in a new design, I
> > decide to short the b-e junction
> >     V(top.i1.ibias.b, top.i1.ibias.e) <+ 0.0;
> > then this would require re-compiling the BJT model!  (Generally,
> > compact models are written with I(b,e) <+ ..., and in any case,
> > your most recent post (below) said you want the compiler to
> > collapse the nodes.  Either way, you've changed the topology
> > of the BJT and perhaps even a larger module that has been
> > pre-compiled.)
> >
> 
> My issue was more that with the current understanding of the semantics the
> 
>   V(top.i1.ibias.b, top.i1.ibias.e) <+ 0.0;
> 
> - would have no effect if there is already a Voltage contribution on that branch.


If there is already a current contribution on that branch,
then the new contrib would be an error!

 
> To be sure that you get the short you need a new operator (say):
> 
>   V(top.i1.ibias.b, top.i1.ibias.e) <= 0.0;
> 
> > David's suggestion:
> >
> >>> What I had in mind was:
> >>> I(a.b.x,a.b.y) <+ V(a.b.x,a.b.y)*Gshort;
> >>>
> >
> > is nice, and does *not* add rows to the matrix; a voltage source
> > always does because you need an extra unknown for the current
> > through the source (unless you collapse the nodes -- but how
> > does the simulator know that your 0-v source isn't really an
> > ammeter? in which case collapsing the nodes means you lose
> > the ability to probe the current).
> >
> 
> It didn't actually say I wanted the compiler to collapse the nodes, my
> point was that if the compiler is smart enough it will be able to do so
> if it can, doing hacky work-arounds for deficiencies in the language and
> tools prevents a smart compiler from doing those optimizations (since
> the compiler doesn't know what the hack is there for).
> 
> Note: the other form of the short circuit -
> 
>   I(a,b): V(a,b) == 0;
> 
> Can be generalized to
> 
>    I(a,b): V(a,b) == func();
> 
>  - and the compiler/solver would probably not be able to differentiate
> between a short or a fixed voltage or a variable voltage. And given that
> all those cases should work, I think your claims about having to
> recompile etc. are probably moot.
> 
> Kev.

What do you mean moot?  The other form you show is an indirect
assignment, and the LRM presently contains restrictions against
using those along with direct contributions.

-Geoffrey

 
> > -Geoffrey
> >
> >
> >
> > Kevin Cameron wrote:
> >
> >> But basically you are proposing a "hack" to fix a language deficiency.
> >> If the user asks for a short-circuit (or fixed voltage) I see no reason
> >> not to give it to them. It might cause the simulator problems, but it's
> >> easier for other tools to work out a short-circuit is what is intended -
> >> i.e. the simulator vendor can fix this "under the hood" with resistors
> >> if they want, but the user should not have to do it. If it's
> >> recognizable as a static assignment the compiler can collapse the nodes.
> >>
> >> Kev.
> >>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.