Re: Hierarchical references

Hello Ken,
I am hoping you can help me understand this a bit clearer.
When you mention that it is the delay that is the problem, do you mean 
returning the value of a variable at time n when probing it at time n+1 is a 
bad thing?

Since we have the restriction that OOMR probes on real variables will not 
propagate partial dependencies what is the danger other than the fact the value 
is a timestep old?

It is no worse than if a user does:
   analog begin
     y = x;
     x = x + 1;
   end

Trivial example, but here y will always be assigned the previous timestep value 
of x.

Regards
Dave


Ken Kundert wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>>   
> 

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