> 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 archive was generated by hypermail 2.1.8 : Thu Apr 26 2007 - 17:59:43 PDT