Hi all, Please, see my comments below. Thanks, Dmitry ------------------------------------------------------------------------ -------- ES: However, I think we have a slight mash-up in the preamble that should be fixed: package pex_gen9_common_expressions; let VALID_ARB(req, vld, arb_override) = (|(req&vld) || arb_override)); ... endpackage module my_checker; import pex_gen9_common_expressions::*; logic a, b; wire [1:0] request; wire [1:0] valid; reg arb_out, ovr; ... prop: assert property(@(posedge clk) request |-> VALID_ARB(request,valid, ovr); ... endmodule is roughly equivalent to the following directive: `define at_least_two(sig, rst = 1'b0) rst || ($countones(sig) >= 2) Those things are not roughly equivalent in any sense! I think the 'roughly equivalent' part belongs to the *first* example. So we should fix this to move the 'is rougly equivalent to...' and the following code snippet to just after these lines: // in a package let at_least_two(sig, rst = 1'b0) = rst || ($countones(sig) >= 2); [Korchemny, Dmitry] Fixed in the latest version LP: Comment: normally in a package, don't you have to declare all variables that are used, such that in the pex_gen9_common_expressions package example shown, technically you should show declarations of req, vld, and arb_override (or perhaps just show ... before the let statement). Comment: sequence and property types are added by 1549, not 1601. 1601 is for "untyped" only. Also, 1549 adds the "event" type, which should also be excluded along with sequence and property. Comment: "see Clause 16.x.y" should be "see 16.x.y" (several instances) Comment: I think bold keywords and example code should be in courier new 9. Comment: cross-module - I think the terminology "hierarchical references" is used elsewhere. Comment: can a let expression contain the $sampled sampled value function(even though it is perhaps redundant). Perhaps it would be better to just reference the section so that as more are added we don't have to update this. Comment: in let_list_of_arguments, the ")" should be red [Korchemny, Dmitry] I sent a separate mail several days ago addressing Lisa's comments. Appropriate changes are included into the latest version. MK: I noticed few corrections required in the proposal: 1. On page 3, In the footnote for let_instance (40) it says: "let_instance may be used only in the expressions which are part of sequence or property expressions, let declarations or immediate assertions." Whereas on the same page later it says: "A let declaration may be instantiated in other let declarations, sequences, properties, concurrent and immediate assertions." In the note (40), concurrent assertions are missing. On page (4) again it says "A let declaration may be instantiated in expressions of immediate assertions and match items of sequences, properties, verification statements, and other let declarations." This statement is again inconsistent with other such statements. What is the intended usage in match items ? Will it be used on the right hand side of assignment or it can also be used in arguments of the subroutine calls ? 2. The proposal does not say that let instance can be used in expect statement (expect statement is not included in concurrent assertions). Is that intended ? I think expect should be included in here. I have some more comments: 1. On page 3, it says "Another intended use of let is in modeling for assertions to provide shortcuts for identifiers or subexpressions.", I understand the usage for subexpressions but why would someone use a let construct for identifier ? 2. On page 3, "A let declaration may be instantiated in expressions of immediate assertions and match items of sequences, properties, verification statements, and other let declarations." In this statement, the ordering of words should be changed as match items apply to sequences and properties only. 3. On page 3, it says "The argument types are restricted the same way as in boolean expressions used in assertions (see 16.5.1)." Why are we putting same restrictions for let. Since let is going to get used in immediate asserts also it should not have any restriction on its declarations. Instead the checking should be done at the time of instantiation if the usage is correct or not. 4. On page 4, " The let expression gets expanded with the actual arguments by replacing the formal arguments with the actual arguments." I think there should be some mention about typed formal arguments as this is not going to be entirely true in case of typed arguments as type casting will also be done along with replacement. 5. On page 4, "let expressions may contain sampled value function calls (see 16.8.3). Their clock, if not explicitly specified, is inferred in the instantiation context in the same way as if the functions were used directly in sequences, properties or verification statements." I think this statement is ignoring the fact that let can be used outside of concurrent assertions also i.e. in immediate asserts. It should be mentioned that in case the usage is in immediate asserts, a clock must be specified (except for $sampled which does not require clock anymore based on some other proposals). 6. I would like to see an example of a concurrent assertion which uses typed arguments in the property declaration and also typed arguments to the let construct used in the property. I think it will be nice to show to the user that in this case actual will get type casted twice (once due to property's argument type and once again due to let's argument type). [Korchemny, Dmitry] I sent a separate mail addressing Manisha's comments and appropriate changes were made in the latest version of the proposal. TT: Page 9: The added text, I believe has incorrect coloring. The square bracket in the expression should not be colored red. Only the = should be red. let_port_item ::= { attribute_instance } let_formal_type identifier [= expression] ^^ Both colored red. [Korchemny, Dmitry] Fixed this in the latest version of the proposal. What happens when you have both a let a= ... and a reg a = 1'b0; ? Is there a separate name space for let declarations? [Korchemny, Dmitry] The explanation about identifier uniqueness was present in the original version of the proposal. But I received a comment from Shalom that the universal SV rules should not be duplicated, and therefore I removed the explanation. Note that the similar situation takes place with sequences and properties, but there is no special explanation about them in the LRM. -- This message has been scanned for viruses and dangerous content by MailScanner, 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Sep 20 06:58:38 2007
This archive was generated by hypermail 2.1.8 : Thu Sep 20 2007 - 06:59:10 PDT