RE: [SPAM] - [sv-cc] Proposal for #431 uploaded - Email found in subject

Hi All,

Thanks Michael for the serious effort munging these 2. I'd like to make
a few comments.

1) Assuming we do this: The ticket is quite reasonable given its
motivation (save namespace) [albeit please see (2) I also am against
this], and Michael's proposal is indeed the way I would've done it too
:-). The proposal needs several fixups. Minor things are for example
changing the "start"/"stop" legacy words in text to "enable"/"disable".
Major fixes include calling something like vpi_control(..kill.., NULL,
attempStartTime). The last argument does not make sense needs to be take
out since:
 a) The system disable would apply to everything ... Not the particular
assertions with attemptStartTime
 b) I my mind, I think it is best to reserve the function (future
enhancement not now) as above  vpi_control(..kill.., NULL,
attemptStartTime) to REALLY disable all the "assertions"
(assertion/property/sequence (not that sequences could have multiple
threads within that are "in-flight")) **with that attemptStartTime**. So
it is a valid function that needs to be reserved i.e. take out
attemptStartTime from here.

2) I am also against this change because while motivation of (1) is
valid, the change is rather short-sighted. For example it is quite
likely that a user might inadvertently or even because of some specific
engine failure (returning NULL to the handle e.g. say sequence handle
and particular engine does not support that), the kill could end up
instead of being "harmless", quite destructive in nature after the
change. The overloading here has a very serious destructive nature so
it's worth "keeping it simple" and paying for some extra #defines. That
said, I disagree with the "polluting name space" stmt in bugID, I do get
the spirit of ticket to "add only what's necessary" and yeah in this
case these are rather necessary ...

Thx.
-Bassam.


--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893

-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Michael Rohleder
Sent: Wednesday, April 06, 2005 4:43 AM
To: SystemVerilog CC DWG
Subject: [SPAM] - [sv-cc] Proposal for #431 uploaded - Email found in
subject

Hi all,

I have also uploaded a proposal for Mantis item #431.

Just as a side note after doing all this work:

I am AGAINST doing this change, because:
 - it mixes the control of the assertion system with the control of the
assertions, and those two things are really different
 - the result does not really look well balanced (at least my simple
mind was not able to find a better solution)
 - IMHO the gain is rather meager (4 enumerations saved), but keep in
mind, these are no SV "keywords" (on the VL side)
    and there are still a huge number of numbers available
 - I am unsure how to justify the statement that the modification would
better fit with other vpi... functions.
Shortly said, I don't see the big benefit here

Just my private opinion. Any comments welcome.

Best regards,
-Michael

-- 

NOTE: The content of this message may contain personal views 
      which are not neccessarily the views of Freescale, unless
specifically stated.
 
         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Freescale Semiconductor     Fax: +49-89-92103-680 |( \
    / / |      Freescale Halbleiter Deutschland GmbH        | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@freescale.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

The information contained in this email has been classified as:
General Business Information                     ( )
Freescale Internal Use Only         ( )
Freescale Confidential Proprietary  ( )


*** This note may contain Freescale Confidential Proprietary or
Freescale Internal Use Only Information and is intended to be reviewed
by only the individual or organization named above. If you are not the
intended recipient or an authorized representative of the intended
recipient, you are hereby notified that any review, dissemination or
copying of this email and its attachments, if any, or the information
contained herein is prohibited. If you have received this email in
error, please immediately notify the sender by return email and delete
this email from your system. 
    Thank you! ***