Re: [sv-ec] RE: [sv-ac] hierarchical references into programs

Hi Shalom:

We discussed these proposed changes in the SV-AC meeting 
on 2007-10-09, and there was no objection to SV-BC and SV-EC
moving ahead with them. 

Please proceed.

J.H.

> X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda.org using -f
> X-ExtLoop1: 1
> X-IronPort-AV: E=Sophos;i="4.21,242,1188802800"; 
>    d="scan'208";a="166729767"
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Mon, 8 Oct 2007 15:36:27 +0200
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ec] RE: [sv-ac] hierarchical references into programs
> Thread-Index: AceyeDX1x8BXmGjoQ1WvjXByG7hTPxUwoRmwAJwPOTAAATTNMA==
> From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> X-OriginalArrivalTime: 08 Oct 2007 13:36:29.0021 (UTC) FILETIME=[3B1560D0:01C809B0]
> X-eda.org-MailScanner: Found to be clean, Found to be clean
> X-Spam-Status: No, No
> X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda-stds.org id l98DbgvB016301
> Sender: owner-sv-ac@eda.org
> X-eda.org-MailScanner-Information: Please contact the ISP for more information
> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> 
> In general yes, since the section is about 'bind'.  
> However, this particular paragraph talks about programs, which belong to
> SV-EC, and assertions, which belong to SV-AC.
> SV-EC and SV-BC are well co-ordinated, since there is a lot of overlap
> between the participants.
> But it is important to hear whether SV-AC has a problem with the issue
> and the proposed change.
> 
> Thanks,
> Shalom 
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda.org 
> > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Lisa Piper
> > Sent: Monday, October 08, 2007 3:01 PM
> > To: Bresticker, Shalom; sv-ac@server.eda-stds.org; 
> > sv-ec@server.eda.org
> > Subject: [sv-ec] RE: [sv-ac] hierarchical references into programs
> > 
> > Shalom,
> > 
> > Who is responsible for taking care of this? My understanding 
> > was that after 1722 this section (22.10) would be owned by 
> > sv-bc.  Is that correct?
> > 
> > Lisa
> > 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> > Behalf Of Bresticker, Shalom
> > Sent: Friday, October 05, 2007 6:44 AM
> > To: sv-ac@eda-stds.org; sv-ec@eda.org
> > Subject: [sv-ac] hierarchical references into programs
> > 
> > Hi,
> > 
> > I corresponded with Gord a few months ago about the following issue:
> > 
> > All the references are to Draft 4:
> > 
> > 23.5 says,
> > "Calling program tasks or functions from within design 
> > modules is illegal and shall result in an error."
> > 
> > (Probably the word 'design' should be stricken as there is no 
> > concept of 'design modules' and 'non-design module'.
> > 
> > 23.3 says,
> > "References to program signals from outside any program block 
> > shall be an error."
> > 
> > 23.6 says,
> > "The set of program definitions and instances define a space 
> > of programwide data, tasks, and functions that is accessible 
> > only to programs."
> > 
> > Thus, in Gord's words: "The LRM does not allow ANY 
> > hierarchical references from modules to programs."
> > 
> > Yet, 22.10 says,
> > "By binding a program to a module or an instance, the program 
> > becomes part of the bound object. The names of 
> > assertion-related declarations can be referenced using the 
> > SystemVerilog hierarchical naming conventions."
> > 
> > In the context, the meaning seems to be that the 
> > 'assertion-related declarations' (whatever that means) are in 
> > the program, and the hierarchical reference is from outside 
> > the program to inside the program.
> > 
> > This is illegal, however.
> > 
> > Thus, this statement in 22.10 should be changed. Gord 
> > suggests adding the following sentence in 22.10:
> > 
> > "Hierarchical references to an item in a bound instance are 
> > permitted following normal hierarchical naming rules."
> > 
> > Thanks,
> > Shalom
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> > 
> > This e-mail and any attachments may contain confidential 
> > material for the sole use of the intended recipient(s). Any 
> > review or distribution by others is strictly prohibited. If 
> > you are not the intended recipient, please contact the sender 
> > and delete all copies.
> > 
> > --
> > 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.
> > 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> -- 
> 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.