-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With copy-in/copy-out semantics for analog process evaluation that's what you get anyway. What's the problem with initial_step that it needs special handling? A lot of Verilog test-benches use OOMRs to probe a design. AMS is supposed to allow plug-&-play so that you can swap implementations from digital to analog without changing the parent modules, putting restrictions on OOMRs will break that. Kev. 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 >>> >>> >>> >>> >> > - -- http://www.grfx.com mailto:dkc@grfx.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHarWeXcIvCtlnEMERArCyAJ4n9na1ig85Ui6YDw3+xyFOmrzFFgCeMplR qnl0g3e7zSt9VQwYDe322MQ= =KRdy -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Dec 20 10:40:20 2007
This archive was generated by hypermail 2.1.8 : Thu Dec 20 2007 - 10:40:23 PST