Re: Hierarchical references

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

-- 
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================

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