Re: [sv-ac] meeting on 3/8

Hillel:

I think the understanding has been that if, after substitution,
the resulting sequence or property expression is not legal
SystemVerilog, then the instance is rejected with a compilation error.

While it is not spelled out in the LRM now, I think the intention has
been for there to be parentheses inserted when actual argument expressions
are substituted for formal argument identifiers.

So I think your property after substitution should be interpreted as

   property p1;
 
      (c?d[0:3]:e[2:0])[2:3] and /* 1 */
   
      (c?d[0:3]:e[2:0])[3:2] and /* 2 */
   
      (f[2:3])[2:1] and /* 3 */
   
      (f)[2:1]; /* 4 */
   
   endproperty

I do not know which, if any, of these bit-sliced expressions is legal in
SystemVerilog.

Regarding your proposal:

> My proposal for the first item is to use the current bnf for SystemVerilog task/function formal parameter description:
>
> tf_port_list ::=
> tf_port_item { , tf_port_item }
> tf_port_item ::=
> { attribute_instance } tf_input_declaration
> | { attribute_instance } tf_output_declaration
> | { attribute_instance } tf_inout_declaration
> | { attribute_instance } tf_ref_declaration
> | { attribute_instance } [ signing ] { packed_dimension } list_of_tf_variable_identifiers
> | { attribute_instance } data_type list_of_tf_variable_identifiers
> tf_port_item ::=
> { attribute_instance }
> [ tf_port_direction ] data_type_or_implicit
> port_identifier variable_dimension [ = expression ]
>
> I drop the second issue, my mistake.
>
> Hillel

I think you need to say how the semantics of argument passing will work.
Especially, I think it needs to be made clear how "input", "output",
"inout", and "ref" will work. We also need to understand how the
current mechanisms for passing local variables into and out of instances
of declared sequences will work in the new scheme.

Best regards,

John H.

>
> Surrendra,
>
> In the following example I will try make my case with respect to the need to declare datatypes for formal parameters
> of properties and sequences.
>
> reg [0:4] f;
> reg [0:4] d;
> reg [4:0] e;
>
> assert p1(c?d[0:3]:e[2:0], f[2:3], f);
>
> property p1(x, y, z)
>
> x[2:3] and
>
> x[3:2] and
>
> y[2:1] and
>
> z[2:1];
>
> endproperty
>
> After macro substitution then we have the following property.
>
> property p1;
>
> c?d[0:3]:e[2:0][2:3] and /* 1 * /
>
> c?d[0:3]:e[2:0][3:2] and /* 2 */
>
> f[2:3][2:1] and /* 3 */
>
> f[2:1]; /* 4 */
>
> endproperty
>
> Here are my problems?
>
> 1) To the best of my knowledge, there is no syntax and semantics for this type of code? That is bit slicing and arbitrary expression.
> 2) If we put parentheses on the substitution are there syntax and semantics?
> 3) If we tell the vendor to develop a smart compiler to handle this we have the risk of
> vendors providing different semantics. This misses the point of a standard.
> 4) In line /* 4 */ this is illegal syntax however /* 3 */ should be legal syntax. This is confusing.
>
> A possible workaround is not to allow bit slicing on parameters. This can be achieved by assigning to a local variable and
> do the slicing on the local variable.
>
> Hillel
>
Received on Tue Mar 9 19:44:12 2004