David, Verilog-AMS is a hardware description language. We intend it to describe hardware while trying to minimize exposing the artifacts of simulation. Timesteps are artifacts of simulation. To the degree that one builds a model whose behavior depends on the timestep, that model is wrong. However, sometimes when giving the users the power they need to express the behavior of their systems in their models, we also give them access to simulator artifacts. This needs to be carefully considered because this access is a user trap. Using these features can make it easy to write bad models, and it often requires sophistication to avoid inaccurate or non-physical models. You example exploits state variables, the ability of variables to maintain their state from timestep to timestep. This capability inadvertently exposes the timesteps. If the values were continuously varying, then the model behavior will be non-physical because it will depend on the timestep, a non-physical quantity. However, if the value of the state variable is piecewise constant, then the result will not depend on the timestep. This is how the feature can be used to write useful physical models. In the case of state variables we accepted the risk that some people might write non-physical models because 1. it is possible to write physical models using this feature (in fact, there was a strong likelihood that models would be written correctly), and 2. the feature is very powerful. The situation is somewhat different for OOMR access to analog variables. With state variables, it is possible to access the current value of the variable, whereas with OOMRs it would not be. Thus, if the value of the variable varies continuously, it is not possible to write a physical model. One could play bound-step games to reduce the problem, but fundamentally the access mechanism is flawed for variables with continuously varying values. Even with variables with piecewise constant values, the delay is problematic. However, my proposal overcomes this by constraining OOMRs to event-driven variables, and forcing the module writer to manage the process of preparing a quantity for export from within the module, where the delay can be eliminated. -Ken David Miller wrote: > Hello Ken, > I am hoping you can help me understand this a bit clearer. > When you mention that it is the delay that is the problem, do you mean > returning the value of a variable at time n when probing it at time n+1 > is a bad thing? > > Since we have the restriction that OOMR probes on real variables will > not propagate partial dependencies what is the danger other than the > fact the value is a timestep old? > > It is no worse than if a user does: > analog begin > y = x; > x = x + 1; > end > > Trivial example, but here y will always be assigned the previous > timestep value of x. > > Regards > Dave > > > Ken Kundert wrote: >> All, >> It seems like we are missing the point. It is the delay that is the >> issue, not the mechanism used for accessing the value. The delay is >> nonphysical and difficult to control. As a result, it does not make >> sense for values that change continuously. It only make sense for those >> that are piecewise constant. And we currently have the ability to >> hierarchically access piecewise constant variables as long as they are >> owned by the event-driven kernel. >> >> Consider the following alternative. Let's maintain the current >> restriction on hierarchical access to variables owned by the >> continuous-time kernel, and instead make it easier to access those >> values from the discrete-time kernel. In doing so, we would be >> addressing two serious deficiencies in the language. >> >> Let me give you an example ... >> >> Consider the situation where one wants to have a single variable that >> indicates the status of a module that you can access hierarchically. >> Call the variable "fault" and make it 1 if the module is being used >> improperly and 0 otherwise. Further consider that there are two ways in >> which the module could be improperly used: if set and reset are both >> applied simultaneously, and if the supply voltage is less than 1V. One >> of these fault conditions is naturally handled by the event-driven >> kernel, and the other by the continuous-time kernel. >> >> wire fault; >> integer faultVdd; >> assign fault = (set && reset) || faultVdd; >> analog faultVdd = V(dd) < 1; >> >> The problem is, that this is not allowed in VerilogAMS. You cannot have >> a variable owned by the continuous-time kernel in either a continuous >> assignment statement or as a trigger to an @ statement unless it is >> protected by a cross function. >> >> So, my suggestion is to allow variables, both integers and reals, that >> are owned by the continuous-time context, to be used in continuous >> assign statements and in @ triggers. Then using this method, one could >> easily copy values that are to be shared, like the fault variable in the >> example, into the discrete-time context. >> >> -Ken >> >> David Miller wrote: >>> Hi Sri, >>> just a couple of quick comments. >>> No problem if you want to restrict it to accessing the last accepted >>> time step value. We can always revisit this in later versions of the LRM >>> once people have the opportunity to use the feature and we get some >>> feedback. >>> >>> During the initial step (t = 0) the value returned should be the value >>> of the variable at time -0. I mean if I assign to a variable in the new >>> analog initial block construct, I should have access to that value when >>> executing an initial step. >>> >>> When accessing an OOMR variable in an analog initial block, then it >>> should return 0. >>> >>> What was the reason for the system task? It doesn't seem it serves any >>> purpose: >>> x = inst1.inst2.y; >>> x = $new_systask(inst1.inst2.y); >>> >>> This has the same underlying behaviour. >>> The system task would mean you need to have a different once for >>> integers, reals and strings. Also means that OOMR of variables inside >>> digital blocks vs analog blocks would be different. >>> >>> Sorry I missed the call last week, but I would be interested in hearing >>> the reason for the systask, maybe I am missing something. >>> >>> Cheers... >>> Dave >>> >>> Sri Chandra wrote: >>>> Hi all, >>>> >>>> As part of the last Verilog-AMS committee meeting there was one more >>>> suggestion to resolve the issue of accessing hierarchical variables >>>> (using out of module reference). >>>> >>>> The proposal was to disallow accessing the variables hierarchically >>>> but instead provide a system task mechanism which takes in the >>>> variable in hierarchical format as an argument to return its value. >>>> The value returned by the system task would be the value of the >>>> variable at the last accepted time point, and if the system task is >>>> used in the initial_step we can return a value of 0 as new time >>>> evaluation has taken place. >>>> >>>> cheers, >>>> Sri >>>> >>>> K. Cameron [SV] wrote: >>>>> David Sharrit wrote: >>>>>>> When accessing variable values and probes on named branches the >>>>>>> value as >>>>>>> per the last iteration shall be returned (to avoid race conditions) >>>>>>> and >>>>>>> without affecting any partial dependencies. >>>>> I thought the "race condition" argument had been debunked, i.e. >>>>> analog processes are solved with a copy-in/copy-out semantic that >>>>> means the only possible race condition is during the copy-out. >>>>> >>>>> I'm also losing track of how many times we've been round through >>>>> this: there shouldn't be any semantic difference between >>>>> branches/variables accessed locally or through OOMRs - if there is it >>>>> will just cause unnecessary errors. >>>>> >>>>> Kev. >>>>> >>>>>> Perhaps I'm just confused, but even after I consider this to just be >>>>>> talking >>>>>> about variable values, I'm still uncertain and concerned as to what >>>>>> this is >>>>>> really trying to do or provide. What exactly is the "value as per >>>>>> the last >>>>>> iteration"? Presumably that is, or could be, the previous time >>>>>> point value >>>>>> in a transient simulation. For a time varying variable, will that >>>>>> not >>>>>> result in fairly unpredictable and inconsistent results, as it will >>>>>> depend >>>>>> on the particular timestep involved? And what does it even mean for >>>>>> other >>>>>> analysis types, such as AC or HB or even DC? Without derivative >>>>>> information, it seems you could either be introducing convergence >>>>>> failures >>>>>> with incorrect Jacobians, or inconsistent (incorrect) results, with >>>>>> state >>>>>> variable dependencies seeming to exist in transient simulations but >>>>>> not in >>>>>> AC simulations. >>>>>> >>>>>> It seems there were some major reasons why OOMR access to variable >>>>>> values is >>>>>> disallowed in the present LRM, and I don't yet see how these issues >>>>>> have >>>>>> been cleanly, accurately or practically resolved. >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> >>>>>> >> > -- 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 Dec 20 2007 - 13:47:54 PST