Re: [sv-ac] 1800 draft 3 review

Hi Ben:

I have a few comments.

>
> Review Comments:
> Grammatical error in 17.6.1
> Change
> from:
> "A formal argument which is not prefixed by a type will be untyped."
>
> TO:
> "A formal argument that is not prefixed by a type will be untyped."
>
> ---
> FROM:
> "The supported data types for sequence formal arguments are the types which are allowed for operands in assertion expressions"
>
> TO:
> "The supported data types for sequence formal arguments are the types allowed for operands in assertion expressions"
>

I do not object to these changes, but I think the originals can be
defended grammatically. In general usage, I believe that a relative
clause formed with "that" should be understood as restrictive rather
than incidental and must not be set off by a comma. However, I
believe that a relative clause formed with "which" can be either
incidental or restrictive, according as it is or is not set off by a
comma.

It may be that IEEE prefers the more restrictive rule that "which"
be used only with a comma and in the non-restrictive sense.

> -----
> I am having a problem understanding the example:
> sequence foo(bit a, bit b);
> bit loc_a;
> (1'b1, loc_a=a) ##0
> (t == loc_a) *[0:$] ##1 b
> endsequence
>
> First, the syntax is wrong, and it should be:
> (1'b1, loc_a=a) ##0
> (t == loc_a) [*0:$] ##1 b;
>
> 2nd, what will the value of loc_a be in the frist cycle of the sequence? 1'b0 or "a"?
> The assignment of loc_a is in the SAME cycle the comparison of the variable is made to "t".
> I would guess that the sampled value of loc_a at the first cycle the sequence is evaluated is
> the default for the type, or 1'b0 in this case.
> Perhaps the following might make things clearer:
> sequence foo(bit a, bit b);
> bit loc_a=1'b0;
> (1'b1, loc_a=a) ##0
> (t == loc_a) *[0:$] ##1 b
> endsequence
> ---------------

I agree with the syntax error comment.

From the formal semantics for ##0 with local variables, it follows
that the reference to loc_a in "t == loc_a" will return the value
assigned to loc_a from "a".

It could be defined as a syntax error to have a reference to a local
variable before it has been assigned. I don't remember if this is
done in the LRM.

I don't know if an initial value is defined for local variables.
If it is, I think it should be "x" rather than "0".

I think allowing the user to specify an initial value in the local
variable delcaration is a good feature that does not exist in
the language right now. It could be defined in terms of
existing features along the following lines:

   sequence foo(bit a, bit b);
     bit loc_a=a;
      (t == loc_a) [*0:$] ##1 b
   endsequence

means the same thing as

   sequence foo(bit a, bit b);
     bit loc_a;
      (1'b1, loc_a=a) ##0
      (t == loc_a) [*0:$] ##1 b
   endsequence

> ---------------------
> 17.14
> Item "5) A multiply-clocked sequence ..."
> I never liked the term "mulitply-clock" as multiply implies to me some artihmetic operator or a multiple of something.
> I prefer the term "multi-clock", inferring several clocks.
>

I am to blame, at least in part, for the move from "multi-clock" to "multiply
clocked" and "multiply-clocked". One of the reasons I like "multiply
clocked" is that it makes sense grammatically as the adverb "multiply"
modifying the adjective "clocked". It also can be contrasted with the
similarly constructed phrase "singly clocked".

If we switch from "multiply clocked" to "multi-clock", then will we
leave "singly clocked" or change it to something else? "Uni-clock", while
a close analogue to "multi-clock", seems awkward.

Best regards,

John H.
Received on Tue, 1 Feb 2005 15:20:38 -0600