"function f1(v) p1: assert #0 (v) ...
always_comb begin: myblk1 if (!b)
a = f1(c);
Now suppose, during some time step, the following sequence of events occurs:
b is set to 0 while c==1, and myblk1 is entered. When f1 is called,
assertion p1 has a passing value.
Later in the time step b settles at a value of 1, while c becomes 0. This
time, since the condition is false, f1 is never evaluated-- so the new
failing value of assertion p1 is never seen."
[Ben] I don;t see the issue in this example because in the first case (b==0
when c==1) the assertion failed. In the later case, f1 should not be
evaluated. What you are saying is that the assertion should have never been
evaluated in the first place. But this is not a "deferred" assignment"
At the end of the time step, no failure is reported on p1, even though the
final signal values for the time step would violate the assertion.
But at the end of the time step, b==1, so the assertion should not be
evaluated.
"Note that this situation could be avoided by using the bitwise | operator,
which does not allow short-circuiting, rather than the logical || in the
assignment to a (see 11.3.5)."
[Ben] But this is not the final solution to this issue, as shown in the
example
always_comb begin: myblk1 if (!b)
a = f1(c); end
*We need better guidelines. Should the function calls be in separate assign
statements? Like*
*
assign e= f1(c, b);
always_comb begin : myblk1
if (!b) a=e;
end : myblk1
function f2(v);
p2: assert #0 (v);
endfunction : f2
assign e= f2(c);
always_comb begin : myblk2
// a = b || f2(c);
a = b || e;
end : myblk2
*
On Fri, Jul 16, 2010 at 10:23 AM, Seligman, Erik <erik.seligman@intel.com>wrote:
> Hi guys—I’ve uploaded a new proposal for 2938, based on the issues
> brought up in email. This was the one on clarifying behavior of deferred
> assertions when included in conditional code. I generalized the discussion
> to cover the ‘if’ case as well as short-circuiting. Please take a look &
> send comments:
>
>
>
> http://www.verilog.org/mantis/view.php?id=2938
>
>
>
>
>
>
>
>
>
> --
> 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.Received on Sun Jul 18 13:18:22 2010
This archive was generated by hypermail 2.1.8 : Sun Jul 18 2010 - 13:18:30 PDT