There were two comments submitted by Stu, which were missed in the excel sheet. Here they are: FIRST COMMENT # Ballot/Comment Data for 0000990 (P1800) # Submitted Thu Mar 24 18:07:31 EST 2005 # Type: comment # Record Number: 41658267 ballot_code = 0000990 form_type = comment ieee_number = 41658267 name = Stuart Sutherland email = stuart@sutherland-hdl.com phone = 503-692-0898 fax = 503-692-1512 org = Sutherland HDL, Inc. page = general line = subclause = 6.4 comment_type = Technical comment = The rules in Clause 6.4 for in-line variable initialization, as part of a variable declaration, needs to be reviewed. First, the rules conflict with the P1364 standard for in-line varialble initialization. The two standards need to be in agreement on this. Second, there has been a debate within the P1800 subcommittees as to whether the initialization rules described in 6.4 allow simulation to correctly initialize combinatorial logic described by always_comb, always @(), continuous assignments, combinational UDPs, and inter-module port connections. suggested_remedy = Shalom Brestnicker has summarized the problem and proposed a solution as follows: There are cases where a net or variable is intended to be a strict combinational function of other nets/variables/constants. In some cases, it does not work correctly as currently defined because the result is evaluated only due to events/changes on the inputs, and the inputs in these cases are constants or have an initial value which does not create an event, and/or the construct is made sensitive to input events only AFTER an initial time-0 event occurs. Proposed Prinicples of Solution: 1. The solution needs to cover: always_comb, combinational always @*, combinational always @(), non-collapsed port connections, continuous assignments, combinational UDPs. 2. It is proposed to treat all of the above as identically as possible for simplicity and consistency. 3. Since the value being assigned can be a simple constant (or parameter) where surely no event is generated, the constructs must unconditionally evaluate at time 0 even without an event. An exception is the simple always, for which we can only activate it, but not unconditionally execute its entire body. 4. The constructs must evaluate at time-0 AFTER any assignments which do not generate events. Variable initializers currently behave that way. However, regular always constructs have a problem with inputs whose initial assignments do not create events. 5. It is accepted that variable initializers execute before initial constructs. No one has argued against that. 6. 1364 does not define an order between always and initial constructs. SV does not change that. However, it seems that in practice, simulators activate always constructs before initial constructs. It would be wise to adopt that offically. (It could be argued that the always_comb scheduling has the same advantages but without the race between initial and always constructs.) 7. Thus, I propose the following 2 solutions. Admittedly, there may be flaws. That is why we have reviews. However, I think the general direction is correct. I'm open to better solutions. Proposal A: Evaluate and activate all of the constructs in question (see Principle 1) at time 0, BEFORE both variable initializations and initial constructs. "Evaluate and activate" means start an execution. In the case of an always construct with a delay or event control, it would wait there. The others will execute unconditionally, then after the first execution, wait for a change on the inputs, like always_comb now, but executing at time 0 earlier than defined now for always_comb. Variable initializers will still execute BEFORE initial constructs, but they WILL generate events. Proposal B: Activate always constructs at time 0, BEFORE both variable initializations and initial constructs. Variable initializers will still execute BEFORE initial constructs, but they WILL generate events. All the other combinational constructs will unconditionally execute at the end of time-0 and then wait for events on their events, just as always_comb does now. ----------------------------------------- SECOND COMMENT # Ballot/Comment Data for 0000990 (P1800) # Submitted Thu Mar 24 18:03:43 EST 2005 # Type: comment # Record Number: 41658267 ballot_code = 0000990 form_type = comment ieee_number = 41658267 name = Stuart Sutherland email = stuart@sutherland-hdl.com phone = 503-692-0898 fax = 503-692-1512 org = Sutherland HDL, Inc. page = general line = subclause = 18 comment_type = Technical comment = Clause 18 on assertions is ambiguous as to whether identifiers must be declared prior to being referenced in a property or sequence block. Some existing implementations require the declaration come first, and some do not. It is my understanding that Verilog allows identifiers to be referenced prior to declaration in specify blocks, tasks, and functions. If this is correct, then it would be reasonable for users to expect that property and sequence blocks be consistent with that rule. Allowing reference before declaration might also help with binding externally declared properties and sequences to a design block. In either case, the P1800 LRM should explicitly state the rule of order for declaration versus reference in a property or sequence block. The current ambiguity has lead to code that is not portable across multiple tools. suggested_remedy =Received on Tue Mar 29 13:39:48 2005
This archive was generated by hypermail 2.1.8 : Tue Mar 29 2005 - 13:39:49 PST