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=bug>
>

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

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!

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

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

Why not?

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

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

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