From: Marq Kole <marq.kole_at_.....>
Date: Mon Jan 29 2007 - 23:54:20 PST
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.
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, and is
believed to be clean.
Received on Tue Jan 30 00:03:01 2007
This archive was generated by hypermail 2.1.8
: Tue Jan 30 2007 - 00:03:17 PST