Subject: Re: [sv-ac] Forwarding note from Jay Lawrence
From: Adam Krolnik (krolnik@lsil.com)
Date: Fri Apr 25 2003 - 07:11:38 PDT
Hi Arturo, Steve, Jay;
My only issue is with the incorrect reporting with an error message.
Steven, as you know I do not and will not advocate immediate assertions as
they expose the user to the potential of false firings. Also, other committee
members have indicated that they will not use immediate assertions as input
to their formal tools. Thus concurrent assertions are what is important.
Arturo, the requirement to use clocking blocks and defining signals within them
in order for the assertion to work does not provide for simplicity in expression
of the assertions. Thus while this may work, I do not see users buying into
a solution that requires such work. Realize that I am trying to encourage
designers to add a significant number of assertions to the design as they are
creating it. To require one to declare every signal used in assertions will
not in reality be done. I am also concerned about a significant performance
impact such a usage would cause, particularly when you have multiple non-overlapping
clock domains that cause every signal to be sampled for every time tick.
>There are several examples for assertion tools using cycle based semantics
successfully >and there are debug solutions from vendors which display the sampled
values correctly.
This is an interesting statement Steve, I agree with the first part - I too have
implemented a very successful assertion toolset using cycle based semantics. And
I am able to print out relevant messages to guide the users as to what the problem
is. For the second part, which toolsets are you referring to?
Harry wondered if the $error, $warning, etc system tasks could be defined to correctly
print out the correct sampled values. If this is possible then this would solve the
messaging problem. Though these system tasks need to work also in the context of
someone using them to report a non assertion error. E.g.
Both:
always @(posedge clk)
begin
<check some stuff>
if (fail)
$error("The above checking code produced an error, actual %h, expected %h.",
actual, expected);
and
assert property (aprop(a, b))
else $error("The preceeding aprop failed because of a %h and b %n.", a, b);
One can not produce errors and produce incorrect reports. The mixture of these will
turn off designers from their use as a poor solution at best. This needs to be a
post 3.1 issue if nothing else can be done.
Thanks.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Fri Apr 25 2003 - 07:14:16 PDT