[sv-bc] RE: [sv-ac] RE: 1995 (concurrent assertions in loops) ready for vote?

Hi Shalom---

WRT the scoping/naming issue, would a statement like this be acceptable?

"Although the assertions are created as if in a separate generate loop,
they are considered to be bound to the hierarchical block in which the
original assertion appeared.  Thus there is no naming conflict, and
there is still only one block with the original block's label."

Or can you suggest something similar that would properly describe our
intention? 


-----Original Message-----
From: Bresticker, Shalom 
Sent: Sunday, October 28, 2007 12:36 AM
To: Seligman, Erik
Cc: sv-ac@server.eda.org; sv-bc@server.eda.org
Subject: RE: [sv-ac] RE: 1995 (concurrent assertions in loops) ready for
vote?

Erik,

Sorry to do this, but some comments:
 
> I have posted an updated version of this proposal (also attached 
> here), which incorporates the feedback received so far.
> 
> John-- unless anyone has major last-minute comments, I believe this 
> should now be ready for a vote.

1. "The loop may not contain an early exit using break or similar
constructs." 
Is "similar constructs" well-defined? Where?


2. "The body of the loop must consist of a labeled begin-end block."
We discussed this topic recently in SV-BC in Mantis 1348. I am cc'ing
SV-BC on this to make sure I get this right. The bottom line is
something like this:

a. A Verilog-type for-loop, where the iterator is declared outside the
for-loop, does not create a new hierarchical scope. In that case,
enclosing the loop body in a named begin-end block creates a new
hierarchical scope around the loop body, which is what you want, I
think. (Would a fork-join block be as good as a begin-end block?)
(Language quibble: begin-end blocks are 'named' when the name appears
after the 'begin' keyword followed by a colon. A 'label' is when the
name appears before the 'begin' keyword, followed by a colon. They have
the same effect.) This is similar to generates.

b. An SV-type for-loop, where the iterator(s) is declared within the
for-statement does create a new hierarchical scope. The LRM says in
12.7, "The local variable declared within a for loop is equivalent to
declaring an automatic variable in an unnamed block." That statement
means that an implicit begin-end block is created around the for-loop,
as though "for (int ii=0; ...)" was really

begin
  int ii;
  for (ii=0; ...)
  ...
end

By default, that begin-end block is unnamed. 1348 intends to modify that
statement to say that a statement label on the for-loop is equivalent to
naming the implicit begin-end block around it, so that

label: for (int ii=0; ...) ...

would be equivalent to 

begin : label
  int ii;
  for (ii=0; ...)
  ...
end

I have an action item to clarify 12.7.

So if you add a labeled begin-end block around the loop body, you get
the following:

label1: for (int ii=0; ...)
          label2: begin
            ...
          end

and then the statements within the loop body are within the scope
label1.label2.

On the other hand, if you do not label such a for-statement, like this:

for (int ii=0; ...)
  label2: begin
    ...
  end

then you have a labelled begin-end block inside an unnamed block, and
you don't have a legal hierarchical name to the label2 scope, because it
is inside an unnamed block.

foreach loops work similarly.

generate for-loops work differently, though. See Mantis 898.


3. The back-tic in 

integer my_ints[2] = '{123, 456};

should be an apostrophe.


4. Finally, regarding the assertion scope labelling. I'm going to ignore
for now the problem of the implicit scope around the for/foreach. Let's
take the first example. You have a foreach loop with a begin-end body
labelled b1 containing an assertion labelled a1. 

You create a generate loop named b1 with the body containing the
assertion labelled a1, giving you scopes b1[0], b1[1], ...

However the scope named b1 in the foreach loop does not disappear. This
is giving you two scopes named b1, the first being a regular scope, and
the second is a scope array created by the generate. I don't think you
can do that in normal code.

Sorry to make life complicated.

Regards,
Shalom

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