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.