RE: [sv-ac] notes from SV-AC meeting 2007-09-25

"integer my_ints[2] = {123, 456};
always @(posedge clk) begin
  foreach (my_ints[i]) begin : b1
    foo[i] <= somefunction(my_ints[i]);
    a1: assume property (foo[i] != `BAD_VAL);
  end
end

The assumptions b1[0].a1 and b1[1].a1 in this example are logically
equivalent to the assumptions in the example below:"

[SB] Second, there is no b1[0].a1 and b1[1].a1, as I tried to explain
earlier. There is only b1.a1. An array of scopes is created by a
generate for-loop, but not by a regular for-loop.


Well, that's the main idea of this proposal: in previous language
versions a concurrent assertion here would not make sense at all, so
there would be no valid instance name regardless, but now b1[0].a1 and
b1[1].a1 *do* exist, as defined by our rewrite-as-generate methodology.
Is there a different way you would phrase this description?



2. The proposal says, "If the loop is a foreach loop, the generate block
will use a for loop that iterates over the indices used in the foreach
statement."

The problem is that if the foreach is over an associative array, the
indices may be non-contiguous, and then you can't recreate them using a
generate for-loop.

Hmmm....  This language is way too complicated.

Any objections if we restrict this proposal to foreach statements with
contiguous indices?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.