Re: Clause 6.6.1: Usage of Hierarchical references (revised version)

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.
2. The analog domain should be able to gracefully handle x & z.
3. One should be able to use full digital expressions in an analog @ 
expression.
4. One should be able to use named events in analog @ expressions.
5. The analog domain should be able to assign to registers.
I am using the language on a daily basis to verify designs, and this is 
the kind of thing that I find most troubling.

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.

-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.