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

Hi Ben,

With this suggestion, I was not suggesting a change to the semantics.
But I was suggesting that for an actual latch model to work correctly,
the user would have to explicitly call $sampled on the latch input.
Inside a module, the example code that Dmitry has would work fine. But
inside a checker, the always block won't be enabled till the Reactive
region. By that time, all the NBA assignments have been completed.

Imagine that signal b is driven by a negative-ege trigged flip-flop in
the design.

        always_ff @(negedge clk)
                b <= a;

With the example code that Dmitry has, at the negative edge of clk, t
would get the value of a, because b would be assigned the value of a in
the NBA region. Then t would get the new value of b in the Re-NBA
region. With the explicit sampling specified, t would hold the old
value of b, as expected.

Tom

On 06/17/11 21:31, ben cohen wrote:
> Thomas,
> [Thomas] 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
> [Ben] I would think that for a latch you would want the current value
> rather than the sampled value in the Preponed Region.
> Per the LRM, an always_latch is like an always_comb with a check. Thus,
> if the variable "b" changes in a region prior to the RE-NBA, your would
> want the current value of "b". That would be similar the the blocking
> assignment in a checker, except that this blocking assignment occurs in
> the Reactive Region (assign x = a; // current value of a).
>
> *
> *
>
> /[LRM D1] 9.2.2.3 Latched logic always_latch procedure/
> /SystemVerilog also provides a special always_latch procedure for
> modeling latched logic behavior. For/
> /example:/
> / always_latch/
> / if(ck) q <= d;/
> /The always_latch construct is identical to the always_comb construct
> except that software tools should/
> /perform additional checks and warn if the behavior in an always_latch
> construct does not represent/
> /latched logic, whereas in an always_comb construct, tools should check
> and warn if the behavior does not/
> /represent combinational logic. All statements in 9.2.2.2 shall apply to
> always_latch./
>
> Thus, why do you say /"It appears the only way to make a latch work in a
> checker is to explicitly sample it's input"?/
> Ben Cohen
> --
> On Fri, Jun 17, 2011 at 4:49 PM, Thomas J Thatcher
> <thomas.thatcher@oracle.com <mailto:thomas.thatcher@oracle.com>> wrote:
>
> My votes:
>
>
> Mantis 3033 ____ Yes __x__ No
>
>
> http://www.eda-stds.org/__mantis/view.php?id=3033
> <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>
> <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/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>
> <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.
>
>

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