RE: [sv-ac] RE: minor comments on 1549

I would like to mention that there is a proposal to introduce checkers
(an entity which is similar to a module aimed to package several
assertions together along with the modeling code, see presentation
Checkers.ppt). The checker resembles both a module and a property, and
therefore there are many problems that are common to parameter passing
in the checkers and in the properties. Therefore there are many common
issues that Lisa raised in the context of properties and I in the
context of checkers.

As for const parameters, they are useful for properties, but they have
even more sense for checkers. I am not talking about a specific keyword
(but in my proposal they are also called const:)). Consider an example
of a checker which is intended to be used both in formal verification
and in simulation. In formal verification an error message cannot be an
arbitrary string, it should be a constant.

checker after(bit a, b, const string msg, bit clk);

	assert property (@(posedge clk) a |=> b) else $error(msg);
	...

endchecker

This specification guarantees that if the actual parameter is not a
constant, the compilation will fail with a clear error message.

The only alternative is to keep separate lists for parameters and other
arguments. But keeping different lists is less intuitive, especially for
properties and for checkers. Compare two invocations (the syntax is not
final):

after my_check(req, gnt, "Error", myclk);

and

after #("Error") my_check(req, gnt, myclk);

For properties the instantiation with parameter list will be even less
intuitive.

Even worse, we become inconsistent. If our checker is targeted for FV
(i.e., we require a constant string), its message should be a parameter:

after #("Error") my_check(req, gnt, myclk);

but if we target it for simulation, and allow any error message, not
necessarily constant, its invocation must be:

after my_check(req, gnt, "Error", myclk);

since a non-constant string cannot be a parameter.

Thanks,
Dmitry

-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] 
Sent: Thursday, September 07, 2006 9:21 PM
To: Bresticker, Shalom; Korchemny, Dmitry
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] RE: minor comments on 1549

The same thought occurred to me, but that would also be inconsistent
with the rest of the language - other elements don't allow mixing ports
and arguments.

I sympathize with Dmitry's concern. That's why before considering const
or parameter for this purpose, I think it might be useful to understand
if such a modifier is needed at all. I feel that using const in this
context is unnecessary and somewhat confusing. As Lisa stated earlier,
the use of const is optional, and passing a variable will result in an
error. If I were to extend this further, one could say that in general,
property arguments are passed by reference, but we don't require the ref
modifier.

	Arturo

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Thursday, September 07, 2006 4:06 AM
To: Korchemny, Dmitry
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] RE: minor comments on 1549

Could the keyword 'parameter' be used instead of 'const'?

Shalom

> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
On
> Behalf Of Korchemny, Dmitry
> Sent: Thursday, September 07, 2006 1:57 PM
> To: Arturo Salz; john.havlicek@freescale.com
> Cc: piper@cadence.com; sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] RE: minor comments on 1549
> 
> Hi Arturo,
> 
> Using parameters is indeed consistent with other SV areas, but the
> property usage becomes more difficult: the end-users will have to
> distinguish between parameters and ports. E.g. instead of writing
> 
> assert property (triggers(.cond(a), .impl(b), .delay(c));
> 
> The user will have to write:
> 
> assert property (triggers#(.delay(c))(.cond(a), .impl(b));
> 
> For the end-user the first form is more intuitive. Therefore when in
> this approach the library properties will always have wrappers. E.g.,
> 
> property triggers(cond, impl, delay);
> 	lib_triggers#(delay)(cond, impl);
> endproperty
> 
> property lib_triggers#(shortint delay = 1) (cond, impl);
> 	a |-> ##delay b;
> endproperty
> 
> Using const would save one wrapper.
> 
> Regards,
> Dmitry