RE: [sv-ac] notes from SV-AC meeting 2007-05-29

Hi John/all,

I thought again about - 1674:  Context value functions [EC]
  . ES submitted revised version so that inferred does not propagate.
  . JH will call for an email vote.
  . BT:  I think that other system tasks preclude user overloading.
    BT will look for the precedent for this and give feedback.  

System tasks can always be overloaded so there is no precedent for
disallowing -- What was on my mind is a thought to make assertion tasks
be like "timing checks" ones see p. 707 of draft3 for example but LRM
says $ is historical and that these are not really system tasks. The
timing checks are indeed similar in spirit to $rose/$fell etc ...  But
on 2nd thought, I don't think we want to go this route (no good reason
to), rather leave assertion ones as system tasks. Yes this would mean
overloading is allowed but typically, unless user wishes to suppress for
some reason/test e.g. a valid use (no change to original source...)
would be say disable $assertoff to keep assertions on, overloading
should enhance implementation only. It would certainly not be a wise
idea for example to change the functional behavior in general e.g.
switch $rose/$fell say. Users can make a judgement call based on their
needs here, it's ok and *useful in some cases* to leave the flexibility.

As Dmitry pointed out for $inferred set the overloading concern is
largely irrelevant (elaboration vs. runtime).

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John
Havlicek
Sent: Tuesday, May 29, 2007 11:11 AM
To: sv-ac@eda-stds.org
Subject: [sv-ac] notes from SV-AC meeting 2007-05-29

All:

My notes from today's meeting are attached.

Please let me know if changes are required.

J.H.

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