Ken Kundert wrote: > Kevin, > If one doesn't use resistors, then there is a significant amount of > complexity in the implementation and the result will be arbitrary and > non-physical. The complexity includes the run time checks and the code > that artificially removes all but one source, and then later > redistributes the currents (including the need to fix up the Jacobian > when there are controlled sources depending on the currents). > Seems like it would be more work to do the resistor thing to me, and it would make the simulation slower. > So there is a cost in solving this 'problem', but is there a benefit? > You claim that a user would want to be able to put two voltage sources > in parallel as long as they are the same voltage. My experience tells me > the opposite. Every time I have done this it has been as a result of an > error and I appreciated the error message. Furthermore, in all my time > at Cadence and HP, never once did anyone indicate any desire to put two > or more voltage sources in parallel. You gave as a justification the > case of batteries. But designers that are designing battery systems > would always use more sophisticated models for batteries that would > allow them to be placed in parallel, and designers that are not > designing battery systems would just naturally model the batteries using > a single voltage source. > According to Marq at least one simulator company has it's simulator handling this with sharing the current across the sources, I'll presume that they had some motivation for doing so. You didn't like my super-conducting wire-or example? > My point is that we are addressing a non issue, and that any 'solution' > we come up with will be worse than the 'problem'. > We need a definition of the behavior of parallel potentials for the LRM, my view is that they should be allowed as long as the potential is exactly the same and the current will be split evenly across the potentials (and the user gets a warning). If you disagree propose something different. Kev. > -Ken > > > Kevin Cameron wrote: > >> Ken Kundert wrote: >> >>> Kevin, >>> Addressing this issue in the simulator is trivial, the simulator >>> need only insert a very small resistor in series with each voltage >>> source. However, doing so brings up some issues ... >>> 1. what is small? this has to be answered for all disciplines. and how >>> is the value specified? >>> >>> >> I'd rather not have the resistor. My view is that if your simulator can >> only handle parallel voltage sources by inserting a resistor then you >> would get an even split in the current (for identical sources), so if >> that's the (LRM's) defined behavior your simulator will appear to be >> doing the right thing. >> >>> 2. what happens if the voltage sources have slightly different values >>> (the voltages are real numbers, so some difference would be expected). >>> how big is negligible difference? >>> >>> >> I can't see any good reason for allowing a difference with ideal sources. >> >>> 3. what happens if the voltages on the sources start out the same but >>> change at some later time >>> >>> >> Due to switch branches, this would be a runtime check, so it will fail >> then if there are multiple differing voltage sources. >> >>> 4. should we really be injecting nonidealities into a behavioral >>> simulation? >>> >>> >> Definitely not. >> >>> 5. the issue with controlled sources was already mentioned. in addition, >>> the reported power dissipation for the circuit could be way off >>> >>> >> I'm not seeing how power would be wrong, unless you allow differences in >> the voltage sources (which I wouldn't). >> >>> 6. is this really what the majority of the users would want? I have been >>> using simulators extensively for 30 years now, and I have gotten a fair >>> number of "loop of voltage sources" errors, and every time it was >>> because of an error in the netlist. there was not a single instance that >>> I can recall where I would have preferred that the simulator just >>> inserted some series resistors and continued. >>> >>> >> Wasn't me who suggested series resistors. >> >> Kev. >> >> >>> -Ken >>> >>> Kevin Cameron wrote: >>> >>> >>>> Marq Kole wrote: >>>> >>>> >>>>> Kev, >>>>> >>>>> The problem is that any pair of currents that add up to the correct >>>>> current for the total branch will work. That makes any solution highly >>>>> implementation dependent. Yesterday I found another simulator that >>>>> gives a solution, but this one split the current equally among the >>>>> voltage sources. Also the instability of the solution is very much a >>>>> problem. >>>>> >>>>> Unless we can nail down exactly what a solver should do in this case, >>>>> I would not be supportive of allowing parallel voltage sources. The >>>>> safest is to say that all solvers should break out with an error. >>>>> >>>>> >>>> The only problem I'm seeing is that you can't (reliably) probe the >>>> current on parallel voltage sources. If I had to pick a default behavior >>>> I'd probably go for the equal split (as above) and also issue a warning >>>> (that would give you pretty much the same result as using small series >>>> resistors, but without the simulation overhead and error). I think the >>>> case of parallel (ideal, 0V) switch branches is likely enough to turn up >>>> in behavioral code that making parallel voltage sources illegal would be >>>> a pain for users. >>>> >>>> Kev. >>>> >>>> PS: Thanks for doing the research. >>>> >>>> >>>> >>>>> Cheers, >>>>> Marq >>>>> >>>>> >>>>> Marq Kole >>>>> Competence Leader Robust Design >>>>> >>>>> Research >>>>> NXP Semiconductors >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Kevin Cameron <kevin@sonicsinc.com>* >>>>> >>>>> Sent by: >>>>> owner-verilog-ams@server.eda.org >>>>> >>>>> 29-01-2007 18:45 >>>>> >>>>> To >>>>> Marq Kole <marq.kole@nxp.com> >>>>> cc >>>>> verilog-ams <verilog-ams@server.eda-stds.org> >>>>> Subject >>>>> Re: Potential Contributions >>>>> Classification >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Marq Kole wrote: >>>>> >>>>> >>>>>> Ken, >>>>>> >>>>>> On circuit theory grounds you are absolutely right: the system is >>>>>> underspecified as one cannot determine the value of the current >>>>>> running through the sources. However, some circuit simulators do know >>>>>> how to handle this situation. Of the 4 simulators I've been able to >>>>>> try 2 gave an error, while 2 gave a solution, though both with a >>>>>> warning. Of the ones being able to solve it, both gave all current to >>>>>> one device and 0 to the other. >>>>>> >>>>>> The test job consisted of two parallel voltage sources, each of 5 >>>>>> Volts, and a load of a 1k resistor or a diode instance. >>>>>> >>>>>> Putting three equal voltage sources in parallel still gave all current >>>>>> to one device and 0 to the others. >>>>>> >>>>>> >>>>> I suppose since the current distribution in the sources is >>>>> indeterminate, that would be (mathematically) as good a solution as >>>>> any. >>>>> I presume that the simulator is just discarding the duplicate voltage >>>>> sources and doing the minimum work - which is probably what I'd want as >>>>> a user if I'm using ideal models. >>>>> >>>>> In the (physical) case of super-conducting switches you wouldn't know >>>>> what the branch current is without probing the circuit somehow, and the >>>>> act of probing it changes the circuit - sounds like Heisenberg's >>>>> uncertainty principle to me: we know how big the current is, just not >>>>> where it's going :-) >>>>> >>>>> Kev. >>>>> >>>>> >>>>> >>>>>> By the way: when putting two unequal voltage sources in parallel both >>>>>> solvers that had been able to solve the above test job would still >>>>>> converge (with a warning) but generate huge currents whose value >>>>>> relates to the absolute current error of the simulators. Only one >>>>>> simulator gave a range warning for the currents. Mind you: given the >>>>>> error bounds of the DC solvers, these are acceptable results! >>>>>> >>>>>> The occurrence of parallel voltage sources (loopset) can easily be >>>>>> determined in a simulator, so even though the system is theoretically >>>>>> underdetermined it is possible to provide a solution. However, if the >>>>>> currents through these voltage sources are used to control other >>>>>> (non-linear) elements you will start to have a real mess, with obvious >>>>>> non-portable results. >>>>>> >>>>>> Cheers, >>>>>> Marq >>>>>> >>>>>> >>>>>> Marq Kole >>>>>> Competence Leader Robust Design >>>>>> >>>>>> Research >>>>>> NXP Semiconductors >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Ken Kundert <ken@designers-guide.com>* >>>>>> >>>>>> Sent by: >>>>>> owner-verilog-ams@server.eda.org >>>>>> >>>>>> 27-01-2007 00:23 >>>>>> >>>>>> > To >>>>>> Kevin Cameron <kevin@sonicsinc.com> >>>>>> cc >>>>>> peter_liebmann@agilent.com >>>>>> David.L.Miller@freescale.com >>>>>> verilog-ams@server.eda.org >>>>>> Subject >>>>>> Re: Potential Contributions >>>>>> Classification >>>>>> > >>>>>> >>>>>> >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Kevin, >>>>>> No, that is an error. You cannot have two voltage sources in >>>>>> parallel. The resulting current is undefined. >>>>>> >>>>>> -Ken >>>>>> >>>>>> Kevin Cameron wrote: >>>>>> >>>>>> >>>>>>> I agree with that. >>>>>>> Do you think this should cause a runtime error (same child)? >>>>>>> >>>>>>> module parent(); >>>>>>> electrical a,b; >>>>>>> ground b; >>>>>>> child #(.POT(5)) ch1(a,b); >>>>>>> child #(.POT(5)) ch1(a,b); >>>>>>> endmodule >>>>>>> >>>>>>> (I think not) >>>>>>> >>>>>>> Kev >>>>>>> >>>>>>> peter_liebmann@agilent.com wrote: >>>>>>> >>>>>>> >>>>>>>> The example below should cause a simulation error, not a verilog_a >>>>>>>> compile error. >>>>>>>> >>>>>>>> PeterL >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: owner-verilog-ams@server.eda.org >>>>>>>> [mailto:owner-verilog-ams@server.eda.org] On Behalf Of David Miller >>>>>>>> Sent: Friday, January 26, 2007 12:54 PM >>>>>>>> To: verilog-ams@server.eda.org >>>>>>>> Subject: Re: Potential Contributions >>>>>>>> >>>>>>>> Hi Peter, >>>>>>>> Okay my example was misleading. >>>>>>>> I'll try this. >>>>>>>> module parent(); >>>>>>>> electrical a,b; >>>>>>>> ground b; >>>>>>>> child #(.POT(5)) ch1(a,b); >>>>>>>> child #(.POT(10)) ch1(a,b); >>>>>>>> endmodule >>>>>>>> module child(p,n); >>>>>>>> electrical p,n; >>>>>>>> parameter integer POT = 0; >>>>>>>> analog begin >>>>>>>> V(p,n) <+ POT; >>>>>>>> end >>>>>>>> endmodule >>>>>>>> >>>>>>>> Is this an example of why potential contributions do not accumulate >>>>>>>> across analog processes? Since here I expect simulator to error, not >>>>>>>> tell me potential diff between a,b is 15? >>>>>>>> >>>>>>>> Dave >>>>>>>> >>>>>>>> peter_liebmann@agilent.com wrote: >>>>>>>> > >>> The following example: >>>>>>>> >>>>>>>> >>>>>>>>> module bb(); >>>>>>>>> electrical a,b; >>>>>>>>> branch (a,b) br1; >>>>>>>>> analog begin >>>>>>>>> V(a,b) <+ 5; >>>>>>>>> V(br1) <+ 10; >>>>>>>>> end >>>>>>>>> endmodule >>>>>>>>> >>>>>>>>> will produce an error in simulation BUT, for example, 2 >>>>>>>>> >>>>>>>>> >>>>> resistors in >>>>> >>>>> >>>>>>>>> parallel may be written as: >>>>>>>>> >>>>>>>>> module bb(); >>>>>>>>> electrical a,b; >>>>>>>>> branch (a,b) br1; >>>>>>>>> analog begin >>>>>>>>> V(a,b) <+ I(a,b)*Res1; >>>>>>>>> V(br1) <+ I(br1)*Res2; >>>>>>>>> end >>>>>>>>> endmodule >>>>>>>>> >>>>>>>>> which is legitimate. >>>>>>>>> >>>>>>>>> >>>>>>>>> Therefore the general syntax of the 1st example should be >>>>>>>>> >>>>>>>>> >>>>> allowed and >>>>> >>>>> >>>>>>>>> the simulator should recognize it as an error rather then a >>>>>>>>> >>>>>>>>> >>>>> Verilog_a >>>>> >>>>> >>>>>>>>> compiler. >>>>>>>>> >>>>>>>>> Peter Liebmann >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: owner-verilog-ams@server.eda.org >>>>>>>>> [mailto:owner-verilog-ams@server.eda.org] On Behalf Of David Miller >>>>>>>>> Sent: Friday, January 26, 2007 12:06 PM >>>>>>>>> To: Martin O'Leary >>>>>>>>> Cc: Kevin Cameron; Verilog-AMS LRM Reflector >>>>>>>>> Subject: Re: Potential Contributions >>>>>>>>> >>>>>>>>> I thought that potential contributions definitely did not >>>>>>>>> >>>>>>>>> >>>>> accumulate >>>>> >>>>> >>>>>>>>> across analog processes. They only accumulate within the same >>>>>>>>> >>>>>>>>> >>>>> analog >>>>> >>>>> >>>>>>>>> block between the same unique branch. >>>>>>>>> >>>>>>>>> so >>>>>>>>> module bb(); >>>>>>>>> electrical a,b; >>>>>>>>> branch (a,b) br1; >>>>>>>>> analog begin >>>>>>>>> V(a,b) <+ 5; >>>>>>>>> V(br1) <+ 10; >>>>>>>>> end >>>>>>>>> endmodule >>>>>>>>> >>>>>>>>> does not result in an potential difference between (a,b) of 15, but >>>>>>>>> rather an error as the potential difference between the nodes (a,b) >>>>>>>>> is not the same for all parallel branches. >>>>>>>>> Is this correct? >>>>>>>>> >>>>>>>>> So if OOMR branches result in a unique parallel branch between the >>>>>>>>> two circuit nodes then the following should error. >>>>>>>>> module bb(); >>>>>>>>> child ch1(); >>>>>>>>> analog V(ch1.a,ch2.b) <+ 5; >>>>>>>>> endmodule >>>>>>>>> module child(); >>>>>>>>> electrical a,b; >>>>>>>>> ground b; >>>>>>>>> analog V(a,b) <+ 10; >>>>>>>>> endmodule >>>>>>>>> >>>>>>>>> If however OOMR branches simply used the existing branch in module >>>>>>>>> child, then the value would accumulate with a potential >>>>>>>>> >>>>>>>>> >>>>> difference of >>>>> >>>>> >>>>>>>>> 15 across the two nodes a and b. >>>>>>>>> >>>>>>>>> Dave >>>>>>>>> >>>>>>>>> Martin O'Leary wrote: >>>>>>>>> > >>>> No - my understanding is that they do accumulate. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> --Martin >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: owner-verilog-ams@eda.org >>>>>>>>>> >>>>>>>>>> >>>>> [mailto:owner-verilog-ams@eda.org] On >>>>> >>>>> >>>>>>>>>> Behalf Of Kevin Cameron >>>>>>>>>> Sent: Friday, January 26, 2007 11:29 AM >>>>>>>>>> To: Verilog-AMS LRM Reflector >>>>>>>>>> Subject: Potential Contributions >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There seemed to be a little confusion about how potential >>>>>>>>>> >>>>>>>>>> >>>>>> contributions >>>>>> >>>>>> >>>>>>>>>> combine from multiple analog processes. 5.3.1.2 says contributions >>>>>>>>>> accumulate (for flow and potential), but my understanding is that >>>>>>>>>> >>>>>>>>>> >>>>>> only >>>>>> >>>>>> >>>>>>>>>> applies within the analog block for potential, i.e. potential >>>>>>>>>> contributions do not accumulate across analog process. Is that >>>>>>>>>> >>>>>>>>>> >>>>>> agreed? >>>>>> >>>>>> >>>>>>>>>> Kev. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> This message has been scanned for viruses and dangerous content by >>>>>>>>>> MailScanner, and is believed to be clean. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > >>> > >> >>>>>>>>>> >>>>>>>>>> >>>>>>>> > > >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> This message has been scanned for viruses and >>>>>> dangerous content by MailScanner, and is >>>>>> believed to be clean. >>>>>> >>>>>> [attachment "ken.vcf" deleted by Marq Kole/EHV/RESEARCH/PHILIPS] >>>>>> >>>>>> -- >>>>>> This message has been scanned for viruses and >>>>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, >>>>>> >>>>>> >>>>> and is >>>>> >>>>> >>>>>> believed to be clean. >>>>>> >>>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by MailScanner, and is >>>>> believed to be clean. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, >>>>> and is >>>>> believed to be clean. >>>>> >> -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jan 30 14:00:37 2007
This archive was generated by hypermail 2.1.8 : Tue Jan 30 2007 - 14:00:50 PST