-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions July 31, 2008 Conference call Thursday 8-10am PDT Attendees: ---------- 1. * Stu Sutherland 2. - Surrendra Dudani 3. - Brad Pierce 4. * Francoise Martinolle 5. * Shalom Bresticker 6. * John Havlicek 7. * Dave Rich - was about to get on a plane (attended the early portion) 8. * Neil Korpusik 1. Review IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: John, Shalom - assume the patent policy was read Passed unanimously 2. List of Mantis items for review 2.1 2396 SV-SC Add edge identifier edge for events - fixed - Passed by voice vote in SV-SC meeting, 2008-07-22. 11y/0n/1a Abstains: Lisa - just not sure, seems like there are other ways to do it. - Email from John before the meeting started: For the example in 9.4.6, I do not have a problem with the new text, but I do not understand the example that currently exists. The current example says: Even if posedge phi1 and negedge phi2 occurred at the same simulation time, each will be detected separately. What does this mean and how does it affect the accounting of the number of times repeated? Does "separate detection" imply counting with multiplicity in case a posedge of phi1 and a negedge of phi2 both occur in the same timestep? John - is this saying that they are counted twice? Shalom - they can't be concurrent, one will always occur before the other. - even the same signal changing several times in the same time step will behave this way. John - that answers my question Shalom - a couple of editorial issues, one technical - p2 9.4.2, "An edge shall be detected whenever negedge or posedge is detected." edge should be in courier font. - p3 bottom, "or equivalent" --> "or equivalently" - p4 bottom and p5 top, s1, s2, s3 The note here is from an older version of the draft. This may confuse the editor - Last paragraph in top section of p5. The last blue sentence before 29.4.3 should use "named sequences" since that is in the current draft. - posedge and negedge in this sentence need to be in the courier font. Shalom - Technical problem with sdf back annotation - The proposal adds the edge specifier. There is unspecified behavior with regards to sdf, 31.4.2 in draft 6 - What if SDF timing check specifies a specific edge, e.g., posedge, and SV timing check specifies "edge". What happens? - 31.4.2 SDF timing checks shall match all SystemVerilog timing checks - Example, p795, bottom, in this example there is no edge specified. This example is ok. - What happens if the SDF specifies just one edge? If the specify block just specifies edge, what happens? Today if a specify block is a simple path it won't annotate. The sdf is only annotating for part of the behavior. It would be wrong to annotate it completely. Now edge can mean both edges. The behavior in this situation is not specified by LRM. Move: Dave - send the proposal for mantis item 2396 back to the svsc Second: Shalom Passed Unanimously 2.2 2414 SV-SC VPI for let - fixed - Passed voice vote in SV-SC meeting, 2008-07-22. 11y/0n/1a Mike Burns abstained due to lack of VPI expertise. - Email from John before the meeting: I found the use of "seq formal decl" in "let decl" counterintuitive, but I guess that that item is being reused for let. The changes to Annex O indicate the vpiSeqFormalDecl is new, though. Was it omitted? John - would like to get clarification that this is not a mistake to use "seq formal decl". FM - was discussed in the svcc - there were questions on it. Shalom - "seq formal decl" appears to be completely new Stu - is there another mantis that adds "seq formal decl"? - this proposal appears to be incomplete FM - the svcc didn't get through everything in their meeting. Stu - there are several vpi proposals not yet in the LRM. John - see 1503 FM - She checked the svcc minutes. Bassam thought it shouldn't be added by this proposal unbold "seq formal decl" from 36.5 - the svcc passed the proposal, with friendly amendments Bassam had an action item. Shalom - editorial note - 36.50 diagram, under let decl, the ">" should have a -> The sv-sc should fix this as well. Summary: - The definition of "seq formal decl" appears to be incomplete none of the properties are listed in the proposal. see p3 - either the name is wrong, or the bolding is incorrect, or the definition is incomplete Move: Stu - approve the proposal for Mantis 2414 with the svcc friendly amendments, along with Shalom's editorial fix Second: John Passed Unanimously 2.3 2088 SV-SC Allow Checker construct (0001900) to include covergroups - fixed - Passed by voice vote at SV-SC meeting 2008-07-22, conditional on Tom reviewing p3 example with two identical bins after return from vacation: did he intend this legal but odd case to illustrate something subtle, or should we replace it with a more typical case of disjoint bins? 8y/0n/4a Abstains: - Gordon based on email vote, likely to be substantive user-based issues resulting in implementation divergence. Risk factors are too high. Addresses current user needs, but will have future changes. - Steven based on same issues as Gord and hasn't reviewed the proposal. - Mirek: No expertise in cover groups. - Manisha: Agrees with Gordon - Email from John before the meeting: I don't understand the rationale for the restriction that the covergroup event cannot reference a checker variable. Couldn't this effect be achieved by created code in the checker that is sensitive to the checker variable and then using an active triggering mechanism (e.g., "->cg_event")? Perhaps there are more restrictions in other checker proposals that forbid this kind of code. John - can't covergroup be triggered another way which would allow this? - can't you have an always block in a checker which is sensitive to a checker variable and then call the covergroup sample method from there? - is there a way to check if sample call is dependent on a checker varialbe? - middle of p3 FM - that would be tough to do. John - does 1900 say anything about a restriction on the sensitivity list inside a checker? John - there seems to be an inconsistency. Question for sv-sc - are checker variables allowed in event expression for procedures within checkers? The restriction on p3 could possibly be worked around, which raises a question about the restriction. Editorial issues from Shalom - p3 bottom, also on p4, two places, the first line of the example, there is a missing ';' - p4, first paragraph, 3rd line, "non-blocking" --> "nonblocking" Move: John - send the proposal for mantis item 2088 back to the svsc - revise it for Shalom's editorial issues and answer the question. Revise 2088 or 1900 for John's point. Second: Stu Passed Unanimously 2.4 2398 SV-SC More consistent semantics for concurrent assertions in procedural code - fixed - Passed by voice vote at SV-SC meeting 2008-07-22, conditional on minor edit implemented in version posted by Erik Seligman on 2008-07-23. 12y/0n/0a - Email from John before the meeting: This proposal strikes the text that says that assertion local variables use current values, not Preponed values. This creates an inconsistency between Clause 16 and Annex F. Local variables do not and have never used Preponed values. The text the provides exception for local variables should be restored. I think that the language discussing the beginning of evaluation of a matured assertion should reference the "leading clocking event" rather than just the "clocking event" of the assertion. Shalom - has a couple of issues John - only read about half of it - p2, top paragraph, local variables are sampled in Observed. - local variables count as automatics? FM - automatic, constant, or static - all other variables in LRM Shalom - local variables are specific to assertions. John - local variables are closest to automatics. FM - why does it refer to "automatic values" instead of variables? John provided the following rewording: "All variables in a concurrent assertion use the value sampled in the Preponed region of a time slot with the exception of local variables, constant casts and automatic variables in procedural code (see 16.15.5), and free checker variables (see 17.6.2)." Similarly in other places (with or without the checker variable phrase). John - 16.15.5, last paragraph, for multiple clocked assertions we talk about the "leading clock event". - 3 places need to be changed - "assertions's" --> "assertion's" - 16.15.5.1, first example , 1st paragraph after that for the first pass through there is an issue. Add text to say, "assuming that posedge clk" doesn't occur at time 0. Stu - could also show the clock oscillator definition and write it to not allow the corner case. Shalom - 6.8, static variable initialization is described here. In 1364 - static variable initialization is the same as an initial procedure. Shalom - Has some editorial changes. - 15.15.5, p3 first new paragraph, in the middle, "Each of these entries" "Each of the entries in this queue" - In the following paragraph The definition of "mature" is given on the second usage. It would be best to define it the first time the term is used. - last paragraph, 4th line, "an attempt" --> "an evaluation attempt", two places. Evaluation attempt is used elsewhere, they should all be consistent in the proposal. - p4, example for p1, and the text in first paragraph. The rules for inferring the clock from the procedural context are unchanged and this is an example of it. - nested always are not allowed, but a nested forever is allowed. Shalom was questioning the following text: "If no clock can be inferred from the procedural context, then the clocks shall be inferred from the current scope as if the assertion were instantiated immediately before the procedure." - now agrees that his original question is not an issue. John - then the only other way to pick up a clock is default clocking - should it just say to use default clocking? Not a reason to stop it, but it seems to be worded in an odd way. Shalom - in order for the assertion to refer to variables they must appear first. Shalom - more issues - 16.15.5.1, the tick is going the wrong way (several) - p9, last paragraph before 3rd example, 3rd line, "which shall not be modified" --> "that shall not be modified" Shalom - p10, last paragraph, 16.15.5.1, finds this confusing. John - the queueing mechanism is replacing that. - inferred enabling conditions no longer exist in this version. Shalom - new people will attempt to understand this in terms of 2009. If there is no discussion on inferred enabling conditions, they will have troubling understanding it. Stu - it might be more appropriate to make this a note. Shalom - it should also refer to a particular clause in the 2005 standard. Shalom - 6.24.1, doesn't like the placement of this prefers to move this paragraph earlier or later. - before the 2 line paragraph "when casting to a pre-defined type" would be better. Move: John - approve the proposal for mantis item 2398 with all of these friendly amendments (shown above) Second: Stu Passed Unanimously 2.5 2434 SV-SC Changes to seq/prop defaults and typing of actuals - fixed - Passed in voice vote at SV-SC meeting, 2008-07-22. 9y/1n/0a Mark Hartoog votes no - not needed, creates backwards compatibility issues. Clarification - not 100% sure about the note at the end, but the whole basic idea of casting these expressions to their self-determined type has the potential to create very subtle backwards compatibility issues per the face-to-face. - Email From John before the meeting: There is a technical change that I do not agree with. The previous language said that an exception is made for substitution of an actual for a reference to the corresponding formal is made if The reference to the formal argument stands as a variable_lvalue in an operator_assignment or inc_or_dec_expression in a sequence_match_item. This has been changed to say The actual argument is a variable_lvalue. These two do not mean the same thing. I think that the actual could be a variable_lvalue in cases for which we do not want this rule to apply. I think that the original wording of this condition should be restored (two places). We also now have an inconsistency between the new wording in 16.8 and 16.8.1 and the wording in the Annex F changes for 1549. John - p2, 16.8, 2nd bullet, the change doesn't appear to be correct. - sequence or property passed into, - not sure what "variable_lvalue" is meant to mean. There appear to be some cases of variable_lvalue doesn't make sense. a whole variable can be an lvalue, we don't want variables to hit this exception. - Thinks that we should revert back to the original text here. 16.8.1 there is another similar change, part in blue (last para) - We also now have an inconsistency between the new wording in 16.8 and 16.8.1 and the wording in the Annex F changes for 1549. This is also related to the same point. Move: John - send the proposal for mantis item 2434 back to the sc with this change. Second: stu Passed Unanimously 3. Next Meeting: Aug 7 AI/All - Please send email on any concerns that you have on any of the proposals that we didn't get to in today's meeting. 1900 2110 -- duplicate 2411 -- duplicate 2089 -- duplicate 1809 2428 2448 Neil will bring any svsc updates to the aug 7 Champion's meeting.Received on Fri Aug 1 13:24:44 2008
This archive was generated by hypermail 2.1.8 : Fri Aug 01 2008 - 13:24:55 PDT