Re: Hierarchical references

All,
    It seems like we are missing the point. It is the delay that is the
issue, not the mechanism used for accessing the value. The delay is
nonphysical and difficult to control. As a result, it does not make
sense for values that change continuously. It only make sense for those
that are piecewise constant. And we currently have the ability to
hierarchically access piecewise constant variables as long as they are
owned by the event-driven kernel.

Consider the following alternative. Let's maintain the current
restriction on hierarchical access to variables owned by the
continuous-time kernel, and instead make it easier to access those
values from the discrete-time kernel. In doing so, we would be
addressing two serious deficiencies in the language.

Let me give you an example ...

Consider the situation where one wants to have a single variable that
indicates the status of a module that you can access hierarchically.
Call the variable "fault" and make it 1 if the module is being used
improperly and 0 otherwise. Further consider that there are two ways in
which the module could be improperly used: if set and reset are both
applied simultaneously, and if the supply voltage is less than 1V. One
of these fault conditions is naturally handled by the event-driven
kernel, and the other by the continuous-time kernel.

wire fault;
integer faultVdd;
assign fault = (set && reset) || faultVdd;
analog faultVdd = V(dd) < 1;

The problem is, that this is not allowed in VerilogAMS. You cannot have
a variable owned by the continuous-time kernel in either a continuous
assignment statement or as a trigger to an @ statement unless it is
protected by a cross function.

So, my suggestion is to allow variables, both integers and reals, that
are owned by the continuous-time context, to be used in continuous
assign statements and in @ triggers. Then using this method, one could
easily copy values that are to be shared, like the fault variable in the
example, into the discrete-time context.

-Ken

David Miller wrote:
> Hi Sri,
> just a couple of quick comments.
> No problem if you want to restrict it to accessing the last accepted
> time step value. We can always revisit this in later versions of the LRM
> once people have the opportunity to use the feature and we get some
> feedback.
> 
> During the initial step (t = 0) the value returned should be the value
> of the variable at time -0. I mean if I assign to a variable in the new
> analog initial block construct, I should have access to that value when
> executing an initial step.
> 
> When accessing an OOMR variable in an analog initial block, then it
> should return 0.
> 
> What was the reason for the system task? It doesn't seem it serves any
> purpose:
> x = inst1.inst2.y;
> x = $new_systask(inst1.inst2.y);
> 
> This has the same underlying behaviour.
> The system task would mean you need to have a different once for
> integers, reals and strings. Also means that OOMR of variables inside
> digital blocks vs analog blocks would be different.
> 
> Sorry I missed the call last week, but I would be interested in hearing
> the reason for the systask, maybe I am missing something.
> 
> Cheers...
> Dave
> 
> Sri Chandra wrote:
>> Hi all,
>>
>> As part of the last Verilog-AMS committee meeting there was one more
>> suggestion to resolve the issue of accessing hierarchical variables
>> (using out of module reference).
>>
>> The proposal was to disallow accessing the variables hierarchically
>> but instead provide a system task mechanism which takes in the
>> variable in hierarchical format as an argument to return its value.
>> The value returned by the system task would be the value of the
>> variable at the last accepted time point, and if the system task is
>> used in the initial_step we can return a value of 0 as new time
>> evaluation has taken place.
>>
>> cheers,
>> Sri
>>
>> K. Cameron [SV] wrote:
>>> David Sharrit wrote:
>>>>> When accessing variable values and probes on named branches the
>>>>> value as
>>>>> per the last iteration shall be returned (to avoid race conditions)
>>>>> and
>>>>> without affecting any partial dependencies.     
>>>
>>> I thought the "race condition" argument had been debunked, i.e.
>>> analog processes are solved with a copy-in/copy-out semantic that
>>> means the only possible race condition is during the copy-out.
>>>
>>> I'm also losing track of how many times we've been round through
>>> this: there shouldn't be any semantic difference between
>>> branches/variables accessed locally or through OOMRs - if there is it
>>> will just cause unnecessary errors.
>>>
>>> Kev.
>>>
>>>>
>>>> Perhaps I'm just confused, but even after I consider this to just be
>>>> talking
>>>> about variable values, I'm still uncertain and concerned as to what
>>>> this is
>>>> really trying to do or provide.  What exactly is the "value as per
>>>> the last
>>>> iteration"?  Presumably that is, or could be, the previous time
>>>> point value
>>>> in a transient simulation.  For a time varying variable, will that not
>>>> result in fairly unpredictable and inconsistent results, as it will
>>>> depend
>>>> on the particular timestep involved? And what does it even mean for
>>>> other
>>>> analysis types, such as AC or HB or even DC?  Without derivative
>>>> information, it seems you could either be introducing convergence
>>>> failures
>>>> with incorrect Jacobians, or inconsistent (incorrect) results, with
>>>> state
>>>> variable dependencies seeming to exist in transient simulations but
>>>> not in
>>>> AC simulations.
>>>>
>>>> It seems there were some major reasons why OOMR access to variable
>>>> values is
>>>> disallowed in the present LRM, and I don't yet see how these issues
>>>> have
>>>> been cleanly, accurately or practically resolved.
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>   
>>>
>>
> 

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