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 >> >> >> >> ------------------------------------------------------------------------ >> >> *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 >> /expert/s. 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 >> >> ------------------------------------------------------------------------ >> >> *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 >> >> ------------------------------------------------------------------------ >> >> *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" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu May 7 07:58:17 2009
This archive was generated by hypermail 2.1.8 : Thu May 07 2009 - 07:59:22 PDT