Forwarding from Mehdi. ________________________________ From: Mehdi Mohtashemi Sent: Monday, October 29, 2007 11:25 AM To: neil.korpusik@sun.com; Arturo.Salz@synopsys.COM Subject: the email vote result, my synopsys email system stopped working, sending this to y Neil, Arturo, I am sending the result for the email vote. - Mehdi Here is the result of the email vote: Two mantis items passed: 885, 1609, Seven mantis items did not pass. 1384, 1715, 1723, 1851, 2021, 2113, 2137 Eligible members who registered their votes: Ray, Steven, Don, Gord, David Scott, Mark, Mike Burns, Arturo, Cliff, Geoffry, Dave Rich, Neil, Ray, Stuart. 885 1384 1609 1715 1723 1851 2021 2055 2113 2137 Full count: 885 XXXXXXXXXXXXXX Yes ------------ No CLOSE 885, covered by 339 1384 XXX-X-X-X-XXXX Yes ----X-XX-X--- No Steven: Though I would prefer that the term "property" be used instead of "member", since "member" includes class methods, which are not streamed. Gord: I agree with Arturo and Mark that "superclass" is what is intended. "base class" might be another alternative. I think the wording was picked up from other wording in 8.12: ... new subclass that inherits the members of the parent class and ...each class is derived from a single parent class. We really should change all of those references to "base class" or "superclass" to be consistent. Certainly nested classes don't inherit from a parent class due to an extends. Mark: I also do not like the change of "superclass" to "parent's class". I think this is ambiguous for nested classes. Arturo: I will change my vote to "yes" if the proposal adopts Neil's suggestions. In particular, I object to the change form "superclass" to "parent's class". The former is unambiguous, the latter may be. Goeffry: Echo Neil's complaints Neil: I will change my vote to yes if the following changes are made. - Minor typo in last sentence, first paragraph, 11.4.15 There are two periods at the end of the sentence. - The changes specified for 11.4.15 are now being defined for a paragraph that was removed from the LRM by 1707 (the issue Jonathan raised). This set of changes needs to be made with respect to the new wording contained in 1707. This change is not something that we can expect the editor to make. Below I have shown one way to incorporate the changes from 1384 into the current text from 1707. From: (this is what is currently in 1707 11.4.15.1) else if the expression is a non-null class handle this procedure shall be applied in turn to each data member of the referenced object, and not the handle itself. Class members shall be streamed in declaration order. Extended class members shall be streamed after the members of their superclass. The result of streaming an object hierarchy that contains cycles shall be undefined, and an error may be issued. To: else if the expression is a non-null class handle this procedure shall be applied in turn to each data member of the referenced object, and not the handle itself. Class members shall be streamed in declaration order. Extended class members shall be streamed after the members of their superclass. The result of streaming an object hierarchy that contains cycles shall be undefined, and an error may be issued. It shall be illegal to stream a class handle with local or protected members if those members would not be accessible at the point of the streaming operator. From: (this is what is currently in 1707 11.4.15.3) Unpacking a 4-state stream into a 2-state target is done by casting to a 2-state type, and vice versa. Null handles are skipped by both the pack and unpack operations; therefore, the unpack operation shall not create class objects. If a particular object hierarchy is to be reconstructed from a stream, the object hierarchy into which the stream is to be unpacked must be created before the streaming operator is applied. To: Unpacking a 4-state stream into a 2-state target is done by casting to a 2-state type, and vice versa. Null handles are skipped by both the pack and unpack operations; therefore, the unpack operation shall not construct class objects. If a particular object hierarchy is to be assembled from a stream, the object hierarchy into which the stream is to be unpacked must be constructed before the streaming operator is applied. The unpack operation shall only modify explicitly declared properties; it will not modify implicitly declared properties such as random modes (See clause 17). 1609 XXXXXXXXXXXXXX Yes ------------ No 1715 -XX-------X-X-- Yes -----XXXXX-X-XX No Abstain X--XX-----X Steven: I agree with the objections to the need for run-time tracking and checking to prevent explicit triggering of the clocking event. I had assumed that the "read-only" nature of the clocking event meant only that it could not be assigned to. I assumed that it could be explicitly triggered like any other event, though users would presumably refrain from doing so. If allowing it to be explicitly triggered is considered too dangerous, and must therefore be disallowed, then I would say that it isn't quite the same as an event after all. I agree that the .triggered "property" (it is actually more like a method) is still reasonable to allow. Mark: Since the -> and ->> cannot be applied to an event handle that holds a reference to a clocking block name, this will require dynamic error checking at simulation time. I would like to understand why this feature is needed to justify the complexity of this proposal Mike Burns: Objections along the same lines as Arturo et. al. - I like adding .triggered, but other additions are problematic. For example, the proposal says the clocking block event is read-only, yet allows assigning it to an event handle: clocking cb @(posedge clk); ... endclocking event ev; ... ev = cb; Is ev now subject to the same read-only restrictions as the clocking block event? I don't think we want to say yes since that would be hard to implement and confusing to users, and we don't want to say no because we don't want to enable explicit triggering of the underlying event regardless of how it's referred to. I think we should disallow clocking block events on the RHS of event assignments and as actual arguments. Clocking block events should not be treated as event variables; rather, they should be treated as event expressions, legal only where event expressions are legal. Perhaps the notion of a "const event" variable would be useful? Such variables would support all the "read-only" functionality of event variables without breaking the connection of the underlying event to happenings in the design. You could then do things like this: const event ev = (posedge clk); Of course, I think "const event" already means something else (namely, an event variable that cannot be asigned to); perhaps "event const"? If there's support for this idea, we should do it before adding .triggered to clocking blocks; then we would just say that the clocking block can be treated as an "event const" and be done with it. Arturo: I support addition of the "triggered" method to the clocking-block - the original issue - and I'll change my vote to yes if the proposal is limited to that enhancement. A major problem I have with this proposal is that it makes clocking-block names assignment compatible with event variables while imposing additional semantic restrictions (i.e., triggering the event) that require run-time checks to ascertain if a particular event (such as a task's event argument) refers to a native event or a clocking block. These errors cannot be issued at compile time. IMHO, the more general enhancement adds much complexity to the type system for little value-add. Stu: I vote no for two reasons. 1) There have been issues raised by other voters that need to be resolved. 2) 1800 14.10 shows an example of @(dram) and says it is equivalent to @(posedge phi1). Using this same clocking example, the proposed use of wait(dram) implies that it is equivalent to wait(posedge phi1), which I consider to an undesirable change to the wait construct. 1723 XX-X-XX-XXXXX Yes --X----X---- No Abstain: ----X--- Don: I like cliff's approach - use num() to return the number of entries in an associative array and use size() to return the full size of the array. DaveRich: [DR] suggested editorial changes grudgingly made. 1851 XXX-XXXXXX-XXX Yes ---X------X-- No Steven: I also approve of the change from "local parameter" to "localparam". Gord: I agree with others -- a "local parameter" is different than a "localparam". If this text changes to "localparam" I'm Ok with the rest. Arturo: I'd like the proposal to incorporate Dev Rich's suggestion as a friendly amendment - use localparam instead of "local parameter" to avoid confusion with a local class property/parameter. Geoffry: Prefer DR's suggestion (local parameters -> localparams), but I vote yes either way. [DR] "local" means something different inside a class. Change "All param_assignments appearing within a class body shall become local parameters regardless of the presence or absence of a parameter_port_list. All param_assignments appearing within a package shall become local parameters." To "All param_assignments appearing within a class body shall become localparams regardless of the presence or absence of a parameter_port_list. All param_assignments appearing within a package shall become localparams." 2021 XXXXXXXXXXXXX Yes ------------X No Stuart: I will change my vote to yes if the word "NOTE" is removed, making the text normative instead of informative. 2055 --X---X-X-XX Yes X---X--X----X No Abstain -X-X-----X Ray: It is not clear there is benefit to outweight the backward incompatability. steven: I abstain, as I don't know what users would actually prefer. Gord: I'll abstain on 2055. This really needs to be user driven and I don't have feedback to provide on that side. Arturo: It is unclear how the new distribution is any better. As I wrote earlier, "the rule needs to be unambiguous, but it must also be simple enough for users to figure out what happened." Coverage reports must be actionable, that is, users need to be able to easily determine how to cover certain bins, and this proposal complicates that determination. I believe that simplicity trounces the need for uniformity. As proof of how complex the new rules are, I submit the email exchange between Steven Sharp and Shalom - it took these two experts several iterations to arrive at a correct formula. Are we seriously suggesting users must do this computation in their heads? The current rule is simplistic but predictable. Geoffry: No idea if the backwards compatibility issue is a big deal. Neil: I like this change, however it does represent a backward compatibility issue. Ray: It is not clear there is benefit to outweight the backward incompatability. Stuart: I abstain because I am not familiar enough with what verification gurus expect for the distribution of values across bins. 2113 -XX-XXX-XX-XX Yes X--X---X--X-X No I agree with deleting the associative array reference. I don't object to resizing a queue. The modified section 17.5.7 describes iterative constraints. Section 17.4 describes the resizing of random varaibles and will also need to be modified. Gord: Agree with previous concerns. Arturo: I'd like to discuss the merits of the added sentence: For queues, any change in size due to randomization results in elements being added or removed from the end of the queue. Why is this a requirement for queues only? How would this be observable in a randomized queue? Other than that, I do favor the replacement of associative array with queues. [DR] Queues should be added in replacement of associative arrays. Neil: with the following friendly amendment From: The size method of a dynamic array ... To: The size method of a dynamic array or queue ... http://www.eda-stds.org/sv-ec/hm/4980.html <http://www.eda-stds.org/sv-ec/hm/4980.html> // discusses this point Ray: I agree with deleting the associative array reference. I don't object to resizing a queue. The modified section 17.5.7 describes iterative constraints. Section 17.4 describes the resizing of random varaibles and will also need to be modified. 2137 --XXX-XX-XX-X Yes -X---X--X--X No Abstain X---------X Steven : I think there are wordsmithing problems here. First, there is the fact that the sentence before the bullets in 9.2 talks about there being four constructs, but there are 7 main bullets (after the always_* bullets are indented properly). Second, the section title and that sentence indicate that the purpose of the section is to list the structured procedures. I am not convinced that a sequence match subroutine_call counts as a structured procedure. It only allows a subroutine call, rather than being a wrapper for general procedural code. Mark: I agree that action blocks need to be added to the list. I am confused why just sequence match subroutine calls are being added. There also are sequence match assignment and increment/decrement statements. Why are these not procedural? Why only subroutine calls? Arturo: This proposal is in need of some wordsmith. Cliff: (Minor corrections and clarifications would turn this vote into a Yes) Neil: This should go to the sv-ac. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Oct 29 12:19:19 2007
This archive was generated by hypermail 2.1.8 : Mon Oct 29 2007 - 12:19:27 PDT