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