Kevin & All, Most of what I am proposing is neither specifically excluded by the LRM nor specifically included in the LRM. I suggest that rectify the situation by including language in the LRM that specifies that this functionality should be supported. I do not have proposed changes for the LRM. Is that what it would take? Given all that I have going on at the moment, it would be difficult for me to do that in a timely manner, but if nobody else is able to it and that is that it takes, I can certainly work to put it together. -Ken K. Cameron wrote: > Ken Kundert wrote: >> Kevin, >> In Section 8.2.2 of LRM 2.2 you will find the following statements: >> >> A given variable can be assigned values only in one context or the >> other, but not in both. The domain of a variable is that of the >> context from which its value is assigned. > > IMO that's a fairly arbitrary restriction that could be lifted. > >> >> I understand that in either context, you can read the value of a >> variable from the other context. My issues center more around >> events. For example, the fact that the only way a change in value in >> an analog variable can trigger a digital event is by way of a >> threshold crossing is very limiting. > > Is that excluded by the LRM or just not supported? > >> This makes sense for continuously varying values, but not all analog >> values very continuously. And integers, which can be owned by the >> analog context, never vary continuously. I would really like to be >> able to trigger the digital context based only on any change in an >> analog variable value. > > Nothing actually varies continuusly in the simulator, either it's an > analytic function that is predetermined in time or its PWL and the > derivatives change discretely: I think we need a better definition of > "continuously varying values". > > Given that analog evaluation is essentially another event-driven > process that gets evaluated with copy-in/copy-out semantics, I don't > see why the copy-out phase can't trigger digital processes with > variable changes. > > Do you have a proposal for LRM changes? > > Kev. > >> >> -Ken >> >> K. Cameron wrote: >> > Sri Chandra wrote: >> >> Kevin, >> >> >> >> With regards to the definition of what constitutes and analog >> >> variable, if i understand correctly, a variable can not be assigned >> >> in both the context - analog & digital. Even if the variable is >> >> declared at the module level, we look at the context in which it is >> >> assigned. >> > >> > I understand that that is what is implied but I'm not sure that it >> > is clearly defined anywhere, and the implication of your statement >> > is that a variable could be assigned by either context and read by >> > the other - which Ken doesn't seem to think works. >> > >> > Since no processes (analog or digital) are actually evaluated >> > continuously or concurrently there is no real reason to consider >> > variables as belonging specifically to either domain. >> > >> > Kev. >> > >> >> >> >> cheers, >> >> Sri >> >> >> >> K. Cameron wrote: >> >> Ken Kundert wrote: >> >> >>> Kevin, Getting a value from some indeterminant point from the >> >> past >> >> >>> on a continuously varying variable is worse than worthless. >> >> It is a >> >> >>> user trap. Since the value is continuously changing, and you >> >> have >> >> >>> no control of when the value is sampled, the value you get has >> >> >>> little meaning. People will not expect this behavior, and >> >> will be >> >> >>> confused by it. >> >> >>> >> >> >>> I want to point out that I do a lot of simulations where the >> >> analog >> >> >>> sits quiescent for long periods of time, or moves very slowly >> >> >>> relative to the activity in the event-driven kernel (think of >> >> slow >> >> >>> smooth analog signal driving a delta sigma modulator). In this >> >> >>> case, the previous analog time point could be thousands of clock >> >> >>> cycles in the past. >> >> >>> >> >> >>> It only make sense with piecewise constant variables. And the >> >> only >> >> >>> way to assure that is to only allow access to digital variables. >> >> >>> >> >> >>> You ask what my issue is. I have two. The first is I don't >> >> believe >> >> >>> we should provide hierarchical access to analog variables. The >> >> >>> second is that I think we should provide greater access >> >> between the >> >> >>> two domains, particularly from the digital into the analog >> >> domain. >> >> >>> For example, 1. One should be able to use analog variables in >> >> >>> digital @ expressions and continuous assigns. >> >> >> >> Do you mean you want to be sensitive to an analog variable changing? >> >> >> >> However, looking at the LRM I'm not sure there is a definition of >> >> "analog variable". If we are mixing analog and digital processes in a >> >> module then the only thing that could be considered a purely "analog" >> >> variable would be something declared in an analog block, but most of >> >> the examples in the LRM declare variables at module level. >> >> >> >> >>> 2. The analog domain should be able to gracefully handle x & z. >> >> >> >> Great - I get to resurrect the NaN argument for the Nth time :-) >> >> >> >> >>> 3. One should be able to use full digital expressions in an >> >> analog >> >> >>> @ expression. >> >> >> >> I see no problem with that. >> >> >> >> >>> 4. One should be able to use named events in analog @ >> >> expressions. >> >> >> >> I see no problem with that either >> >> >> >> >>> 5. The analog domain should be able to assign to registers. >> >> >> >> Shouldn't be a problem either. >> >> >> >> >>> I am using the language on a daily basis to verify designs, and >> >> >>> this is the kind of thing that I find most troubling. >> >> >> >> I seem to remember those are all the sort of things you voted against >> >> when you were actually in charge of the simulator development back at >> >> Cadence - what goes around comes around :-) >> >> >> >> >>> >> >> >>> There are innate differences between analog and digital that >> >> force >> >> >>> us to provide different simulation mechanisms. But because of >> >> our >> >> >>> starting with Verilog-A, there is more separation between the >> >> two >> >> >>> parts of the language than there needs to be, and it causes >> >> people >> >> >>> real pain. It would be nice to bring the two closer together. >> >> >> >> If you view connected analog processes as an event driven >> >> macro-process (Section 8.3.3 in the LRM) then there really isn't that >> >> much difference between analog and digital. Nothing is continuously >> >> evaluated. >> >> >> >> 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. >> >> >> >> 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. 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. 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. >> >> >> >> BTW, it should be possible to do a whole lot of things in a purely >> >> digital simulator with PWL signals, but nobody has proposed >> >> supporting >> >> that yet. >> >> >> >> Kev. >> >> >> >> >>> >> >> >>> >> >> >>> -Ken >> >> >>> >> >> >>> >> >> >>> Kevin Cameron wrote: >> >> >>> > Ken Kundert wrote: >> >> >>> >> Sri, I strongly believe that hierarchical access to analog >> >> >>> >> variables is a bad idea, and we would be better served by >> >> >>> >> making it easier to transfer analog values into the digital >> >> >>> >> context where they could be accessed hierarchically using >> >> >>> >> existing capabilities. Right now the biggest weakness in the >> >> >>> >> language, besides the incomplete and flawed >> >> implementations, is >> >> >>> >> the lack of access to analog values from the digital context. >> >> >>> >> That is what we should fix before we release 2.3. >> >> >>> >> >> >> >>> >> -Ken >> >> >>> > >> >> >>> > That doesn't entirely make sense to me. Seems a likely use of >> >> >>> > OOMRs that you would want to work is accessing analog variables >> >> >>> > from digital testbench processes. Given that the simulation >> >> >>> > semantics don't actually allow real concurrency, I can't see >> >> any >> >> >>> > reason for not allowing direct access to "analog" variables >> >> from >> >> >>> > digital either locally or through OOMRs. >> >> >>> > >> >> >>> > Is your issue that changing a variable (via OOMR) from a >> >> digital >> >> >>> > process doesn't trigger re-evaluation of analog processes that >> >> >>> > use it? (Not that it should IMO). >> >> >>> > >> >> >>> > Kev. >> >> >>> > >> >> >>> >> Sri Chandra wrote: >> >> >>> >>> Hi all, >> >> >>> >>> >> >> >>> >>> There have been various discussions & mails on the reflector >> >> >>> >>> with regards to hierarchical references using >> >> >>> >>> Out-Of-Module-References (OOMR). There have been couple of >> >> >>> >>> things that need to be resolved from the previous proposal >> >> >>> >>> that have been outstanding before we can include it in >> >> >>> >>> LRM2.3, and also I thought we can make this section more >> >> >>> >>> complete in terms of what can and cannot be accessed >> >> >>> >>> hierarchically using OOMR. >> >> >>> >>> >> >> >>> >>> So the changes from the previous version (I have attached the >> >> >>> >>> new proposal below) >> >> >>> >>> >> >> >>> >>> 1/ Behavior of variable OOMR - What should be the returned >> >> >>> >>> value? - Syntax - dot syntax vs system function: To make the >> >> >>> >>> syntax consistent between digital & analog i think its >> >> >>> >>> preferable to use the "dot notation" rather than introducing >> >> >>> >>> a new system task. - Handling variable OOMR for initial step >> >> >>> >>> and block. - Handling for non-transient simulations? >> >> >>> >>> >> >> >>> >>> 2/ There was a request to allow voltage probe on unnamed nets >> >> >>> >>> using OOMR as this is a very useful feature for AMS >> >> >>> >>> verification and test bench development. >> >> >>> >>> >> >> >>> >>> 3/ Make the section more complete including parameters, port >> >> >>> >>> branch, implicit branches etc. >> >> >>> >>> >> >> >>> >>> There are some restrictions that are included in this >> >> >>> >>> proposal to keep the usage and restrictions simple and clean. >> >> >>> >>> We can possibly relax some of these restrictions in the next >> >> >>> >>> revision when we have more detailed discussion & intended >> >> >>> >>> behavior. Hopefully we can close in on this section soon to >> >> >>> >>> be included as part of LRM2.3 as we are fairly close to >> >> >>> >>> getting this LRM version completed very soon. >> >> >>> >>> >> >> >>> >>> Considering the above I have taken another shot at proposal >> >> >>> >>> for Clause 6.6.1. >> >> >>> >>> >> >> >>> >>> ============= New Proposal >> >> >>> >>> ============================================ >> >> >>> >>> >> >> >>> >>> Section 6.6.1: Usage of hierarchical references >> >> >>> >>> >> >> >>> >>> The following usage rules and semantic restrictions will be >> >> >>> >>> applied to analog identifiers referred hierarchically using >> >> >>> >>> OOMR in a mixed signal module >> >> >>> >>> >> >> >>> >>> * Potential & flow access for named branches can be done >> >> >>> >>> hierarchically * Potential access for unnamed branches can be >> >> >>> >>> done hierarchical, however the nets should belong to the same >> >> >>> >>> domain, otherwise it shall be an error. * Hierarchical >> >> >>> >>> reference of an implicit net is allowed when the referenced >> >> >>> >>> net is first coerced to a specific discipline * Access of >> >> >>> >>> analog variable values can be done hierarchically. The value >> >> >>> >>> of the variable shall be as per the last accepted time point. >> >> >>> >>> * Access of parameters can be done hierarchically. However, >> >> >>> >>> access of parameters using OOMR shall be disallowed as part >> >> >>> >>> of parameter declaration statements. * Analog user defined >> >> >>> >>> functions can be accessed hierarchically. * It shall be an >> >> >>> >>> error to access the flow of an unnamed hierarchical branch. * >> >> >>> >>> It shall be an error to hierarchically reference port >> >> >>> >>> branches * It shall be an error to have potential & flow >> >> >>> >>> contributions to named or unnamed branches hierarchically * >> >> >>> >>> It shall be an error to assign to a variable using >> >> >>> >>> hierarchical notation >> >> >>> >>> >> >> >>> >>> Accessing variable values hierarchically does not affect any >> >> >>> >>> partial dependencies and are purely considered as value >> >> >>> >>> access. Any OOMR reference to variables in analog initial >> >> >>> >>> block shall return 0, and for OOMR references in initial_step >> >> >>> >>> the return value will be the variable value at time t=0. In >> >> >>> >>> case of non-transient analysis, the DC value of the variable >> >> >>> >>> shall be returned for AC, HB analysis. In the case of dcsweep >> >> >>> >>> analysis the value returned shall be the calculated value at >> >> >>> >>> the conclusion of the operating point analysis of the >> >> >>> >>> previous dc point. >> >> >>> >>> >> >> >>> >>> Hierarchical references to analog branches, nets and >> >> >>> >>> variables and can be done in both analog as well as digital >> >> >>> >>> blocks. >> >> >>> >>> >> >> >>> >>> >> >> > ========================================================================= >> >> >> >> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> cheers, Sri >> >> >>> > >> >> >> >> > >> > >> > > > -- 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 : Fri Jan 18 2008 - 15:29:08 PST