RE: disallow distributed switch branches

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.