Hi Doug, Sorry it's taking me so long to get around to implementing this. Two week long business trip training teams all over the place combined with jet lag and I'm a bit frazzled right now. I will try and get this done in the next couple days so we can talk about it during the next conference call. I haven't read the 2005 proposal yet. I'll take a look at it tomorrow. I'm hoping to glean from it the wording they used to describe the "false glitch" avoidance. Eric explained it to me so I understand the semantics, just want to make sure my wording is right. I met with Shalom on Sunday in Israel. He explained the assertion issue to me. I personally don't like this falling into the category of assertions because I don't want it turned off, at least I don't see a reason to disable it. If there is a strong argument on both sides however, then we can leave it vague. I have no issue with that. Thanks for taking these notes for me and thanks for the Rev5 update. Rev6 coming soon. -Tom ________________________________ From: Warmke, Doug [mailto:doug_warmke@mentor.com] Sent: Monday, January 21, 2008 5:41 PM To: Alsop, Thomas R; sv-bc@server.eda.org Subject: RE: [sv-bc] E-mail ballot: DUE 8am PST, Jan 21, 2008 Hi Tom, In the SV-BC today we discussed 2008 at some length. The consensus was that the proposal needs to define more precise semantics of how the avoidance of "false glitches" is to be implemented. Another topic was "Are unique/priority if/case considered to be SV assertions of some kind?" Matt M would like that to be the case. Stu and others argued it should not be the case. In the end, I think the idea was to leave that matter explicitly vague. That way tools could have leeway to provide command-line switches that swing the constructs one way or the other (i.e. optionally allow $assertoff and $assertkill to affect unique/priority violation checks) Others on the committee surely will have something to add here. Personally I have no strong opinion; I'm just trying to relay what I heard at the meeting. I've uploaded a rev5 of the 2008 proposal which takes care of a lot of the above. The main idea is to borrow relevant sections of 2005's proposal and mechanics. If 2005 changes substantially (which I doubt at this point), then 2008 would need to be updated with similar changes. The rev5 proposal is not complete. I mainly wanted to give a running start to things based on my experience with 2005 and the LRM at large. Some example work still needs to be done in 2008 (presumably by you). Also, I only made the changes in the unique/priority if section. The same kinds of changes would need to be done in the unique/priority case section. Thanks, Doug From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Alsop, Thomas R Sent: Sunday, January 20, 2008 8:19 PM To: Alsop, Thomas R; Brad Pierce; sv-bc@server.eda.org Subject: RE: [sv-bc] E-mail ballot: DUE 8am PST, Jan 21, 2008 I have updated the proposal for 2008 (see Rev4) to remove basically all references to 2005, removing the #0 and throughput qualifiers. This has greatly simplified the proposal. I am not sure if I'll log on tonight for the meeting mostly because it will be very late at night here in Bangalore _and_ I am jet lagged. Matt or Shalom, if you can make notes about any comments from the latest proposal, I can address them over the next week and we can vote again on this sometime ww05. Thanks, -Tom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Alsop, Thomas R Sent: Tuesday, January 15, 2008 11:10 PM To: Brad Pierce; sv-bc@server.eda.org Subject: RE: [sv-bc] E-mail ballot: DUE 8am PST, Jan 21, 2008 I agree with Brad on issue 5 below. Can we just remove "throughout" from this proposal? Does anyone want that in there? I don't care about it. If you do, is there a recommendation for a better keyword? Thanks, -Tom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce Sent: Tuesday, January 15, 2008 7:01 AM To: sv-bc@server.eda.org Subject: RE: [sv-bc] E-mail ballot: DUE 8am PST, Jan 21, 2008 Doug, I agree with your objections 1-3 about the current version. I'm happy though with the compatibility break you mention in 4 (from default 'throughout' to default '#0'), because unique/priority themselves are already broken. A precedent is the backward incompatible fixes to 'generate' in 2005. 5) I also object to the re-use of the 'throughout' operator as a qualifier entirely unrelated to its conventional meaning in SVA sequences. I suppose the intent is 'throughout the time step'. But I doubt anyone will really want this 2005 immediate-style semantics going forward anyway. I recommend not changing the syntax of unique/0 and priority, but only changing the semantics. -- Brad ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Warmke, Doug Sent: Tuesday, January 15, 2008 12:22 AM To: Maidment, Matthew R; sv-bc@eda.org Subject: RE: [sv-bc] E-mail ballot: DUE 8am PST, Jan 21, 2008 Hello all, I vote No on Mantis 2008 for the following reasons: 1) The related Mantis 2005 has been rewritten such that the event-control form of the syntax is no longer present. That had too many unresolved issues, so SV-AC decided to postpone that enhancement until sometime in the future. Thus, the event-control aspect of 2008 should be removed, too. 2) The example in the unique/priority if area specifically mentions a 4 ns delay. But that is not actually the case in the example. Rather, this is an example that is immune to zero-delay glitches in the active region set. Note that evaluation of the unique-ness/priority-ness of the conditions is supposed to happen in the Observed region, as per alignment with the deferred assertion feature of Mantis 2005. Thus, "zero-delay glitch" isn't quite an accurate term. It should be "zero-delay glitch in the active region set". (Since oddball glitches caused by zero-delay oscillations across the active and reactive region sets would still fire the violation checks) 3) Speaking of "violation checks", I would prefer it if 2008 caused that wording to be used when describing unique/priority if/case. 4) I'm not in favor of the compatibility break. I think that the proposed default behavior is too sophisticated to be allowed without the #0 syntactic clue. It's not hard to add those #0 into the source code, and it does give the reader the clue that unique/priority violations will be checked with some zero-delay semantic. In addition, the current version of the construct can work fine if placed in clocked procedures that include logic when assigning the clocked output variables of the procedure. (Thus, the current semantics aren't totally useless, though I do agree they are pretty useless for combinational procedures) I'd like to hear what others have to say about 4). If there was enough weight in favor of making the compatibility break, I will lift this particular objection, since I do think 2008 has a lot of value and should be passed in this version of the standard. Regards, Doug From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Maidment, Matthew R Sent: Monday, January 14, 2008 4:53 PM To: sv-bc@server.eda.org Subject: [sv-bc] E-mail ballot: DUE 8am PST, Jan 21, 2008 -You have until 8am PST, Monday, January 21, 2008 to respond -An issue passes if there are zero NO votes and half of the eligible voters respond with a YES vote. -If you vote NO on any issue, your vote must be accompanied by a reason. The issue will then be up for discussion during a future conference call. -Note: For some issues, the proposed action is captured in the bug note (resolve as duplicate, already addressed, etc.). As of the January 7, 2008 meeting, the eligible voters are: Brad Pierce Shalom Bresticker Cliff Cummings Mark Hartoog Francoise Martinolle Karen Pieper Dave Rich Steven Sharp Gordon Vreugdenhil Stu Sutherland Alex Gran Don Mills Heath Chambers Tom Alsop Doug Warmke Mike Burns SVDB 2008 ___Yes ___No http://www.eda.org/svdb/view.php?id=2008 <http://www.eda.org/svdb/view.php?id=2008> -- 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. -- 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. -- 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, and is believed to be clean.Received on Tue Jan 29 13:49:10 2008
This archive was generated by hypermail 2.1.8 : Tue Jan 29 2008 - 13:49:54 PST