RE: [sv-ec] RE: [sv-bc] Re: Mandated warnings

From: Stephen Hill <Stephen.Hill_at_.....>
Date: Thu May 07 2009 - 08:24:44 PDT
Hi,

 

  Yes... except rather than writing all these assertion by hand why not
have an assertion created implicitly (effectively an assertion created
automatically by the tool).  Then allow users to override it with their
own hand coded asserion if they want. Or override it with a null
assertion to disable the warning on a case by case basis.   That gives
less typing and default-to-safe. 

 

  I don't think anyone suggested a warning that could not be turned off
on a case by case basis was a good idea.  It was mandatory in that it
had to be supported by the tools not mandatory that it was on all the
time. 

 

  But... I suspect these changes are too big for this rev. so this
discussion may be pointless right now. 

 

...Stephen

  

 

  

 

 

 

________________________________

From: Adam Krolnik [mailto:adam.krolnik@verisilicon.com] 
Sent: Thursday, May 07, 2009 3:39 PM
To: Bresticker, Shalom
Cc: Stephen Hill; Rich, Dave; sv-ec@server.eda.org; SV_BC List
Subject: Re: [sv-ec] RE: [sv-bc] Re: Mandated warnings

 


Hi Shalom;

Yes, correct - the bounds check is an assertion to be written. Then you
can control the reporting of the violation through the use of the rest
of the SystemVerilog language.



   Adam



Bresticker, Shalom wrote: 

Adam,

 

Just for clarification, please note that lint tools can only detect
violations that are identifiable with static analysis, whereas this is
an example of a run-time violation.

 

Regards,

Shalom





________________________________

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Adam Krolnik
Sent: Thursday, May 07, 2009 4:59 PM
To: Stephen Hill
Cc: Rich, Dave; sv-ec@server.eda.org; SV_BC List
Subject: Re: [sv-ec] RE: [sv-bc] Re: Mandated warnings


Hello all;

With the availability of lint tools (with directives for disabling the
diagnostic messages at the site of the warning) and assertions that have
standard syntax for all the tools to parse and use or ignore,
the need for simulation tool warnings is waning.

Yes, it is true that a lot of folks ignore warnings. It is also true
that using lint tools to review
and recode or mark off diagnostic messages help find bugs (I found one
yesterday.) It is also true that assertions when written early on have a
high probability of finding bugs. The hard thing is having a methodology
and implementing it consistency. This is a management/methodology issue
that companies (hopefully) develop as they mature in developing code.

When you can't disable warnings, it becomes tedious and error prone to
have to go and scan through all the cases.  This is one valid reason for
ignoring them after a while.

   Adam Krolnik
   Director of Design Verification
   VeriSilicon Inc.
   Plano, TX.
   Co-author "Assertion-Based Design", "Creating Assertion-Based IP"

Stephen Hill wrote: 

Hi Dave,

  As you can tell I'm certainly no all knowing expert.  I am responsible
for making sure Verilog is used and delivered effectively across a
middle size company, so to some extent I see both user and developer
interactions.  

 The main reason I mentioned the "user point of view" is that the
discussion was heading down the road "no" because it is hard to
implement or optimize.  Those are important issues but I also feel
saving people hours of debug time is worth consideration.

 Maybe I'm unusual in asking design teams to aim for warning-free log
files and then asking for review of any remaining warnings before
tapeout. It seem like there must be an awful lot of bugs slipping though
if most folks really ignore all warnings.

out-of-range bounds checking: I do think there is a way to make this
work cleanly by thinking about the warning (or error) an assertion that
is created automatically and which the user can override.  If a designer
doesn't know whether an array in their own code can be written out of
bounds then they have big problems because they don't understand their
own design.  However I do realize it is not appropriate to try to make
that level of change at this point the process. 

...Stephen

  

________________________________

size=2 width="100%" align=center tabindex=-1> 

From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Thursday, May 07, 2009 1:38 AM
To: Stephen Hill
Cc: sv-ec@eda.org; SV_BC List
Subject: RE: [sv-bc] Re: Mandated warnings

Hi Stephen,

First, thank you for posting directly to the sv reflector. We want to
hear from more users. We know many users are apprehensive with posting
in fear of getting pounced on by so-called experts.  If more users did
this, there would be less pouncing. :-)

Second, a committee member calling themselves exclusively a user
representative or tool representative is sometimes a misnomer. I would
like to think that I represent the users of Mentor's tools equally as
much as I do the tool developers. From what I have heard, Shalom, as an
example, represents both end users within his company, as well as the
tool developers internal to Intel. And like many tool representatives on
this committee, we don't have complete control over what those tool
developers actual do. In reality, the committee that defines this LRM is
a political stew of people representing their own best interests. This
is not to be taken as a bad thing.

Third, as a former customer, colleague, competitor, and vendor to most
of the people on this committee, as well as being directly responsible
for the support of 8 independently developed tools that had to interpret
Verilog or SystemVerilog, I can tell you that users treat warning
messages as background noise. Mandating a warning message is comparable
to making it fully legal behavior. We have tried to make things illegal
when the code written is virtually assured not be the user's intent, and
the difficulty in detecting the problem code is significant. That's why
SV requires an extra set of parenthesis when there is an assignment
within an expression, and doesn't require always blocks to have blocking
statements, causing hangs. But still, most users are more interested in
having their new tool work in the same the as their old tool, rather
than changing their code to be LRM compliant. That is why we have the
mess otherwise know as "mixing ANSI with NON-ANSI port declarations".

