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

Charles my take is that for example a 3rd party/CAD person integrating
to some simulator would rather the designer end user get "something"
instead of "nothing" after executing a disable call just because the
particular simulator returned an unexpected NULL handle and/or there is
an extra vpi_control arg. More data can be filtered out, less data is
harder to recreate.

I think simplicity helps reduce such worries, that's my take, albeit as
I said the spirit of the change is valid, there is such a thing as too
compact/too much reuse particularly when there is a rise in
side-effects.

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
Charles Dawson
Sent: Wednesday, April 06, 2005 11:45 AM
To: SV-CC
Subject: Re: [SPAM] - [sv-cc] Proposal for #431 uploaded - Email found
in subject

Hi Bassam,

I'm not sure I agree with your reasoning.  As a programmer, I would
prefer that my code fail in a dramatic way when I have a bug.  Subtle
bugs are much harder to find, and having all assertion callbacks
suddenly disappear instead of only one, makes it much more obvious that
I have a bug in my code.

   -Chas


Bassam Tabbara wrote:
> 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
> 


--
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com