[sv-bc] Issue STU1 from Ballot Feedback

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. 

--
Matt Maidment
mmaidmen@ichips.intel.com