Kevin, you wrote: If you try to do it as a current then you'll have to do something like: I(a.b.x,a.b.y) : V(a.b.x,a.b.y) == 0; if you try to do it with a contribution (<+) and some resistance then you'll get an error (plus more elements in your matrix). I think: V(a.b.x,a.b.y) <= 0.0; Is the simplest, least ambiguous way to describe a deliberate short. --- What I had in mind was: I(a.b.x,a.b.y) <+ V(a.b.x,a.b.y)*Gshort; -- It WONT fail if there is already a voltage source between the branches.. (Meaning that you can't combine the two branches into one.. ) you can make gshort to what ever value you need so that any delta v is negligible.. (the pc board jumber really WILL have a couple of ohms resistance..) I think users are more likely to get an error adding in V()<= 0 (due to attempting to short out another souce..) than from adding in a (very small) resistance. But off course I expect oomrs to increase the size of the matrix. you might get that even adding the short.. the resistor is better behaved than a hard short. Jonathan David j.david@ieee.org jb_david@yahoo.com http://ieee-jbdavid.blogspot.com Mobile 408 390 2425 Work: jbdavid@scintera.com http://www.scintera.com 408 636-2618 ----- Original Message ---- From: Kevin Cameron <kevin@sonicsinc.com> To: verilog-ams@eda.org Cc: Jonathan David <j.david@ieee.org> Sent: Monday, April 30, 2007 1:27:39 PM Subject: Re: Fw: Contributions (was Re: disallow distributed switch branches) Jonathan David wrote: > sorry , meant to send this to the reflector.. > > Jonathan David > j.david@ieee.org > jb_david@yahoo.com > http://ieee-jbdavid.blogspot.com > Mobile 408 390 2425 > Work: > jbdavid@scintera.com > http://www.scintera.com > 408 636-2618 > > ----- Forwarded Message ---- > From: Jonathan David <jb_david@yahoo.com> > To: Kevin Cameron <kevin@sonicsinc.com> > Sent: Monday, April 30, 2007 11:23:42 AM > Subject: Re: Contributions (was Re: disallow distributed switch branches) > In this case the user definitely expects to apply the voltage in parallel, that's why I'm advocating having a different operator (say "<=") to indicate that to the compiler. If you try to do it as a current then you'll have to do something like: I(a.b.x,a.b.y) : V(a.b.x,a.b.y) == 0; if you try to do it with a contribution (<+) and some resistance then you'll get an error (plus more elements in your matrix). I think: V(a.b.x,a.b.y) <= 0.0; Is the simplest, least ambiguous way to describe a deliberate short. > --- In my (quick and dirty) thought exercise I see no reason to forbid contributions across block boundaries and yes I WOULD want a contribution type of behavior.. > > I'm saying we should have both modes of operation, but users need to be explicit about which mode they want. > so if this is the case, then the problem is only in the simulators.. Currently I think it's just a language semantics problem. > > is there a simulator requirement to forbid contributions to the same node from different blocks? ie to allow multi-rate simulation etc.. > No, that's what happens when you hook things up normally through ports. I'm just looking to get the same behavior with both ports and OOMRs, since that's probably what you expect if you are already familiar with Verilog. > - really the only problem here is when folks try to make a short circuit with V(a) <+ 0 .. and another block adds a different voltage too that.. > Perhaps the easy way around that would be to allow a local branch declaration so that you could create in a block a branch that cannot be contributed to from outside that block.. > (As above) an extra operator fixes the problem. Deprecating the error-prone usage is not essential, but forces people to tidy up their models. > but a better way might be to deprecate switch branches.. of this sort in favor of a other sorts of switches.. > I see no reason for deprecating switch branches of any sort, I think that will cause more problems than it solves. > Ie contribute a current between two nodes proportional to a variable resistance > if two blocks contribute to the same branch quantity but are evaluated at different times, I would expect the behavior to be like that of accessing a voltage from the digital side.. the contribution from the non-evaluated branch would be a linear interpolation between its most recent value and its next value.. > (some simulators might make an approximation that its the most recent value projected with its rate of change .. but that might get into simulator design rather then language design.. > I think you are onto a different topic there :-) Kev. > > > > > > Jonathan David > j.david@ieee.org > jb_david@yahoo.com > http://ieee-jbdavid.blogspot.com > Mobile 408 390 2425 > Work: > jbdavid@scintera.com > http://www.scintera.com > 408 636-2618 > > ----- Original Message ---- > From: Kevin Cameron <kevin@sonicsinc.com> > To: Verilog-A Reflector <verilog-ams@eda.org> > Cc: Ken Kundert <ken@designers-guide.com> > Sent: Monday, April 30, 2007 10:02:43 AM > Subject: Re: Contributions (was Re: disallow distributed switch branches) > > Ken Kundert wrote: > >> edaorg@v-ms.com wrote: >> >> >>> 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. >>> >>> >> The situation is ambiguous. There are two equations when there should >> only be one. With the accumulating nature of the contribution operator >> we define how they should be combined. If we remove the accumulating >> nature, then we must define some other way for the ambiguity to be resolved. >> >> > Are you talking about the accumulating nature of the "<+" operator or > just branches in general? > >> >> >>>> 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). >>> >>> >> I am at a loss to understand why it is a problem that contributions do >> not behave the same as port connections, especially since doing so would >> make OOMR contributions inconsistent with in-module contributions. >> >> > I would differentiate "in-module" and "in-block", this discussion sprang > out of issues related to having multiple analog blocks in a module. > > While I have no real issues with the "<+" in-block behavior, I don't see > the logic in extending it to in-module (for multiple blocks) or to OOMRs. > > The problem is that if you take an analog block which is in one module > and another in another module that contribute to the same nodes, then > the behavior can change if you put them in the same module (but > otherwise connect them the same). My view is that is a subtlety that > most engineers are not going to appreciate and it will become a source > of bugs. > >> >> >>> 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. <++,<=). >>> >>> >> Again, we seem to be proposing changes for the sake of change. Is there >> a documented problem we are trying to solve? >> >> > Yes. "<+" on OOMRs gives a different behavior than regular port > connection, and there is no operator to get the same behavior as port > connection. I don't believe the average user will be aware of the > difference in behavior so that usage should be discouraged. > > I case I'd consider possible is where in some higher level of a design > you decide you need to short some connections on a pcb so you do: > > V(a.b.x,a.b.y) <+ 0.0; > > If someone else had decided to add noise on that branch a level down - > > V(b.x,b.y) <+ noise_fn(); > > Then do you have a) failure because you can't drive two different > voltages, or b) the noise, or c) 0 Volts. > > I think a) is the correct behavior for the simulator, b) seems to be > what you are advocating, and c) is what the user actually wanted. > > Kev. > > > >> -Ken >> >> >> >>> 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 <http://www.grfx.com>mailto:dkc_ f rom _grfx.com <mailto:dkc_ f rom _grfx.com> >>> >>> >>> >> >> > > > -- 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.Received on Tue May 1 11:07:19 2007
This archive was generated by hypermail 2.1.8 : Tue May 01 2007 - 11:07:36 PDT