Re: Hierarchical references

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

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