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. 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. 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. -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 - 01:09:47 PST