[sv-ac] RE: uploaded proposal for 3295

Hi Erik,

- I am fine with symbolic values but I do not see any such precedent in
the LRM. If we define such symbolic names then those names become part
of keywords list and become reserved words. This may not be acceptable.
I am going to make the change such that the values are like 0x1, 0x2
(exclusive bits) so that they can be combined by ORing them. The user
has the flexibility to do `define and use the names as suggested by you.

- One suggestion from Anupam was to have only one task and take
on/off/kill as argument. The name would be like $assertcontrol and first
argument would be on/off/kill value. Does that sound better ? Or if we
keep separate tasks then names like $assertcontrolon, $assertcontroloff
etc. are possible. Do you have any suggestion for name ?

- I'll make the name change to legacy.. for the old tasks. Are they
deprecated ?

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.