[sv-ac] RE: uploaded proposal for 3295

Hi,

I have uploaded another version addressing some of the comments from
Erik and others.

Thanks.
Manisha

-----Original Message-----
From: Seligman, Erik [mailto:erik.seligman@intel.com]
Sent: Tuesday, February 15, 2011 3:00 AM
To: Kulshrestha, Manisha; sv-ac@eda.org
Subject: RE: uploaded proposal for 3295

Manisha-- A few comments:

- Can we define symbolic values for the constants used in the
assertion_type and directive_type tables? Something like
ASSERTION_TYPE_CONCURRENT, ASSERTION_TYPE_IMMEDIATE, etc.

- Can we come up with better names for the new functions? I'm not sure
it's such a good idea having two related functions with similar names
like $asserton and $assertionon.

- In the grammar, maybe we should replace assert_control_task with
something like legacy_assert_control_task. Similar to the above point,
I think having both assert_control_task and assertion_control_task in
the grammar might lead to confusion.

- Would it be possible to rephrase the section to solely be describing
the new, more general, $assertion* functions, and then at the end add
something like this?

Legacy functions $asserton, $assertoff, and $assertkill are also
provided for backwards-compatibility. They are defined as follows:
-- $asserton(levels[,list]) ==
$assertionon(levels,ASSERTION_TYPE_ALL,DIRECTIVE_TYPE_ALL[,list])
...

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Kulshrestha, Manisha
Sent: Monday, February 14, 2011 2:28 AM
To: sv-ac@eda.org
Subject: [sv-ac] uploaded proposal for 3295

Hi,

I have uploaded a proposal for 3295. Please review and send your
feedback.

Dimitry, probably this proposal can be included for discussion in the
next meeting if there is enough time available.

Thanks.
Manisha

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