[sv-ac] 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.