Finally, in regard to out-of-range bounds checking, how is the user
supposed to distinguish between meaningful warnings that require
correction versus ones that can be ignored? By visual inspection? You're
going to have to code this condition up as a procedural check, or use an
assertion. We can also entertain an enhancement request that might help
make the coding easier in the next rev of the standard.


Dave Rich

________________________________

size=2 width="100%" align=center tabindex=-1> 

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Stephen Hill
Sent: Sunday, May 03, 2009 3:12 PM
To: Vreugdenhil, Gordon; Bresticker, Shalom
Cc: Jonathan Bromley; sv-ec@server.eda.org; SV_BC List; Stephen Hill;
Stephen Hill
Subject: RE: [sv-bc] Re: Mandated warnings -- was Re: [sv-ec] Mantis
2701, ballot ID #44 - Arturo's feedback

It hard to see that it should be left to tool developers since having
different tools warn about different things is quite painful for users.
It means that code that is clean on one tool is not on others. So when a
new tool is used either we have to open up the code and fix things or
turn we just off warnings.  This is one of the few legitimate reasons
for turning off warnings.  If warnings are clearly captured in the LRM
this problem becomes a lot less significant.  

Of course there are not-so-sensible users about but shouldn't we can to
support sensible users in doing the right thing.

...Stephen

________________________________

size=2 width="100%" align=center tabindex=-1> 

From: Vreugdenhil, Gordon [mailto:gordon_vreugdenhil@mentor.com] 
Sent: Saturday, May 02, 2009 5:44 PM
To: Stephen Hill; Bresticker, Shalom
Cc: Jonathan Bromley; sv-ec@server.eda.org; SV_BC List; Vreugdenhil,
Gordon
Subject: RE: [sv-bc] Re: Mandated warnings -- was Re: [sv-ec] Mantis
2701, ballot ID #44 - Arturo's feedback

I'm not sure there is a disconnect -- there is just a
big difference in opinion as to what is appropriate for
an LRM as opposed to a user guide or customer/vendor
discussion.

I have no problem having customers ask for additional
warnings, etc. and will make business/implementation
decisions about implementation and defaults based
on the very wide user community.

I have pretty substantial objections to an LRM mandating,
as in the 2701 proposal, that exactly one warning be
issued for a particular construct.  That is way beyond
what the LRM should be trying to dictate.

In addition, if many users will just turn off the warnings,
(which is reality) why mandate the warning at all?  If we
really want to reflect reality, shouldn't we really just
mandate suppression of such warnings at time 0?  That is
the primary reason that users turn off warnings.  Oh,
and if we do that, shouldn't we .....

Gord.


-----Original Message-----
From: Stephen Hill [mailto:Stephen.Hill@arm.com]
Sent: Sat 5/2/2009 4:23 AM
To: Vreugdenhil, Gordon; Bresticker, Shalom
Cc: Jonathan Bromley; sv-ec@server.eda.org; SV_BC List; Stephen Hill
Subject: RE: [sv-bc] Re: Mandated warnings -- was Re: [sv-ec] Mantis
2701, ballot ID #44 - Arturo's feedback

Hi Gord,

I think there is a significant disconnect here.  No one is suggesting
implementing warnings without control to let users express their design
intent.  They key is giving the users the case-by-case option. Not
fixing this as always-on or always-off.

The question is really over whether the default should be warning "on"
or "off".

I suspect the "on" behavior is by far the most desirable, at least in
synthesizable code.

Currently I have to tell people that they should really create an
assertion for every array write to spot these problems... unsurprisingly
their reaction is incredulous. It just feels like something that should
be automatic not manual.  The assertion should be there automatically
and overridden by users in the rare case when something else is needed.

On the optimization front - of course it's good to optimize tools but
taking a step back it well be more efficient for the users to run
slightly more slowly but not have to debug hard-to-find masked problems
like this.

Cheers,

...Stephen

Stephen Hill           
ARM R&D                        
EMail: Stephen.Hill@arm.com    
 

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Friday, May 01, 2009 3:26 PM
To: Bresticker, Shalom
Cc: jonathan.bromley@doulos.com; sv-ec@server.eda.org; SV_BC List
Subject: [sv-bc] Re: Mandated warnings -- was Re: [sv-ec] Mantis 2701,
ballot ID #44 - Arturo's feedback


Bresticker, Shalom wrote:
> I also find the following
>
>> The recent vote in SV-BC where vendors
>> unanimously opposed a warning on any array bound write violation
>> and users unanimously supported the warning
>
> very disturbing and not "a good indicator" at all. It indicates a bad
disconnect between vendors and users.


That was actually my point -- it is a good indicator
that there is a problem.  I've stated my position on
the problem.

Gord.



>
> Shalom
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>

--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium.  Thank you.

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

 

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you. 





-- 
    Soli Deo Gloria
    Adam Krolnik
    Director of Design Verification
    VeriSilicon Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design", "Creating Assertion-Based IP"
    


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

---------------------------------------------------------------------
Intel Israel (74) Limited
 
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
  





-- 
    Soli Deo Gloria
    Adam Krolnik
    Director of Design Verification
    VeriSilicon Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design", "Creating Assertion-Based IP"
-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu May 7 08:31:56 2009

This archive was generated by hypermail 2.1.8 : Thu May 07 2009 - 08:33:01 PDT