Geoffrey.Coram wrote: > 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! > Why? You can have a current contribution into a short. > > >> 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. > That restriction only applies within a single analog block. Contributions via OOMR and ports are not restricted that way (the driver of the OOMR is a different block-instance). Kev. > -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.Received on Fri May 4 11:15:49 2007
This archive was generated by hypermail 2.1.8 : Fri May 04 2007 - 11:15:51 PDT