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

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.

cheers,
Sri

K. Cameron wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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
>> >
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> &subject=Re:_Clause_6.6.1:_Usage_of_Hierarchical_references_(revised_version)&date=1200609362\n
> iD8DBQFHj9hAXcIvCtlnEMERAkSjAJ9tefHvaKha4CXCce5Yn+IOF3vrigCdGhYt
> adR+/f5jwW51Erqnsm3XqAQ=
> =1uiX
> -----END PGP SIGNATURE-----
> 

-- 
Srikanth Chandrasekaran
Design Technology (Tools Development)
Freescale Semiconductor Inc.
T:+91-120-439 5000 p:x3824 f: x5199

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.