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