[Fwd: Re: Hierarchical references]

Fwd'ing Jonathan David's email to reflector.

-------- Original Message --------
Subject: Re: Hierarchical references
Date: Fri, 7 Dec 2007 00:49:54 -0800 (PST)
From: Jonathan David <jb_david@yahoo.com>
To: Sri Chandra <sri.chandra@freescale.com>

Sri, David, I'll pitch in my 2 cents worth here..

As a USER, here is ONE case where I would use this..
to grab values of circuit internal nodes/model variables in a 
verification "wrapper"
Here I use a wrapper, so that my (verification) sims can use a "model" 
of the circuit, or a "netlist" of
the schematic, or even a netlist of the extracted layout (including 
parasitic RLCs)
--the current LRM restricts me to what I can measure at the block ports, 
and I don't necessarily want to make
these (internal) nodes of the circuit part of the symbol ports just to 
make some measurements..
--  for VARIABLE's, typically I'd only want the "accepted" timestep value..
-- for Access functions of nodes, I might want to be able to setup an 
@cross event..
-- for hierarchically extracted  layouts, I would use this to connect 
parasitic  elements into the module without adding an internal node ( 
coupled to an external one) to the modules port list.. -- yes and I 
STILL want the multi-rate partitioner to work correctly, and the 
currents and voltage values to work "right" even if the node connected 
to isn't being evaluated on this timestep..
(silicon doesn't care if the capacitance is to a wire that is a port of 
the block or not! - so neither should my simulator.. )
-- but this third one is hardest, and I can live without for the short 
term ..
But the first two are IMPORTANT, and we should not DROP this idea 
lightly, I want it to be part of the spec, even if its hard to describe, 
and hard to make it work.. (IE only 1 or 2 simulators support this 
feature right away.. )

Jonathan

Jonathan David
j.david@ieee.org
jb_david@yahoo.com
http://ieee-jbdavid.blogspot.com
Mobile 408 390 2425

----- Original Message ----
From: Sri Chandra <sri.chandra@freescale.com>
To: David Sharrit <david@tiburon-da.com>
Cc: verilog-AMS LRM Committee <verilog-ams@eda.org>
Sent: Thursday, December 6, 2007 10:32:54 PM
Subject: Re: Hierarchical references


Hi David,

The same issue did come up in the committee meeting today with respect
to the access of the variable value. (I apologize that I didnt get some

of the names clearly and whether you were also involved in that
discussion in the call, but here is the update from the meeting).

* It seems fairly unclear about the usage of the variable access from
  an
user point of view - whether they want the "last accepted timepoint" or

"the latest iteration value" in a NR iterations. There seems to be
ambiguity in either of the choices (and i agree probably the reason for

restricting in the language) since there is no guarantee in order of
evaluation of the instances if you take the last iteration value or not

reflecting the strobe values if we go with accepted timepoint value
which might be quiet confusing.

* One of the use cases has been to have a file descriptor open and
  refer
to that variable using OOMR. However, with the proposal of analog
initial block the same feature can be achieved more cleanly through
  this
mechanism.

* As part of the discussions in the call, the plan was to send out an
email to the reflector (which i guess is this email), to seek for any
examples or models that use OOMR access for variable, the intention and

what the modeler expects in terms of the value of the variable.

So if any of you have any good examples of such an usage please post it

to the reflector. Otherwise, the current plan is to disable to access
  of
variables using out of module access.

Regards,
Sri


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






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