RE: [sv-ac] Call to vote: Due June 20

Hi Tom,

Please, see my comments below.

Thanks,
Dmitry

-----Original Message-----
From: Thomas J Thatcher [mailto:thomas.thatcher@oracle.com]
Sent: Saturday, June 18, 2011 02:50
To: Korchemny, Dmitry
Cc: sv-ac@eda-stds.org
Subject: Re: [sv-ac] Call to vote: Due June 20

My votes:

>
>
> Mantis 3033 ____ Yes __x__ No
>
> http://www.eda-stds.org/mantis/view.php?id=3033
>
> http://www.eda-stds.org/mantis/file_download.php?file_id=5152&type=bug
> <http://www.eda-stds.org/mantis/file_download.php?file_id=5152&type=bu
> g>
>

17.5 example
        always_latch
                if (clk) // current value of clk
                  t<=b; // current value of b

It appears the only way to make a latch work in a checker is to explicitly sample it's input
        always_latch
                if (clk) // current value of clk
                  t<=$sampled(b); // Need to explicitly sample

[Korchemny, Dmitry] As far as I understood from the meeting minutes, this comment is not relevant anymore.

17.5 "The reason for sampling expressions in always and always_ff procedures is to make checkers behave deterministically.

The language should be changed because it is not really correct. The code in the example will behave deterministically, even if there is no sampling on a. The behavior, however is not the desired behavior. The variable a would be assigned in the Active region, and the assignment in the checker always block would always pick up the new value. There is only one case that would behave indeterministically. This would occur when variable a is assigned with a blocking assignment from test bench code (bad coding style). In this case, the result would depend on whether the assignment to a was processed first, or this always block
was processed first. A properly coded test bench would use a
non-blocking assignment to a, and the result would be perfectly deterministic.

What we really want to say here is that variables need to be sampled because it gives the desired behavior when working with design variables that are assigned in the Active or NBA regions. i.e. we want an always_ff to act like a flip-flop!

[Korchemny, Dmitry] I agree with your comment. Following Ben's request I modified this example, so that the text should hopefully be correct now.

--- In always and always_ff procedures, only nonblocking assignments are allowed . . .

Do we need an example for this? This is a fairly straightforward rule.
  At least make the example shorter.

Shouldn't always_latch be included in this?

[Korchemny, Dmitry] I dropped the example.

--- The right hand side of continuous and blocking procedural assignments shall not contain free variables

Why not?

[Korchemny, Dmitry] I cannot remember why I introduced this limitation. It looks redundant. The behavior should be intuitive even with free variables in the RHS. I removed this limitation.

Are you going to have a complementary rule for always_comb? i.e. only blocking assignments?

[Korchemny, Dmitry] This limitation was present in one of the earlier versions of this proposal. Though I cannot see any compelling reason why to use NBA in always_comb, to keep it consistent with always_latch where NBA are sometimes used, I dropped this limitation. In most cases it does not harm, but there are cases when it does. E.g., the following statement does not represent a combinational logic:

always_comb begin
        a <= b;
        b <= a;
end

We can discuss this issue further.

>
>
> Mantis 3069 __x__ Yes ____ No
>
> http://www.eda-stds.org/mantis/view.php?id=3069
>
> http://www.eda-stds.org/mantis/file_download.php?file_id=5142&type=bug
> <http://www.eda-stds.org/mantis/file_download.php?file_id=5142&type=bug>
>
>
>
> Below are the changes made in 3069:
>
>
>
> - Replaced "global clocking declaration in effect" with
> "effective global clocking declaration"
>
> - Fixed punctuation and spelling
>
> - Changed
>
> However, any of its instances in the elaborated design description shall
> contain at most one global clocking declaration. It shall be an error if
> there is more than one global clocking declaration in a given module,
> interface, checker or program instance in the elaborated design description.
>
> To
>
> However, any of its instances in the elaborated design description shall
> contain at most one global clocking declaration; it shall be an error
> otherwise.
>
> - Changed
>
> When global clocking is referenced in a sequence declaration, a property
> declaration, or as an actual argument to a named sequence instance, a
> named property instance, or a checker instance, the point of reference
> shall be considered after the application of the rewriting algorithm
> defined in F.4.1, which flattens properties and sequences, and
> substitutes actual arguments to sequence, property and checker instances
> for their corresponding formal arguments. As a result, when a property
> or a sequence declaration containing a reference to global clocking is
> instantiated in an assertion statement, the hierarchical lookup rules
> described above shall be applied from the place of the assertion
> statement appearance in the source description, not from the point of
> the sequence or the property declaration. Similarly, when global
> clocking is referenced in an actual argument of a checker instance, the
> lookup rules shall be applied after the substitution of the actual
> argument in place of the corresponding formal argument inside the
> checker body.
>
> To
>
> When global clocking is referenced in a sequence declaration, a property
> declaration, or as an actual argument to a named sequence instance, a
> named property instance, or a checker instance, the point of reference
> shall be considered after the application of the rewriting algorithm
> defined in F.4.1. As a result, when a property or a sequence declaration
> is instantiated in an assertion statement, the hierarchical lookup rules
> described above shall be applied from the place of the assertion
> statement appearance in the source description, not from the point of
> the sequence or the property declaration. Similarly, the lookup rules
> shall be applied after the substitution of the actual argument in place
> of the corresponding formal argument inside the checker body.
>
>
>
>
>
> ---------------------------------------------------------------------
> 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.