(2) There's a technical inconsistency in sec 6.1.1. "only the values
'0' and 1' shall be used in expressions representing clock levels".
Then it says that the rising_edge() function is an allowable form of
clock edge specification, but rising_edge (when elaborated as per LRM
semantics), uses the To_X01 function which references both 'H' and
'L'. Nit-picking, to be sure, but that's what digital designers live
for
1076.6:
6.1.1 Clock signal type
The allowed types for clock signals shall be: BIT, STD_ULOGIC and
their
subtypes (e.g. STD_LOGIC) with a minimum subset of '0' and '1'. Only
the
values ‘0' and ‘1' from these types shall be used in expressions
representing
clock levels and clock edges (See 6.1.2).
(Actual language can be important)
Only '1' and '0' are used in expressions representing clock (signal s)
levels in the rising_edge() function:
-------------------------------------------------------------------
-- edge detection
-------------------------------------------------------------------
FUNCTION rising_edge (SIGNAL s : std_ulogic) RETURN BOOLEAN IS
BEGIN
RETURN (s'EVENT AND (To_X01(s) = '1') AND
(To_X01(s'LAST_VALUE) = '0'));
END;
FUNCTION falling_edge (SIGNAL s : std_ulogic) RETURN BOOLEAN IS
BEGIN
RETURN (s'EVENT AND (To_X01(s) = '0') AND
(To_X01(s'LAST_VALUE) = '1'));
END;
------------------------------------------------------------------
Nary an 'U', 'X', 'Z', 'L', 'H', 'W' nor '-' in there.
rising_edge()/falling_edge() uses To_X01() which calls the
cvt_to_x01() to convert state values to logic values.
----------------------------------------------------------
CONSTANT cvt_to_x01 : logic_x01_table := (
'X', -- 'U'
'X', -- 'X'
'0', -- '0'
'1', -- '1'
'X', -- 'Z'
'X', -- 'W'
'0', -- 'L'
'1', -- 'H'
'X' -- '-'
);
----------------------------------------------------------
The implication is that a signal state 'L' is a logic value of '0'
and a logic value of 'H' maps to a state value of '1'. And yes, 'X'
is present as a signal value (the left hand column in the
logic_x01_table). A lookup table is a type conversion function.
Note that no where are 'U','Z', 'W', 'L', 'H' or '-' expressed as
signal values only as signal states.
B.95 expression: A formula that defines the computation of a value.(§
7.1 )
Further an expression has a left side and a right side or is a factor/
term (including function calls and type conversions).
Nowhere in the rising_edge()/falling_edge() elaboration is a constant
value evaluated as a left hand side of an expression.
Nowhere in the rising_edge()/falling_edge() elaboration is a constant
value of 'U', 'X', 'Z', 'L','H', 'W', or '-' evaluated as the right
hand side of an expression.
Is the logic_x01_table an expression by itself? It doesn't match the
definition above, it's not a formula.
Note that neither value nor formula are defined in the glossary of the
LRM.
From websters for formula:
3 a: a general fact, rule, or principle expressed in usually
mathematical symbols b: a symbolic expression of the chemical
composition or constitution of a substance c: a group of symbols (as
letters and numbers) associated to express facts or data (as the
number and kinds of teeth in the jaw) concisely d: a combination of
signs in a logical calculus
A table hits definition c., above for formula, a group of symbols
associated to express facts or data.
By this (twisted) chain of logic, 'X' shows up in the elaborated
expression (but not 'U', 'X', 'Z', 'L','H', 'W', or '-').
You were right there was something creeping around in there contrary
to the statement in 6.1.1. It wasn't the 'L' or 'H', though. They
only show up in comments, and while you could have a comment embedded
in an expression:
LRM 13.8:
Furthermore, comments do not influence the execution of a simulation
module; their sole purpose is to enlighten the human reader.
Note that the language doesn't indicate that comments don't have
meaning for synthesis. There appears to be more angels dancing on the
head of that pin, yet.