Re: [sv-ac] Updated version of 3033

Hi Dmitry,

Here is a review of your updated proposal.

Tom

17.5 Checker procedures

Replace:
A general purpose always procedure in checkers is equivalent to
always_ff procedure and the same restrictions apply (see 9.2.2.4).

With:
A general purpose always procedure appearing in a checker is equivalent
to an always_ff procedure, and the same restrictions on the event
control apply (see 9.2.2.4).
(This is what you meant, correct?)

Replace:
It follows from this rule that all expressions in deferred assertions . . ."

With:
It follows from this rule that all expressions in immediate and deferred
assertions . . ."

You have a statement that expressions in always and always_ff procedures
are sampled. There should be another sentence or sub-paragraph
describing that always_comb and always_latch procedures do not sample
arguments, like this:

On the other hand, expressions in always_comb and always_latch
procedures are not sampled. The assignments appearing in these
procedures use the current values of their expressions. For example:

(Not sure if "on the other hand" is considered too much of an idiom to
appear in the standard)

17.5 Checker procedures (paragraph about determinism)

Here, I see you have changed the example, and now you are demonstrating
the classic indeterminism problem with typical RTL code. If someone
coding an external block did not follow proper coding guidelines, you
could have a race condition in module m. This is all very true. But
now the paragraph now has a sub-text that, "the rest of SystemVerilog is
broken but we fixed it in checkers"
Now perhaps you feel that the determinism is a great benefit, but other
committees may not see it that way. To me, the reason we HAVE to do
sampling is that we want an always_ff to model sequential logic, and the
only way to do that if checker procedures are executing in the Reactive
region set is to sample.

I suggest this paragraph and example be dropped. It could be replaced
with a statement that sampling is necessary in order for the always_ff
to behave like a sequential element (i.e. data doesn't shoot through a
flop model).

17.7.1
I think some red cross-out text is missing in this version of the
proposal: The first paragraph of the section: "Checker variables may
be assigned using non-blocking . . ."

-- The left hand side of an assignment shall be the longest static
prefix of a select (see 11.5.3).

What is the reason for this restriction? Wouldn't this restriction
prevent uses like the following?

        bit [3:0] tags [0:15]

        always_ff @(posedge clk)
                tags[wr_tag_indx[3:0]] <= tag_in;
                        // Sampled value of wr_tag_indx

But we might have to restrict automatic variables as array indexes to
the LHS.

-- A checker variable may not be assigned in an initial procedure, but
maybe initialized in its declaration.

Why not? (also, the sentence needs a space between "may" and "be")
        

The right-hand side of a checker variable assignment may contain the
sequence method triggered (see 16.14.6).

This sentence seems out of place here after the example, and it
duplicates a bullet point that occurs just before the example. This
sentence can be dropped.

Tom

On 07/11/11 03:59, Korchemny, Dmitry wrote:
> Hi all,
>
>
>
> I updated the version of 3033:
> http://www.eda-stds.org/mantis/file_download.php?file_id=5196&type=bug
> <http://www.eda-stds.org/mantis/file_download.php?file_id=5196&type=bug>.
> Fixed several typos and slightly rearranged 17.7.1 Checker variable
> assignments.
>
>
>
> Thanks,
>
> Dmitry
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

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