RE: [sv-ac] final final final proposal 19

Subject: RE: [sv-ac] final final final proposal 19
From: Bassam Tabbara (bassam@novas.com)
Date: Mon Jan 19 2004 - 14:39:39 PST

John, the second comment from Brad (calling methods) does catch an
oversight. May be you can just take out the words "system task" and just
keep things as tasks and void functions (to cover also system (aka built-in)
and other methods ...), but just a quick suggestion. If you think it's
better to list everything explicitly then I'm all for it too.

Thx.
-Bassam. 

--
Dr. Bassam Tabbara
Technical Manager, R&D
Novas Software, Inc.

http://www.novas.com
(408) 467-7893

> -----Original Message-----
> From: owner-sv-ac@server.eda.org 
> [mailto:owner-sv-ac@server.eda.org] On Behalf Of Faisal Haque
> Sent: Monday, January 19, 2004 9:14 AM
> To: sv-ac@server.eda.org
> Subject: FW: [sv-ac] final final final proposal 19
> 
> 
> John,
> Please take a look and let me know.
> Thanks.
> -Faisal
> 
> -----Original Message-----
> From: David W. Smith [mailto:David.Smith@Synopsys.COM] 
> Sent: Friday, January 16, 2004 3:00 PM
> To: 'Karen Pieper'; Faisal Haque; johny.srouji@intel.com; 
> Arif.Samad@Synopsys.COM
> Cc: 'Surrendra A Dudani'
> Subject: FW: [sv-ac] final final final proposal 19
> 
> 
> Greetings,
> Brad Pierce is working on leaving on vacation for the next 
> two weeks. In his final clean-up has generated a suggestion 
> for proposal 19 in SV-AC that is dependent on an SV-BC issue. 
> I would suggest that this is an inter-committee dependency 
> between the two committees that you need to handle.
> 
> Assuming both get approved then this needs to be handled and 
> then sent to me as an LRM change.
> 
> Regards
> David
> 
> -----Original Message-----
> From: Brad Pierce [mailto:bpierce@Synopsys.COM] 
> Sent: Friday, January 16, 2004 2:58 PM
> To: David W. Smith
> Subject: Re: [sv-ac] final final final proposal 19
> 
> David,
> 
> If the following cleanup proposal is approved by the SV-BC
> 
     http://www.eda-twiki.org/sv-bc/hm/att-1473/01-subroutine.htm

then I would suggest replacing the proposed sequence_match_item with

      sequence_match_item ::=
            variable_assignment
      |     subroutine_call

Restrictions on the kind of subroutines that can be attached should ideally
be semantic checks described in the body of the LRM, like the restrictions
on the kinds of functions allowed in statements.

Also, I wonder why the proposed section "Calling subroutines
on a match of a sequence" does not allow method calls.

-- Brad

-----Original Message-----
From: David W. Smith [mailto:david.smith@synopsys.COM]
Sent: Thursday, January 15, 2004 9:11 AM
To: 'Brad Pierce'
Subject: FW: [sv-ac] final final final proposal 19

Here is proposal 19.

Regards
David

This archive was generated by hypermail 2b28 : Mon Jan 19 2004 - 14:46:35 PST