Re: [sv-dc] RE: SV-DC agenda for 2015.02.27

On 2/26/15 4:15 PM, Steven Sharp wrote:
>
> I assumed that “Global variable access” was intended to mean access to 
> anything but local variables of the function, which I believe is the 
> current restriction.  These might not actually be global variables.
>

Oh, yes, I agree.  Using an "instance variable" or other mutable state 
would have
similar issues.  I think the context of most of the discussion has been 
with nettypes
and resolution functions with assumption of a "package" or "global" 
context.  Not
a necessary assumption, but probably just a bit of simplification that 
has slipped
into the discussion over time.

The current LRM wording is the wording we've used in other places:
A resolution function shall be automatic (or preserve no state 
information) and have no side effects.
So that allows "global" reads (which I'm pretty sure was not the 
intent!).  But it wouldn't
allow writes.  Up until now, most arguments in favor of writes have 
appeared to be
debug related.

I certainly think that reading of a constant expressions is fine in a 
resolution function.
Reads of simulation time mutable state would introduce potentially 
problematic
race behavior for the user.
IEEE Std 1800™-2012 (Revision of IEEE Std 1800-2009) IEEE Standard for 
SystemVerilog—Unified Hardware Design, Specification, and Verification 
Langua
Gord



> *From:*owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] *On Behalf Of 
> *Gordon Vreugdenhil
> *Sent:* Thursday, February 26, 2015 7:12 PM
> *To:* O'Leary, Martin; Little, Scott; sv-dc@eda.org
> *Subject:* Re: [sv-dc] RE: SV-DC agenda for 2015.02.27
>
> On 2/26/15 3:07 PM, O'Leary, Martin wrote:
>
>     Hi,
>
>     I have some questions on some of the items in the roadmap as it
>     wasn’t exactly clear what was meant from the minutes.
>
>     Thanks,
>
>     --Martin
>
>     R08. [] Allow sensitivity to aggregates in event controls
>
>     R10. [] Event sensitivity to UDNs
>
>     What is the precise difference between the above two items? – they
>     seem pretty similar
>
>
> They are.  R08 is probably a bit more general in that it would
> impact variable or other aggregate expressions as well, not
> just UDNs.
>
>
>     R11. [] Global variable access in resolution functions
>
>     What is a global variable is SV – does this instead mean
>     hierarchical references?
>
>
> "Global" is a bit imprecise -- "compilation unit" (or package) is better.
>
> Ex:
>
> int some_thing;
> module top;
>      child c1();
>      child c2();
> endmodule
> module child;
>      initial some_thing++
> endmodule
>
> In this case, some_thing is a "compilation unit" variable that is directly
> visible within the modules (etc) compiled "at the same time".  The LRM
> talks about a couple of models for what "at the same time" means and
> vendors have various behaviors that more or less align with the models.
>
> If you have a compilation unit that spans the entire design, then
> some_thing would in fact be a "global" variable.
>
> Gord
>
>
>
>     *From:* owner-sv-dc@eda.org <mailto:owner-sv-dc@eda.org>
>     [mailto:owner-sv-dc@eda.org] *On Behalf Of *Little, Scott
>     *Sent:* Wednesday, February 25, 2015 3:48 PM
>     *To:* sv-dc@eda.org <mailto:sv-dc@eda.org>
>     *Subject:* [sv-dc] SV-DC agenda for 2015.02.27
>
>     Please note that the conference ID is different from previous
>     meetings.
>
>     I have added a few potential work items to discuss.  One is a
>     follow-up from last meeting.  The others are new items that were
>     discussed in the last round and have been requested internally at
>     Intel recently.  Hopefully those discussions will be quick. 
>     Please let me know if there are other items.
>
>     As Gord mentioned in the last meeting please take a bit of time to
>     think about your bandwidth to do proposal work in the upcoming
>     PAR.  Meeting attendance is great but to move forward folks will
>     have to commit time outside of the meetings.  I think it would be
>     useful in the time estimates to assign 1-2 owners for each
>     proposal we consider a must do.  These owners can then look at
>     what they are expected to do during the PAR and wager a guess at
>     the amount of time it may take to complete them.
>
>     Thanks,
>
>     Scott
>
>     Agenda:
>
>     1.IEEE patent policy
>     (http://standards.ieee.org/board/pat/pat-slideset.ppt)
>
>     */Please read the above content if you aren't familiar with it
>     already./*
>
>     2.Minutes Approval
>
>     3.Discuss potential work items
>
>     a.Strings in UDNs [MartinO]
>
>     b.Late binding of resolution functions [ScottL]
>
>     c.State in resolution functions [ScottL]
>
>     4.Roadmap document [http://goo.gl/OOI0gN]
>
>     a.Prioritize work items
>
>     b.Discuss bandwidth of participants
>
>     c.Estimate time required for work items
>
>     Upcoming dates to note:
>
>     2015-02-27 - SV-DC meeting
>
>     2015-03-06 - P1800 Working Group Meeting
>
>     Dial-in Information:
>
>     US: 1 888 875 9370
>
>     India: 1 800 425 2663 (or) 080 2520-8990
>
>     Israel: 08-666-2663
>
>     Eindhoven: +31 4080 02004
>
>     Bridge: 5 Conference ID: 293521529
>
>     .........................................................................................................................................
>
>     àJoin Lync Meeting <https://meet.intel.com/scott.little/7PYH2JNJ>
>
>     Join by phone
>
>     +1(916)356-2663 (or your local bridge access #) Choose bridge 5.
>     <tel:+1%28916%29356-2663%20%28or%20your%20local%20bridge%20access%20#%29%20Choose%20bridge%205.>
>     (Global)         English (United States)
>
>     Find a local number <https://dial.intel.com>
>
>     Conference ID: 293521529
>
>     Forgot your dial-in PIN? <https://dial.intel.com>|Help
>     <http://o15.officeredir.microsoft.com/r/rlidLync15?clid=1033&p1=5&p2=2009>
>
>     _[!OC([1033])!]
>
>     .........................................................................................................................................
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean.
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean.
>
>
>
> -- 
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Verification Technologies, Mentor Graphicsgordonv@model.com  <mailto:gordonv@model.com>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Verification Technologies, Mentor Graphics        gordonv@model.com


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