RE: Merged version of chapter 6

Hi,

> 2. In that same paragraph, where it says "unless the conditional
> expression is a constant expression", shouldn't it use the term
"genvar
> expression" rather than "constant expression"?
 
> 7. At the bottom of page 115 is the constant expression / genvar
> expression thing. Also the restriction about not changing during a
> single analysis is weird (seems arbitrary and unnecessary).

> 13. I think much of the ambiguity concerning "constant expressions"
> would go away if we defined "genvar expressions" and then defined
genvar
> conditionals as we did with the for loop. That way we could easily say
> things like analog operators are allowed in genvar conditionals and
> genvar loops, but not conventional conditionals and loops.

Maybe I can clear up some of the fog about genvar expressions and
constant expressions. This explanation describes 1364-2005:

In 1364-2005, genvars exist only as generate loop indices. They may not
be referenced outside a generate loop, except in a genvar declaration.
In the syntax, the control scheme of the generate loop ("for
(initialization; condition; increment)") uses special BNF non-terminals,
genvar_expression, etc. , to indicate that here genvars can be used
although they cannot be used outside the loop. The difference in the
syntax starts with genvar_primary, which allows a genvar to be used,
although a genvar is not allowed to be used in a regular primary or
constant_primary.

A genvar is a unique beast in that it assumes a sequence of values
during elaboration time, yet is treated as a constant afterwards. That
is found only in generate loops, thus genvars can only be used there.

At the top of the loop body there is an implicit declaration of a
localparam with the same name as the genvar. So within the loop body,
genvars can be used as localparams and therefore are included as allowed
components of constant_expressions. Where a constant_expression is used
within the loop body, a genvar identifier can be used. However, really
you are using the localparam with the same name, not the genvar.

It can be a little confusing at the beginning, but I think it is natural
and intuitive after you get used to it.


> 9. On page 124 in the "event_expression" syntax definition, can
> "expression" be an expression that returns a real number? I hope so,
but
> if so, it does not seem like it should be allowed to derive from the
> analog context where it could be continually varying. Also, what would
> posedge or negedge real_expression mean?

[Shalom] In 1364-2005 an event expression can be a real variable, that
is you can write @(realvar), but you cannot use posedge and negedge with
reals.

Hope this helps,
Shalom