Subject: Re: [sv-ac] Forwarding note from Jay Lawrence
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Fri Apr 25 2003 - 09:15:05 PDT
Adam,
I don't agree that the issues you mention will turn people off from using
assertions. They may turn people off from providing their own messages,
and that can be addressed in many ways. I simply showed how that
can be addressed with the current constructs available in the language.
Certainly, there'll be plenty of enhancements to add in post-3.1, and
this may be just one such issue.
As a user, I would prefer more control over the error messages generated
by default when concurrent assertions fail. There are many things that a
built-in error generator can do that a user provided $display cannot, such as
the source file from which the assertion was instantiated, its full pathname,
the hierarchical name of each of the signals involved in the assertion, the
actual expression and the sequence that caused a property to fail, etc... plus
other things users will surely raise as they begin to use the tool. Including,
among all these things, the values used by the failing assertion or sub-expression
in the error generated is possibly a good enhancement.
Another possible enhancement might be to allow for the immediate execution
of pure functions (perhaps using a different syntax or qualifier). The key here
is that the function would have no side-effects and hence safe to be called
within the assertion; something that the compiler can ensure that. I believe this
is similar to Harry had in mind. Note that all these are worthwhile enhancements
to consider, but they do not invalidate all the work that has been done. Rome
was not built in one day!
Arturo
----- Original Message -----
From: "Adam Krolnik" <krolnik@lsil.com>
To: "Arturo Salz" <Arturo.Salz@synopsys.COM>
Cc: "System Verilog Assertion" <sv-ac@eda.org>; "Stephen Meier" <Stephen.Meier@synopsys.COM>; "Jay
Lawrence" <lawrence@cadence.com>
Sent: Friday, April 25, 2003 7:11 AM
Subject: Re: [sv-ac] Forwarding note from Jay Lawrence
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 - 09:12:06 PDT