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 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 : Wed Jan 16 2008 - 10:10:00 PST