RE: [sv-ac] RE: SV-AC meeting minutes 2010-04-27

Hi Tom,

I agree, some clarification would help. I think, this example is always valid, it just requires the clevel to be a constant.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Thomas Thatcher
Sent: Wednesday, April 28, 2010 9:27 PM
To: sv-ac@server.eda.org
Subject: Re: [sv-ac] RE: SV-AC meeting minutes 2010-04-27

Hi John,

The problem is that there is no instantiation of the checker in this
example. If the clevel port is bound to a parameter or constant in the
instantiation, the example would be legal. However if the clevel port
is bound to a variable, then the example is illegal.

Perhaps a note is required that states that this example is valid only
if the clevel port is bound to a constant value.

Tom

On 04/28/10 11:08, Havlicek John-R8AAAU wrote:
> Hi Folks:
>
> There is something missing from this discussion. It was expressed in
> the SV-AC meeting that the intent of checker instantiation was that it
> behave like sequence and property instantiation with regard to the
> binding of actual arguments to formal arguments.
>
> There is no question that compilation/elaboration time constant
> expressions can be passed as actual arguments to formals of sequences
> and properties and that the formals can be referenced in places where
> compilation/elaboration time constants are required.
>
> See, for example, delay_arg_example on p. 328 of 1800-2009.
>
> Following this lead, the checker formal can be bound to a
> compilation/elaboration time constant expression, and the checker formal
> can be referenced in places where compilation/elaboration time constants
> are required.
>
> It should not be the case that all checker formal arguments are treated
> as compilation/elaboration time constants, but it is certainly true that
> they do not behave the same as module ports and parameter ports.
>
> I have not checked the BNF to see if any relaxation is required.
>
> J.H.
>
> ------------------------------------------------------------------------
> *From:* Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com]
> *Sent:* Wednesday, April 28, 2010 9:14 AM
> *To:* Korchemny, Dmitry
> *Cc:* Havlicek John-R8AAAU; Bresticker, Shalom; sv-ac@server.eda.org
> *Subject:* Re: [sv-ac] RE: SV-AC meeting minutes 2010-04-27
>
> Hi Dmitry,
> Then do you want to mean checker formal argument should be treated as
> compilation/elaboration time constant unlike module formal argument?
>
> Regards
> Surya
>
>
>
> -------- Original Message --------
> Subject: Re:[sv-ac] RE: SV-AC meeting minutes 2010-04-27
> From: Korchemny, Dmitry <dmitry.korchemny@intel.com>
> To: Surya Pratik Saha <spsaha@cal.interrasystems.com>, Havlicek
> John-R8AAAU <r8aaau@freescale.com>
> Cc: "Bresticker, Shalom" <shalom.bresticker@intel.com>,
> "sv-ac@server.eda.org" <sv-ac@eda.org>
> Date: Wednesday, April 28, 2010 7:36:31 PM
>>
>> Hi Surya,
>>
>> The below declaration should be allowed. Probably we need to fix the
>> checker BNF.
>>
>> Thanks,
>>
>> Dmitry
>>
>> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of
>> *Surya Pratik Saha
>> *Sent:* Wednesday, April 28, 2010 5:03 PM
>> *To:* Havlicek John-R8AAAU
>> *Cc:* Bresticker, Shalom; Korchemny, Dmitry; sv-ac@server.eda.org
>> *Subject:* Re: [sv-ac] RE: SV-AC meeting minutes 2010-04-27
>>
>> Moreover, if clevel is a module formal argument, then it is not
>> allowed to be used as generate_if condition. Is there any special in
>> checker formal argument? I did not find any.
>>
>> Regards
>> Surya
>>
>>
>>
>> -------- Original Message --------
>> Subject: Re:[sv-ac] RE: SV-AC meeting minutes 2010-04-27
>> From: Surya Pratik Saha <spsaha@cal.interrasystems.com>
>> <mailto:spsaha@cal.interrasystems.com>
>> To: Havlicek John-R8AAAU <r8aaau@freescale.com>
>> <mailto:r8aaau@freescale.com>
>> Cc: "Bresticker, Shalom" <shalom.bresticker@intel.com>
>> <mailto:shalom.bresticker@intel.com>, "Korchemny, Dmitry"
>> <dmitry.korchemny@intel.com> <mailto:dmitry.korchemny@intel.com>,
>> "sv-ac@server.eda.org" <mailto:sv-ac@server.eda.org> <sv-ac@eda.org>
>> <mailto:sv-ac@eda.org>
>> Date: Wednesday, April 28, 2010 7:30:00 PM
>>
>> Though clevel is a formal argument but its usage is not categorized as
>> const_exprssion which generate_if condition demands. If it is
>> const_expression then is the following e.g. allowed:
>>
>> reg[clevel:0] r;
>>
>> If it is not, then its usage is invalid in generate_if condition.
>> Please let me know if I miss anything.
>>
>> Regards
>> Surya
>>
>>
>>
>>
>> -------- Original Message --------
>> Subject: Re:[sv-ac] RE: SV-AC meeting minutes 2010-04-27
>> From: Havlicek John-R8AAAU <r8aaau@freescale.com>
>> <mailto:r8aaau@freescale.com>
>> To: Bresticker, Shalom <shalom.bresticker@intel.com>
>> <mailto:shalom.bresticker@intel.com>, Korchemny, Dmitry
>> <dmitry.korchemny@intel.com> <mailto:dmitry.korchemny@intel.com>,
>> sv-ac@server.eda.org <mailto:sv-ac@server.eda.org> <sv-ac@eda.org>
>> <mailto:sv-ac@eda.org>
>> Date: Wednesday, April 28, 2010 7:14:46 PM
>>
>> Hi Shalom:
>>
>> Why is clevel a variable? It is a checker formal argument. The
>> semantics of checker instantiation is supposed to mimic the semantics
>> of sequence and property instantion, where compile- or
>> elaboration-time constant expression are allowed to be passed to
>> formal arguments.
>>
>> J.H.
>>
>> ------------------------------------------------------------------------
>>
>> *From:* owner-sv-ac@eda.org <mailto:owner-sv-ac@eda.org>
>> [mailto:owner-sv-ac@eda.org] *On Behalf Of *Bresticker, Shalom
>> *Sent:* Wednesday, April 28, 2010 8:41 AM
>> *To:* Korchemny, Dmitry; sv-ac@server.eda.org
>> <mailto:sv-ac@server.eda.org>
>> *Subject:* [sv-ac] RE: SV-AC meeting minutes 2010-04-27
>>
>> I don't think this will work.
>>
>> "clevel" is a variable, and generate if-conditions require parameters.
>>
>> Shalom
>>
>> 2955: Checker example is wrong
>>
>> Dmitry: Instead of "generate if (coverage_level != cover_none)" it
>> should be "generate if (clevel != cover_none)"
>>
>> ---------------------------------------------------------------------
>> 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* <http://www.mailscanner.info/>, and is
>> believed to be clean.
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>> believed to be clean.
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>> believed to be clean.
>>
>> ---------------------------------------------------------------------
>> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
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.