> In my book variables are discrete valued things, and (analog) signals > are PWL, if you want something that is going to vary continuously > over time it needs to be PWL - therefore a signal not a variable. Conceptually, the analog block executes continuously, and therefore analog variables (those assigned from within the analog block), change continuously. In this way, analog variables and analog signals are the same. The fact that it is not practically possible to evaluate the analog block continuously is an unfortunate limitation of the simulator, a limitation it is expected to minimize the impact of by evaluating the analog block enough to approximate continual evaluation. Thinking of analog variables as containing values that are discrete in time is conceptually wrong, and doing so leads to non-physical models. Our responsibility as language developers is to provide a language that naturally leads to physical models and naturally avoids non-physical models. Providing hierarchical access to the value of an analog variable at the previous time point is inherently non-physical and therefore should be avoided. > Hierarchy is an artifact of the design process and is not anything > physical, real designs are essentially flat and OOMRs are a language > feature that supports that. Here we are in complete agreement. Hierarchy is artificial. However, my aversion to providing hierarchical access to analog variables is based on implementation issues. To provide the ability to access an analog variable at the current time point, the only thing that makes physical sense, would require that the modules be recompiled in order to provide the ability to compute the needed derivatives. That would be very difficult for the simulator developers. Since this feature is of only marginal value, it hardly seems to justify the huge increase in implementation complexity. > It's fine with me if the value of a > variable I look at is from the last time step (/activation), that > matches the digital behavior. No, it does not match digital behavior. When you access a hierarchical digital variable, you don't get its previous value, you get its current value. > If you don't like that kind of thing > then I suggest that importing the keywords public/private to limit > access would be a good idea and adding (user-defined) methods to > modules so that you can ask for the interpolated/extrapolated value > of the variable would do the rest. The keyword would not address anybody's issues, and extrapolation would be very bad. It would lead to instability (oscillations) on large timesteps. Providing hierarchical access to analog variables was carefully considered when the language was first defined, and it was jointly agreed upon as being undesirable. Nothing has changed since then. -Ken -- 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 Jan 17 2008 - 16:43:50 PST