All, One of the original reasons why we went with the contribution operator with its accumulating nature as opposed to a equality operator when the language was first designed was that it neatly addressed the question of "what happens if you apply it more than once to the same branch". There are two choices if you use an equality operator: 1. it is an error 2. one wins Neither seemed like a very good alternative, but in the case of OOMRs in particular it was decided that neither was desirable. Consider each case: 1. if it is an error to give a value to a branch more than once, then once a branch is given a value in a module, then it could never be given a value via an OOMR. Since it is likely that any branch that one might want to give a value to via an OOMR would already have a value, this seemed like too big a restriction. 2. if only one wins when two values are given to a branch, how is it decided which value wins, particularly if both values are being given via OOMRs. Since the accumulating nature of the contribution operator was added to the language specifically to support OOMRs, it seems odd that we are now considering stripping this feature, but only for OOMRs. Has there been some issue with the contribution operator and OOMRs? I have heard people voice an opinion that they would prefer that it be changed, but nobody has pointed out any real problems with the way it works now or what significant new capability would be gained if a change were made. -Ken Kevin Cameron wrote: > > To back up a bit in the discussion, I'd agree "<+" is a bit odd, but > it's not that dissimilar to "+=" in C. The only objection I had was to > extending the summing semantic to OOMRs and between analog blocks for > potentials, which is why I suggested using "<++" to make that case > explicit. Likewise I would have no problem with introducing a > non-summing operator (say "<=") if that makes it clearer to users what > is going on, that would then probably require another operator to match > the "<++" (say "<=+") for symmetry. Given that modelers then use "<=" > instead of "<+", why would they expect any summing of potential > contributions for OOMRs or between blocks when using "<="? > > I think re-using operators from other languages would be a bad idea > unless they do exactly the same thing. > > Kev. > > Geoffrey.Coram wrote: >> Marq - >> In most cases, though, the distinction doesn't matter: >> if you don't expect the contributions to accumulate, >> then you write your model with a single contrib and >> everything works fine; or you have multiple contribs >> of complicated expressions, and for efficienct, you >> don't want to compute the complicated expressions that >> you don't need. It'd be odd to have >> >> I(br) <+ (some complicated expression); >> if (off) >> I(br) <+ 0; //does not set branch current to zero! >> >> If it's off (the idea is that the user wanted to turn >> the current off), it seems that the user would have >> wanted to bypass the complicated expression: >> if (off) >> I(br) <+ 0; >> else >> I(br) <+ (some complicated expression); >> >> >> The curious nature of the contrib is mentioned explicitly >> in my tutorials for writing Verilog-A compact models ... >> >> -Geoffrey >> >> >> >> Marq Kole wrote: >> >>> All, >>> >>> I would even say that most users starting to write models for >>> Verilog-AMS are quite unaware of this. They write their models as >>> though it were a simple assignment - only in rare cases or when they >>> start to work on more complicated models will they start looking at >>> the actual LRM text and discover the contribution behavior. The same >>> goes for the implicit equations for that matter... >>> >>> Just my $0.02. >>> >>> >> >> > > -- 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 : Fri Apr 27 2007 - 18:47:14 PDT