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> 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.Received on Fri Jun 17 21:32:39 2011
This archive was generated by hypermail 2.1.8 : Fri Jun 17 2011 - 21:33:28 PDT