-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions July 24, 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 -- traveling today -- no issues with any of these proposals 8. * Neil Korpusik 1. Review IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Brad, John - assume the patent policy was read Passed unanimously 2. List of Mantis items for review 2.1 2370 SV-SC Inferred clock ambiguities with the sampled functions - Champions feedback on 1698 - duplicate - This mantis item was opened at the request of the Champions The Champions flagged the following: "There seems to be something missing on how putting $past into the procedural code is meant to work." - The sv-sc reviewed 1698 and determined that no changes are required. Neil - reviewed it in detail, as part of the sv-sc activities. John - also reviewed it in detail. Move: Brad - approve the resolution of "duplicate" for mantis item 2370 Second: John Passed Unanimously 2.2 2415 SV-SC Allow using .triggered methods in sequences - fixed - Passed in SV-SC vote closing 2008-07-16, 10y/0n/3a. Email from John: a. Out of curiosity, why was deprecating "ended" favored over deprecating "triggered"? We are chucking the shorter one in favor of the longer. That was the initial suggestion [from Dmitry] -- Re: Brad Because .triggered is already used for events -- Re: Dave Neil - prefers ended Shalom - for events, ended is not meaningful Shalom - There was a difference in the lrm, see 16.14.6 ended - persists through the Observed region only triggered - persists through the remainder of the timestep John - .ended can only be used within sequences, see 16.14.6 Stu - question about multiple clocks Shalom - page 10, 3rd paragraph, for Stu's question on multiple clocks John - could possibly catch a .triggered on a different clock that is coincident on this timestep. - .triggered used to not be allowed on sequences Stu - 16.14.5 discusses multiple clocks John - the last paragraph on page 7 covers Stu's concern Stu - triggered never described these clock rules. if used in a procedural block. - by changing the triggered restrictions to those currently on ended, does it create a new restriction for triggered? John - thinks we are ok, given the text at the bottom of page 7. - old rules for triggered used outside of a sequence still apply b. It would be a good idea to enter a mantis item for the next PAR to update A sequence treats its formal argument as a local variable if the formal argument is used as an lvalue in operator_assignment or inc_or_dec_expression in sequence_match_item. to include local variable formal arguments. John - expects implementors to know what they are doing. The LRM should also say it applies to local var args. Brad - why not fix it? (as opposed to creating a new Mantis) I recommend changing [From John] A sequence treats its formal argument as a local variable if the formal argument is used as an lvalue in operator_assignment or inc_or_dec_expression in sequence_match_item. to A sequence treats its formal argument as a local variable if the formal argument is a local variable argument or the formal argument is used as an lvalue in an operator_assignment or an inc_or_dec_expression in a sequence_match_item. c. Editorial: some indefinite articles seem to be missing. Note: see the re-wording from John that addresses this problem. I guess that this restriction could also be reviewed for relaxation if the actuals involve only statics. Move: John - approve the proposal for Mantis 2415 with friendly amendments Second: Stu Passed Unanimously 2.3 1728 SV-SC Introduce "let"statement - fixed - Started out in the sv-ac - Was sent back to the svac in the Champions conference call of Nov 8th. - The champions feedback was addressed - The proposal failed in the Champions email vote which ended on Feb 4th, 2008. - The proposal was approved by the Champions in the February 25th, 2008 conference call with 2 opposed. (Dave, Stu) - The Working Group unanimously agreed to send this Mantis item to the new Assertions sub-committee in the conference call of March 27, 2008. - Passed in SV-SC vote closing 2008-07-16: 10y/0n/3a Email from Shalom: I have a small number of minor editorial comments on Mantis 1728: 1. On p. 3, in 11.12, "A let declaration may be instantiated in other expressions." It's not really the declaration that is being instantiated. We don't use that terminology elsewhere, either. Better would be, "A let construct may be instantiated ...". 2. A few lines after that: "while the scope of compiler directives is global." This is not quite precise. Better would be "global within the compilation unit," as in 3.12(d). 3. On p. 5, "It shall be an error, if the clock is required, but cannot be inferred..." The first comma should be deleted. 4. On p. 7, in example (e), the property declaration header should end with a semicolon, in two places. 5. The let keyword should be added to Table 21-5 in 21.14.7 also. Email from Brad: 6. There are two module declarations that begin module m(input bit clock); But there are, unfortunately, still no 2-state wires in SystemVerilog, so these should be module m(input var bit clock); [SB] or 'input logic clock' or simply 'input clock', since there does not seem to be any need in the examples for clock to be 2-state. 6.a Also, example (f) has [SB] module m(logic clock); While not incorrect, this declares clock as inout, which was probably not the intent. 6.b More seriously, [SB] both examples (e) and (f) refer to both "clock" and "clk". It needs to be consistent. 7. "let_expression" should be added to "primary" in A.8.4, not "expression" in A.8.3. [SB] This will require that it go back to the sv-sc. Brad - it looks the same as a function call. - it should be in primary not expression Shalom - is this a substantive or an editorial change? Stu - not editorial (the Editor speaking) Brad - a primary is not required in too many places. Shalom - thinks that some of these type of changes were addressed before Brad - it also needs to be in "constant_primary" Shalom - a subset of expression John - what about if in a generate? Shalom - there may also be something special there as well. John - believes that Brad is correct about the const expression issue. Shalom - should there be a constant version of let that can be used in a constant primary. If not, why not? The following set of BNF changes was summarized in the meeting a) "let_expression" should be added to "primary" in A.8.4, not "expression" in A.8.3. b) constant_let_expression needs to be added, and added to constant_primary c) semantic restriction analogous to constant function calls When can a let_expression be used as a constant? Email from John: 8. On p. 4: let at_least_two(sig, rst = 1'b0) = rst || ($countones(sig) >= 2); logic [15:0] sig1; logic [3:0] sig2; always_comb begin q1: assert (at_least_two(sig1)); q2: assert (at_least_two(~sig2)); end "In this case the let instantiation cannot be replaced by a function call since formal arguments of a function need to have a specific type." Is it true that calls to a (single) function cannot replace the calls shown to this let? Suppose that the function took logic[15:0] on the sig formal. Do the rules of passing ~sig2 to sig extend ~sig2 by 0 or by its high order bit? Even if ~sig2 were extended by its high order bit, the actual could be changed to {12'b0,~sig2}. I don't think that it is important to try to demonstrate the superiority of let in the LRM. If it is to be done, then the wording should be more precise and the argument given more carefully. For a given model, it might be possible to examine all the calls to a let and determine a way to uniformize a function to handle them all. By using mechanisms to examine bitwidths and types, there might be clever ways to do this. My opinion is that there is no need to put this kind of apology for let in the LRM. John - has a doubt as to whether this is actually true. - the claim is being made for convenience of using a let versus a function. - it might be possible that a function could be used - would prefer to just struck out that text FM - could possibly use parameters Shalom - you would need two different functions John - it might be possible Shalom - it would be difficult Brad - would you also pass in the size? John - you could do a whole bunch of stuff to get it to work John - thinks it should really be a statement of convenience. Neil - "...cannot be easily replaced..." Sahlom - ok adding in the word "easily". Suggested rewording: From: "In this case the let instantiation cannot be replaced by a function call since formal arguments of a function need to have a specific type." To: "In this case the let instantiation cannot be easily replaced by a function call since formal arguments of a function need to have a specific type." 9. On p. 4: "Otherwise, the self-determined result type of the actual argument shall be cast compatible (see 6.22.4) with the type of the formal argument. The actual argument shall be cast to the type of the formal argument before being substituted for a reference to the formal argument in the rewriting algorithm (see F.5.2)." This text appears in other places in discussing sequence and property arguments. I recall that Gord raised some concern about misinterpreting this to mean that the actual is first reduced to self-determined result type and that is then cast to the type of the formal. This is not what the text actually says, but if SV-SC changed the text in the other places, then this instance should be aligned. John - remembers Gord raising an issue. - if it was changed elsewhere this should also change. Email from Brad: 10. Another example would help It seems likely to me that in practice a let-body would need to apply $eft(), $right(), and so on, to the actuals. It would be helpful to users if there were an example of this. Brad - let is like unconstrained array types in vhdl functions Move: Brad - send the proposal for Mantis 1728 back to the sv-sc Second: John Passed Unanimously Note to sv-sc: all 10 items listed above should be addressed. ---------------- 3. Next meeting July 31 (Brad will not be able to make it) August 7Received on Fri Jul 25 14:33:43 2008
This archive was generated by hypermail 2.1.8 : Fri Jul 25 2008 - 14:33:51 PDT