[sv-bc] Issue 0000021 always_comb 'static prefix' description unclear

I agree the longest static prefix is confusing.

The LRM refers to the longest static prefix in the following sections:

1) Longest static prefix is mentioned in section 5.6 Nets, regs and logic, but this section refers
the reader to section 7.11 for a definition.

2) Section 7.11 Static Prefixes has the best explanation and even includes some examples, but some
people still find the recursive definition confusing, although the examples help a lot.

3) Section 9.2.1 Implicit always_comb sensitivities has another definition of longest static prefix,
which is less clear and less detailed than section 7.11. I think this definition is the one that
leaves most readers confused, and since there is no reference to 7.11 in this section, the reader
does not even know to look in 7.11.

I think the explanation of longest static prefix in section 9.2.1 should be removed and replaced by
a reference to section 7.11.

The explanation of longest static prefix in section 7.11 is still hard to understand because it is
recursive. It might be clear if the formal definition was preceded by a simple explanation of what
the longest static prefix is trying to accomplish.

The examples in section 7.11 could also be enhanced. I think we should add an example with struct
field and array accesses. I also think that ‘1’ and ‘i’ look too close to each other and I would
like to change the current example to make it more obvious.

The other question here is one of terminology. Is “longest static prefix” a good name for this
concept? The term ‘static’ here means the access can be determined from elaboration time constants,
but it can be confused with ‘static’ variables in System Verilog and the concept of a ‘prefix’ is
not otherwise defined or used in the LRM.

If we want to replace the term “longest static prefix” with a better term, what should it be?

We are basically trying to end up with the minimum range of bits on the sensitivity list of an
always_comb block that can be determined at compile time, so maybe something like “minimum compile
time bit range” of an expressions, but I don’t like that either.

Mark Hartoog
700 E. Middlefield Road
Mountain View, CA 94043
650 584-5404
markh@synopsys.com
Received on Tue Sep 7 20:55:46 2004