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

Let me try to summarize what all is required to resolve this mantis (#2955)
- change/correction in the example (coverage_level -> clevel)
- a note mentioning this checker argument/actual should be a constant (in checker instance).

Warm regards,

Tapan

"You must be the change you want to see in the world" : Mahatma Gandhi

>-----Original Message-----
>From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
>Korchemny, Dmitry
>Sent: Thursday, April 29, 2010 11:59 AM
>To: Thomas Thatcher; sv-ac@server.eda.org
>Subject: 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.
>

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