Jonathan David wrote: > 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. > But basically you are proposing a "hack" to fix a language deficiency. If the user asks for a short-circuit (or fixed voltage) I see no reason not to give it to them. It might cause the simulator problems, but it's easier for other tools to work out a short-circuit is what is intended - i.e. the simulator vendor can fix this "under the hood" with resistors if they want, but the user should not have to do it. If it's recognizable as a static assignment the compiler can collapse the nodes. 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-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.Received on Tue May 1 12:05:46 2007
This archive was generated by hypermail 2.1.8 : Tue May 01 2007 - 12:05:52 PDT