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? 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? 3. what happens if the voltages on the sources start out the same but change at some later time 4. should we really be injecting nonidealities into a behavioral simulation? 5. the issue with controlled sources was already mentioned. in addition, the reported power dissipation for the circuit could be way off 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. -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.
This archive was generated by hypermail 2.1.8 : Tue Jan 30 2007 - 10:40:50 PST