RE: disallow distributed switch branches

Hi Colin,

I believe that the LRM does allow the merging of resistive and capacitive
contributions on the same <+ statement. For instance, Section 5.1.3.3 in
the 2.2 LRM has the following examples for series and parallel RLCs:

V(p, n) <+ R*I(p, n) + L*ddt(I(p, n)) + idt(I(p, n))/C;

I(p, n) <+ V(p, n)/R + C*ddt(V(p, n)) + idt(V(p, n))/L;

With that said, I too like the additive nature of <+ (although if it
wasn't additive, developers could simply contribute to a variable
piecemeal and then hand off the variable to <+ at the end). If a developer
feels that the single-contribution style is aesthetically preferable, the
current language spec allows that.

Regards,

- Boris

> I believe that having the accumulation behavior of <+ is good.
> This allows modular code (separate blocks for DC/current,
> AC/charge, and noise, I always do this), and re-usable sections of code
> that include <+
> can be used as building blocks (although I do not use <+ in blocks like
> this myself).
>
> I have found that <+ is the only really "different" operator
> compared to other programming languages, and people quickly
> understand how it works and have no trouble using it.
>
> Also, as you can declare multiple named branches and then
> separately contribute to them, even if <+ (or another operator)
> was not accumulative, you could effectively make it so anyway.
> And there are times when you are really forced to do this anyway,
> when you want both a voltage contrib (e.g. V=I*R form for a resistor)
> and a current contrib (e.g. I=ddt(C*V) form for a capacitor)
> to combine in parallel you cannot merge these into a single contribution
> operation.
>
> If you want to lump all contribs (of one type) to one branch together
> you can do it now,
> but there are good reasons for wanting <+ to be accumulative, and I have
> not
> seen people run into problems with this (there are *many* other mistakes
> they make though ...), so I think just having <+ as it is is fine.
>
> Colin
>
>
> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Ken Kundert
> Sent: Thursday, April 26, 2007 5:59 PM
> To: Muranyi, Arpad
> Cc: verilog-ams
> Subject: Re: disallow distributed switch branches
>
>> However, going back to the original subject, which revolved around
>> contribution vs. assignment, I think it would still be nice to have an
>
>> assignment like operator which doesn't accumulate like the
>> contribution operator.  To me it to be a lot safer to code the
>> equations that way...
>
> Arpad,
>     I disagree. I have been using the language and helping others learn
> and use the language for over 13 years, and I have never come across a
> case where this was an issue. To me, there is more risk in adding this
> new operator than keeping things they way they are now. Certainly there
> is more chance of confusion. After all, we would be adding a new
> operator that behaves almost the same as an existing operator, and yet
> is less capable. I think that would be confusing. And we would be doing
> it simply to eliminate a potential problem that nobody seems to be
> having.
>
> Personally, I would hate to see this change. I feel that the
> "contribution" aspect of the contribution operator results in much
> cleaner code, and has a certain simple elegance.
>
> -Ken
>
> Muranyi, Arpad wrote:
>> Ken,
>>
>> Thanks for that insight, this is good information to know.  I have
>> come across problems with tolerances, but putting it in this
>> perspective it makes more sense.
>>
>> On the suggestion from a private email I looked up "implicit
>> equations" in the LRM, and I have to admit that I was wrong earlier in
>
>> this thread when I stated that equations in Verilog-A had to be
>> arranged so that a variable appears only on one side of the "<+"
>> operator.  I understand now that this is not a requirement.
>>
>> However, going back to the original subject, which revolved around
>> contribution vs. assignment, I think it would still be nice to have an
>
>> assignment like operator which doesn't accumulate like the
>> contribution operator.  To me it to be a lot safer to code the
>> equations that way...
>>
>> Thanks,
>>
>> Arpad
>> ===================================================
>>
>> -----Original Message-----
>> From: Ken Kundert [mailto:ken@designers-guide.com]
>> Sent: Wednesday, April 25, 2007 12:49 PM
>> To: Muranyi, Arpad
>> Cc: verilog-ams
>> Subject: Re: disallow distributed switch branches
>>
>> Arpad,
>>     Actually, this "feature" that VHDL-AMS has, that of being able to
>> connect two arbitrary expressions with an == operator is one of its
>> biggest flaws. This is one of three common ways of representing an
>> implicit equation. The three ways are ...
>> 1. f(x) = 0
>> 2. x = f(x)
>> 3. f(x) = g(x)
>> Verlog-AMS forces users to use form 2. In VHDL-AMS, you can use any
>> form. They three forms are all mathematically equivalent. So it would
>> seem that VHDL-AMS is nicer in that it is giving the user the
>> flexibility to express the equation in the form that is most natural.
>> However, while the 3 forms are all mathematically equivalent, they
>> differ in a very practical manner for the simulator. The simulator
>> needs tolerances in order to determine if the equation is solved to
>> sufficient accuracy. In forms 1 and 3 the scaling of the equation is
>> arbitrary, so there are no natural tolerances. In form 2, the scaling
>> is fixed by the presence of x on one side of the equation, and x is
>> quantity with a nature, so we have the tolerance. So in Verilog-AMS,
>> the users normally do not have to worry about tolerances, which is
>> good because tolerances are confusing to most users. The fact that
>> VHDL-AMS is unconstrained means that users have to give different
>> tolerances on each equation, which means that the tolerances are
>> embedded in the models. This is a very ugly aspect of VHDL-AMS, one
> that we do not want to duplicate.
>>
>> -Ken
>>
>
> --
> 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.
>
>
>



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.