RE: Hierarchical references

Hi David,

    With your example, I think it should be relatively easy to explain to
the user why that model, while perhaps technically valid, is a very bad, and
generally useless, thing to do in a model that is to be used in a general
Spice like simulator.  The value of x, as well as the relationship between y
and x, would be totally dependent on the simulator's timestep algorithm, and
be completely variable from one simulator to another, and even from one
application to another.  And that's the biggest concern I have with this
proposal ... it has no physical, simulator independent, definition of what
the results should be.   With this OOMR proposal, we could end up with

y = x;
meaning something totally different than
y = m1.m2.x;

The former means what it says, but the latter means
y(t) = m1.m2.x(t-tstep).

I suppose the system function approach avoids this obvious contradiction,
and also makes it clear that we're not trying to also support

m1.m2.x = y;

but it certainly seems awkward, has the multiple-type issues that you point
out, but most significantly, has no real definition (use?) in the world of
continuous, time-varying signals.  As Ken as pointed out, this should be
limited to piece-wise constant signals, which is the domain of the digital
side of the AMS language.

> >> When accessing an OOMR variable in an analog initial block, then it
> >> should return 0.

This definition would really be counter-intuitive to users.  Given the only
truly valid use of OOMR variable access in the analog domain is for static,
constant signals, having them always return 0 in an initial block would be
totally unexpected and problematic.

I'd also like to re-iterate my previous point that not only does this
feature have no accurate definition for continuous, time-varying signals in
transient simulations, it would be guaranteed to result in models that have
fundamental inconsistencies between AC and transient and probably even DC
and steady-state transient, not to mention all the issues with noise and
other frequency domain simulations.  It's not modeling anything physical.

Lastly, although not as critical, I thought I'd mention the point that this
feature would probably have to be disabled in highly optimized VerilogA
compilers.  The industry could end up in a situation where previously
compiled models may or may not work in a design, depending on whether or not
it was compiled with read access/optimization disabled.  While this issue
does already exist in the cases of debugging and using VPI access, those
cases seem more easily explained and easier to deal with than this OOMR
variable reason.

David

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of David Miller
> Sent: Thursday, December 20, 2007 1:50 PM
> To: Verilog-AMS LRM Committee
> Cc: Ken Kundert
> Subject: 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.


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