RE: [sv-ac] call to vote on 1667

Thanks John.  I vote yes.

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com] 
Sent: Tuesday, January 15, 2008 7:53 AM
To: Lisa Piper
Cc: john.havlicek@freescale.com; sv-ac@eda.org
Subject: Re: [sv-ac] call to vote on 1667

Hi Lisa:

Please see my answers below.  Let me know if you have further questions.

J.H.

> 1. in the illegal examples, you mention that event is a type
disallowed
> in 16.5.1. Unfortunately, we defined an "event" type in 1549. It may
not
> be exactly the same as that defined in 16.5.1, but I think that is
> confusing.

I checked 1549, and I do not think that it changes 16.5.1.

I checked 1668, and it adds the following sentence:

   The data type [of an assertion variable declaration] shall be one of
the
   types allowed within assertions as defined in Subclause 16.5.1.

In 1667, we say

   The type of a local variable argument shall be one of the types
allowed
   in 16.5.1.

This doesn't seem confusing to me, although it might be better if we
change
the sentence in 1668 to align it with the one in 1667.

Can you make a specific suggestion to address your concern?

> 2. "It shall be an error if there exists a match of the named sequence
> for which an inout or output local variable formal argument is
> unassigned at the completion of the match."   Does this make sense for
> an inout? I thought an inout would have a default initial value, so
what
> does "unassigned" really mean?
> 

Here is an example:

   sequence foo (local logic inout v);
      (a == v)
      ##1
      (
         (b[->1], v = d)
         and
         (c[->1], v = e)
      )
      ;
   endsequence

Because v is assigned in both operands of the "and", v does not flow
out of the "and" subsequence.  Therefore, v is unassigned at the end
of a match of foo.

> 3. "If a local variable formal argument has direction input, then a
> default actual argument may be specified for that argument in the
> optional declaration assignment in the port item, subject to the rules
> for default actual arguments described in 16.7."   I am confused
between
> "default actual argument" and "initialization value".  How do I
> distinguish?

A "default actual argument" is an expression.  An "actual argument" is
also
an expression.  In general, the "actual argument bound to a given formal

argument" is either 

   1) the expression bound to the given formal argument in the instance
(by
      position, by name, by .* resolution, etc.), or,

   2) the default actual argument expression associated with the given
formal
      argument in the declaration if no actual argument expression is
bound to
      the formal argument in the instance.

I think that these are general statements about arguments in
SystemVerilog
(and other langauges) and do not have anything specifically to do with
1667.

The "initial value" of a local variable formal argument of direction
input
or inout is the value of the actual argument expression bound to that 
formal argument that is used in the initialization assignment.  In the 
singly-clocked case, this value will be determined from teh actual
argument
expression by using preponed values of non-local variable and current
values
of local variables in the timestep in which the attempt begins.  In the 
multiply-clocked case with multiple semantic leading clocks, then the
initial
value is determined separately for each semantic leading clock, as
described 
in the changes to 16.13.7.

> Also, it seems inconsistent to state that "It shall be
> illegal to specify a default actual argument for a local variable
> argument of direction inout or output." And "The directions input and
> inout indicate the instantiation context is expected to provide an
> initial value for the local variable argument." Which is stated in the
> "goal of this proposal" but not in the proposal.

The initial value for an inout must be provided by the actual argument
specified in the instance.

For an inout or output local variable, a value is supposed to be
returned
to the instantiation context.  The recipient of that value is the local
variable referenced in the associated actual argument.  This is why 
the use of default actual arguments is not allowed -- if the default 
actual argument were bound to the local variable formal argument, then
this would mean that there is no recipient specified for the output
value
in the instantiation context.

> 4. In the example sub_seq2, the value of v1 is assigned the value of
> "lv" which is data_in, right?  Is it true that it is only assigned to
> the output at the sequence match and not earlier?=20

