Re: [sv-ac] another small flaw in 1549 Annex F

Hi Shalom:

I know I answered your mail already, but I think that someone should
criticize the example in 6.20.2.1.

I couldn't find the criticism that I thought I had seen, so I
will provide some myself.

The example in 6.20.2.1 is

   For example, $ represents unbounded range specification, where the
   upper index can be any integer.  
   
      parameter r2 = $; 
      property inq1(r1,r2); 
         @(posedge clk) a ##[r1:r2] b ##1 c |=> d; 
      endproperty
      assert inq1(3);

In the example, the parameter does not have a type.  According to
6.20.2,

   A parameter declaration with no type or range specification shall
   default to the type and range of the final value assigned to the
   parameter, after any value overrides have been applied. If the
   expression is real, the parameter is real. If the expression is
   integral, the parameter is a logic vector of the same size with
   range [size-1:0].

This seems to say that if r2 is not overriden, then the type of r2 is
the type of $, which I don't think has been defined.  The declaration
of inq1 has two formal arguments, neither with defaults, and yet the
instance has only one actual.  Furthermore, the "assert" specifies an
immediate assertion, in which it is not legal to instantiate a named
property.  Parentheses are missing in the assertion syntax.  

Finally, the example does not illustrate any point from the text

   The value $ can be assigned to parameters of integer types. A
   parameter to which $ is assigned shall only be used wherever $ can
   be specified as a literal constant.

that precedes it.  The example does not show $ being assigned to a
parameter of integer type, and it does not show any use of the
parameter r2 (the reference to r2 in the declaration of inq1 is
to the formal r2, not the parameter).

J.H.

> X-ExtLoop1: 1
> X-IronPort-AV: E=Sophos;i="4.21,217,1188802800"; 
>    d="scan'208";a="290369526"
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Mon, 1 Oct 2007 15:56:31 +0200
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] another small flaw in 1549 Annex F
> Thread-Index: AcgEHoGKPwLMry4NRDWs9SPp9KpLeQAEL5zg
> From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> Cc: <sv-ac@eda-stds.org>
> X-OriginalArrivalTime: 01 Oct 2007 13:56:32.0311 (UTC) FILETIME=[DF689C70:01C80432]
> 
> John,=20
> 
> > There is not general agreement on how to cast $ into a type=20
> > or whether to treat it as a "special value" that is not=20
> > really cast.  There has been criticism of the example of=20
> > assigning $ to an int parameter.
> 
> I think the situation was the reverse.
> 
> 6=2E20.2.1 says explicitly, "The value $ can be assigned to parameters of
> integer types."
> 
> The question would be about other types.
> 
> Shalom
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

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