Let, Sequence and Property Declarations; Inference - SVA: The Power of Assertions in SystemVerilog - page 174

The actual argument for s could also be a sequence expression. For example,
suppose that the actual argument is x ##1 y or v ##2 w . This is syntactically cor-
rect sequence expression. The variables x, y, v, w must exist in the instantiating
context otherwise it is an error. Let the list of actual arguments be
2'b11+v,( posedge clk), 1, 0, x ##1 y or v ##2 w
After substitution for the formal arguments, the resulting expression for sequence
s_def becomes
@( posedge clk)(2'b11+v+1==0)##1(x##1y or v ##2 w)
Notice the parentheses around the sequence expression that was substituted for
the occurrence of the formal argument. It is only when the untyped argument is
substituted into the sequence expression that its syntactic and semantic validity
can be ascertained. In this case, all is well. If the same sequence expression were
provided for the untyped formal argument a , it would result in an error, because
after substitution, the actual argument sequence expression becomes an operand of
an addition.
The question is, should untyped arguments be used at all? The advantage of
untyped arguments is that they do not restrict the actual argument to any particular
type. This can be very useful in the case of integral types where the dimensions need
not be specified. The usual type checking is performed after the actual argument has
been substituted wherever the formal argument appeared in the sequence definition.
Therefore, the resulting error message may point to the body of the sequence and
thus may not be easily comprehensible to the user. For instance, the interface of
s_def could be written as
sequence s_def( bit [1:0] a, event b, int c, d, sequence s);
This still leaves much freedom as to the actual argument for s , because it can be
any integral expression or a sequence expression. It would seem that if the sequence
definition s_def above were to be reused, e.g., as part of a library package, then it is
preferable to specify the expected types of the arguments except in the case where
any integral type is allowed and type conversion to int is not desired (see Chap. 9
for further discussion about untyped vs. typed arguments).
The formal argument can also have default actual assignment specified in the
header, as shown in the definition of sequence_port_item . The default argument
specification is resolved in the scope of the sequence declaration. This is different
from the usual actual arguments, which are resolved in the scope of the sequence
instance. For example, let us consider the sequence header for s_def but add default
actual argument specifications:
sequence s_def(
a, event b = $inferred_clock, int c, d, untyped s=x);
In this case, in the absence of actual arguments for the formals b and s , like in
the instance specification s_def(2'b11+v, , 1, 0) or equivalently using named
argument association s_def(.a(2'b11+v), .c(1), .d(0)) , we can see that
neither formal b nor s has an actual argument. Therefore, the clocking expression of