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