Ken Kundert wrote: > Kevin, > This conversation is beginning to seem familiar. I think we have had > it before. And I remember pointing out that you simply cannot have two > or more voltage sources in parallel. Nor is there any value in doing so > as anything in parallel with a voltage source has no effect on the rest > of the circuit. > Yes we are repeating the discussion, and I said it was perfectly OK to have multiple voltage sources of the same potential - and it appears that that is supported in the simulators. Also, for non-constant voltages in parallel the solver will balance the currents so that the voltages match. The only failing case is more than one constant voltage source of a different value. > The reason for having OOMR voltage contributions being in series is > consistency with the rest of the language. Why should the rules be > different for out-of-module-references than for in-module-references? > I think you are just avoiding my question on justifying the behavior being different depending on how you wire things up. I'd ask the question: why should in-module behavior be different from multi-module behavior, and hence why should OOMR behavior be different from that. > There is also a nice application of this, originally suggested by you. > Imagine that you have a module that has an output driven by a voltage > source. And say that you want to more accurately model the delay caused > by a load capacitance, but you don't want to explicitly go in and modify > the module. With OOMRs you can effectively add a series resistance if > the language stays as currently defined, but you could not do it if the > language were modified so that all OOMRs combined in parallel. > I don't remember suggesting that. However, I do remember proposing a back-annotation scheme that would allow you to do the same thing. -- If I you have the module: module batt (pos,neg) electrical pos, neg, lcl; parameter real res = 1.0e-3; parameter real vb = 1.0; analog V(pos,neg) <+ vb - res * I(pos,neg); endmodule That's a non-ideal battery, I should be able to put a bunch in parallel. Should instantiating it with res = 0.0 change the behavior significantly? NB: I have nothing against providing a summing behavior if people think they need it, I just don't think it should be the default anywhere outside an individual analog block. Kev. > -Ken > > > > Kevin Cameron wrote: > >> Ken Kundert wrote: >> >>> Kevin, >>> In a response you wrote to Geoffrey, you say >>> >>> >>>> Contributions from analog blocks in different modules are in parallel for >>>> potential and flow - thats the way it has always been. I'm just asking >>>> for that behavior to apply consistently. >>>> >>>> >>> My point is I don't believe that is true, nor should it be true. That >>> certainly was not the intent when this functionality was originally >>> defined, and it does not seem consistent with the LRM. >>> >>> >> If it is not true it becomes somewhat difficult to get reliable modeling >> with voltage sources. I think most hardware engineers would expect a >> bunch of identical 1V ideal voltage sources in modules connected in >> parallel would just produce a 1v potential (as previously discussed: >> current simulators do that). >> >>> So again, why are you assuming that OOMR contributions would combine in >>> parallel? >>> >>> >> In digital a driver is a real object in the simulator. A branch (named >> or unamed) in the Verilog-AMS syntax is not a real simulation object, >> the real objects are the contribution (belonging to the analog block, as >> a driver belongs to a digital process) and the nodes it connects. In the >> examples the nodes being connected are the same in all cases, and the >> analog blocks are the same, I see no justifiable reason for the behavior >> being different. >> >> What reason can you give that the behavior should be different? >> >> Kev. >> >>> -Ken >>> >>> >>> Kevin Cameron wrote: >>> >>> >>>> Ken Kundert wrote: >>>> >>>> >>>>> Kevin Cameron wrote: >>>>> >>>>> >>>>> >>>>>> You are confusing the issues. The problem is if you have >>>>>> >>>>>> module A ... >>>>>> electrical a,b; >>>>>> analog V(a,b) <+ 5; >>>>>> analog V(a,b) <+ 6; >>>>>> endmodule >>>>>> >>>>>> Which would work under Marq's proposed rules giving V(a,b) == 11, but if >>>>>> you split it into submodules: >>>>>> >>>>>> module A ... >>>>>> electrical a,b; >>>>>> B; >>>>>> C; >>>>>> endmodule >>>>>> >>>>>> module B.. >>>>>> analog V(A.a,A.b) <+ 5; >>>>>> endmodule >>>>>> module C >>>>>> analog V(A.a,A.b) <+ 6; >>>>>> endmodule >>>>>> >>>>>> That fails because the contributions are now considered as being in >>>>>> parallel. >>>>>> >>>>>> >>>>>> >>>>> Kevin, >>>>> Why are you assuming that OOMR contributions would combine in >>>>> parallel? That was not the original intent, nor does it seem to square >>>>> with the LRM, which says ... >>>>> >>>>> "From within an analog block, it is possible to use hierarchical name >>>>> referencing to access signals on an external branch, but not external >>>>> analog variables or parameters. When accessing external branches, a >>>>> branch signal (its potential or flow) can be monitored (probed); for >>>>> source branches, contributions can be made to the output signal." >>>>> >>>>> While it is not very explicit, it does say that external contributions >>>>> are made to the existing branch. There is no mention of creating a new >>>>> parallel branch. >>>>> >>>>> >>>>> >>>> I think you are making my point: >>>> >>>> Why should the two version above behave differently? >>>> >>>> If I rewrite it again: >>>> >>>> module A ... >>>> electrical a,b; >>>> B(a,b); >>>> C(a,b; >>>> endmodule >>>> >>>> module B(electrical a, electrical b); >>>> analog V(a,b) <+ 5; >>>> endmodule >>>> module C (electrical a, electrical b); >>>> analog V(a,b) <+ 6; >>>> endmodule >>>> >>>> >>>> - why should that behave differently? >>>> >>>> Note: while these are obvious cases, I'm more worried that it will >>>> appear in larger models where small voltages are being injected for >>>> noise or correction, and the behavior change would be subtle. >>>> >>>> Kev. >>>> >>>> >>>>> -Ken >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Apr 19 17:39:32 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 19 2007 - 17:39:38 PDT