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.Received on Wed Jan 16 13:15:19 2008
This archive was generated by hypermail 2.1.8 : Wed Jan 16 2008 - 13:15:35 PST