Re: [sv-ac] check: How will we do this?


Subject: Re: [sv-ac] check: How will we do this?
From: Prakash Narain (prakash@realintent.com)
Date: Mon Feb 10 2003 - 16:14:09 PST


Adam,

That was the whole motivation behind assert and assert_strobe.
DWG debated a lot about the merits of different solutions wrt
preventing false firings in simulation, providing consistent cycle-
based and event-driven semantics and came up with this solution.
This was the best way to do things but with a small hole that was
patched up by check.

Having said that, I am all for a solution that will automatically use
a different scheduling for assert when used in a sequential block
than when used in a combinational block. The objection raised
in DWG was that in general testbench usage, you can't guarantee
that the block will be uniquely identified as combinational or
sequential.

Best Regards,

Prakash

Adam Krolnik wrote:

>
>
> Hi Prakash;
>
>
> Your procedural example is a good one. The check() statement is the
> correct choice
> here. But let's consider the alternatives.
>
> We all agreed that Check expressions not very different from if()
> o Adds 'else $error()'
> o Allowed to be disabled by $assert* (kill, off, on) tasks.
> o Documentation statement.
> o Covered (mostly) by assert statement.
>
> Instead of check(foo), what is the alternative? I have removed the
> comments from the
> desired behavior statement and called $error instead of $display.
>
> always @(posedge clk)
> case(sig1)
> junk1:
> if (sig2) begin
> .
> .
> .
> if (sig3) begin
> check(foo) ;
> > if (!foo) $error("assertion failed") ;
> < //desired behavior if (!foo) $display("assertion
> failed");
> .
> end
> end
> endcase
>
>
> I would add to the above points one more:
> o Identify assertions for validation by other tools (than simuulation.)
>
> Without check() a tool would have to find $error() (or $warning ?)
> system task calls
> and produce an antecedent form to come up with something to prove.
>
> It is unfortunate that:
>
> 1. the check() statement has so little extra functionality.
> 2. the assert() statement does not work properly here - if it did I'd
> be happy.
> I..e. it would be nice to just tell people, 'use an assert to ..."
>
> Is it unrealistic to have an assert statement work differently in a
> edge triggered block
> vs. an unclocked (no edge trigger) block?
>
>
> Adam Krolnik
> Verification Mgr.
> LSI Logic Corp.
> Plano TX. 75074
>
>
>
>



This archive was generated by hypermail 2b28 : Mon Feb 10 2003 - 16:15:02 PST