In the example in 16.7.2, v1 is passed as actual to lv.  The initial
value
of lv is the value of v1 at the beginning of the attempt of sub_seq2.
This
is the same as the value of data in the preceding cycle (see the text of
seq2).
Later (upon matching a ##1 !a), sub_seq2 updates lv by 

   lv += data_in

This value is the value in lv that flows out of the match of sub_seq2,
and
so this value gets assigned into v1 at completion of the match.

> x-mimeole: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Mon, 14 Jan 2008 13:44:35 -0500
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] call to vote on 1667
> Thread-Index: AchSKIjkj4KrehoOSxGyeeUwY1qqpgEpNISQ
> From: "Lisa Piper" <piper@cadence.com>
> X-Received: By mx-sanjose.cadence.com as m0EIibc3015321 at Mon Jan 14
10:44:37 2008
> X-OriginalArrivalTime: 14 Jan 2008 18:45:08.0157 (UTC)
FILETIME=[95D4C6D0:01C856DD]
> 
> Hi John,
> 
> I have the following questions/comments:
> 
> 1. in the illegal examples, you mention that event is a type
disallowed
> in 16.5.1. Unfortunately, we defined an "event" type in 1549. It may
not
> be exactly the same as that defined in 16.5.1, but I think that is
> confusing.
> 
> 2. "It shall be an error if there exists a match of the named sequence
> for which an inout or output local variable formal argument is
> unassigned at the completion of the match."   Does this make sense for
> an inout? I thought an inout would have a default initial value, so
what
> does "unassigned" really mean?
> 
> 3. "If a local variable formal argument has direction input, then a
> default actual argument may be specified for that argument in the
> optional declaration assignment in the port item, subject to the rules
> for default actual arguments described in 16.7."   I am confused
between
> "default actual argument" and "initialization value".  How do I
> distinguish?  Also, it seems inconsistent to state that "It shall be
> illegal to specify a default actual argument for a local variable
> argument of direction inout or output." And "The directions input and
> inout indicate the instantiation context is expected to provide an
> initial value for the local variable argument." Which is stated in the
> "goal of this proposal" but not in the proposal.
> 
> 4. In the example sub_seq2, the value of v1 is assigned the value of
> "lv" which is data_in, right?  Is it true that it is only assigned to
> the output at the sequence match and not earlier?=20
> 
> Lisa
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
John
> Havlicek
> Sent: Tuesday, January 08, 2008 1:39 PM
> To: sv-ac@eda.org
> Subject: [sv-ac] call to vote on 1667
> 
> Hi Folks:
> 
> This is the call to vote on 1667.  I think it is better to
> review the capability now before the VPI stuff is added in
> case there are issues.
> 
> The proposal on Mantis is in two parts:
> 
>   1667_part_1_2008-01-07_jhec.pdf
>   1667_part_2_2008-01-07_jh.pdf
> 
> 
> Please vote if you are eligible.  See the details below.
> 
> J.H.
> 
>
------------------------------------------------------------------------
> ----------
> Ballot on Mantis 1667
> 
> - Called on 2008-01-08, final ballots due by 2008-01-14 T 23:59-08:00.
> 
>  v[xxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan
> (Intel)
>  v[xxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny
> (Synopsys)    =20
>  n[---------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani
> (Synopsys)
>  v[xxxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais
> (Freescale)
>  t[xxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek
> (Freescale - Chair)
>  v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny
> (Intel - Co-Chair)
>  v[xxxx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha
Kulshrestha
> (Mentor Graphics)
>  n[-----------------------------xxxxx-------x-xx-x-] Jiang Long
(Mentor
> Graphics)
>  n[--------x------------x--xxx.....................] Joseph Lu
(Altera)
>  v[xxxxxxxxxxxxxxxxxx..............................] Johan Martensson
> (Jasper)
>  n[--------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller
> (Freescale)
>  v[xxxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper
> (Cadence)
>  v[xxxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman
> (Intel)
>  n[------x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor
> Graphics)
>  v[xxxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara
> (Synopsys)
>  v[xxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun
> Microsystems)
>    |------------------------------------------------ attendance on
> 2008-01-08
>  |-------------------------------------------------- voting
eligibility
> for this ballot
> |--------------------------------------------------- email ballots
> received
> 
>         Legend:
>                 x =3D attended
>                 - =3D missed
>                 r =3D represented
>                 . =3D not yet a member
>                 v =3D valid voter (2 out of last 3 or 3/4 overall)
>                 n =3D not a valid voter
>                 t =3D chair eligible to vote only to make or break a
tie
> 
> 
> 
> --=20
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.