Ken Kundert wrote: > 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. > That's what the solver is for, it's not some kind of race condition. > 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.assignments [Don't recall the accumulating nature of the operator having much to do with OOMRs myself, I suspect the OOMR stuff was pretty much an afterthought.] The current behavior is inconsistent in that if you wire something up with OOMRs vs using ports then you can get different behavior. To someone with a good understanding of electronics and digital Verilog it's not at all obvious that an OOMR potential contribution will add in series with other potential contributions to a branch - the obvious behavior would be that it was in parallel (as with using ports). IMO the easiest way out of the problem is to deprecate "<+" as an operator for OOMRs, and use a new operator which is explicitly indicates that the contribution is in series or parallel (e.g. <++,<=). Kev. > -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. >>>> >>>> >>>> >>> >>> >> > > -- http://www.grfx.com mailto:dkc@grfx.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Apr 28 02:50:04 2007
This archive was generated by hypermail 2.1.8 : Sat Apr 28 2007 - 02:50:18 PDT