RE: [sv-ac] Updated version of 3033

Hi Tom,

Please, see my comments below. I uploaded a new version of the proposal: http://www.eda-stds.org/mantis/file_download.php?file_id=5198&type=bug.

Thanks,
Dmitry

-----Original Message-----
From: Thomas J Thatcher [mailto:thomas.thatcher@oracle.com]
Sent: Monday, July 11, 2011 23:44
To: Korchemny, Dmitry
Cc: sv-ac@eda-stds.org
Subject: 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?)

[Korchemny, Dmitry] The restrictions are not related to the event control only, but also to the variables in the assignment LHS. Namely these variables should not be assigned in any other process. Probably this section may become irrelevant as many people stay for the always procedure deprecation in checkers.

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 . . ."
[Korchemny, Dmitry] Immediate assertions are illegal in a checker body. Nothing prevents us now from allowing them. Let's discuss it today at the meeting.

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)

[Korchemny, Dmitry] Added the following sentence:
Expressions in always_comb and always_latch procedures are not implicitly sampled and the assignments appearing in these procedures use the current values of their expressions.

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).

[Korchemny, Dmitry] Let's discuss it at today's meeting.

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 . . ."

[Korchemny, Dmitry] Fixed.

-- 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.

[Korchemny, Dmitry] This rule was originally introduced to prevent multiple assignment to the same bit of a free variable in different processes. Since we have now the implicit restriction from the always_ff procedure that the free variables can be assigned only in a single process, this restriction is not needed any longer. Removed it. Why should we 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")

[Korchemny, Dmitry] Assignments in initial procedures introduce non-determinism in case there are assignments in different initial procedures and/or always procedures. Fixed the typo.

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.

[Korchemny, Dmitry] 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.
---------------------------------------------------------------------
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, and is
believed to be clean.