FIx coverage for generate scopes

[Blebowski]

Hi,

this is a proposal for fixing the generate scopes not being emitted as coverage "instance" scopes.
It works well for for generate because T_BLOCK name for the generate has iterator variable suffix.

In case of if generate or case generate, only a single block is elaborated at single simulation.
A branch / choice inherits name of the parent generate statement, unless overridden by a branch / choice
specific alternative_label. If user omits alternative_label, than different HDL items may end up with
the same code coverage item name (in a different elaborations / simulations). When merging the code
coverage data from such simulations, such data aliases.

Consider e.g. following example:

G_CASE_GEN : case (G_PAR) generate
    when 0 => c <= '1';
    when 1 => d <= '0';
    when 2 => e <= '1';
    when 3 => f <= '0';
    end generate;

Where G_PAR is a top level generic of the entity instantiating this case generate statement.
Upon elaborations with G_PAR ranging from 0 to 3, each of the signal assign statements from
c up to f will have following coverage item name:

<scope name="G_CASE_GEN" block_name="G_CASE_GEN" line="31">
      <scope name="_P0">
        <scope name="_S0">
          <statement hier="WORK.COVER27.G_CASE_GEN._P0._S0" data="1"/>
        </scope>
      </scope>
    </scope>

since the implicit statement / process / branch / expression labelling always counts the equally
within distinct coverage scopes. Merging of code coverage from such simulations gives confusing
results and false positives.

An obvious approach how to fix this, would be appending the branch / choice index to a name
of implicit block that is created for such choice / branch. Such "conflict avoidance" would work
very similarly to implicit labelling of statements / processes / expressions for code coverage.
Do you think it is better to append such "implicit counter" to the name of the created code coverage
scope only, or to the name of the implicit block ? Or would you choose another approach ?

[Blebowski]

Hi,
I decided not to deal with it. After thinking about solution, this would lead to tracking index of the
if/else generate branch or case generate alternative from the parser through the whole front-end
up to code emit. Querying the index would not work in the "elab/lower" phase, since folded false
branches / alternatives can "drop" during simplification.

Instead, I added loc compare when determining if two items to be merged are equal. This will
solve the most obvious problems. I extended the manual with some limitations so that users can
avoid aliasing of coverage items.

@nickg do you have any way on how to debug the failing test on MAC OS ? I don't have MACOS
machine.

[Blebowski]

Hi,
this is now ready for review. The issue was in SHA Library. Despite SHA1_Update buffer being defined as const,
the f-tion actually changes the string content. I think it happens in the default non-accelerated implementation
(MACOS x86) where blk(i) macro changes the underlying block which is a pointer to the string.