Re: [sv-bc] RE: Email Vote: respond by 8AM PDT, Friday, July 30, 2010

From: Neil Korpusik <neil.korpusik@oracle.com>
Date: Wed Aug 04 2010 - 12:47:22 PDT

Hi John,

Please refrain from discussing vendor specific behavior
over the reflector. This type of thing should only be
done if you have been granted specific permission from that
vendor. Most contracts between vendors and users preclude this.

We are working on a standard that applies to all compliant
implementations and not a specific implementation.

Neil Korpusik
P1800 Technical Chair

On 08/04/10 11:41, John Michael Williams wrote:
> Hi Shalom.
>
> For VCS, at least, the choice of min vs. typ vs. max can be made
> by a command-line switch. I tried reinvoking VCS with +maxdelays
> on a small design with a timing triplet in a parameter, and it
> did recompile, with the message,
>
> "recompiling module junk because:
> Module parameters have been changed via defparam."
>
> It probably is an elaboration choice for VCS, as you say.
>
>
> On 08/03/2010 11:48 PM, Bresticker, Shalom wrote:
>> Hi, John.
>>
>> I don't think the LRM says, at least explicitly, when the min-typ-max
>> choice is made.
>> In practice, in the tools I see, the choice is made at elaboration
>> time, not at run time.
>> In fact, the choice has to be so, because mintypmax expressions can
>> appear in constant expressions that the elaboration is dependent on.
>>
>> In any case, the form
>>
>> parameter P = 1:2:3;
>>
>> is syntactically and semantically legal and has been so for many years.
>>
>> What the 2005 LRM said explicitly and got omitted from the 2009
>> standard was that if the RHS result value is not a real or an integral
>> value (e.g., string, array), then the parameter declaration has to
>> explicitly include the data type of the parameter.
>>
>> Regards,
>> Shalom
>>
>>> -----Original Message-----
>>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
>>> John Michael Williams
>>> Sent: Wednesday, August 04, 2010 4:59 AM
>>> Cc: sv-bc@eda.org
>>> Subject: Re: [sv-bc] RE: Email Vote: respond by 8AM PDT, Friday, July
>>> 30, 2010
>>>
>>> Hi Steve.
>>>
>>> I agree that a min:typ:max is an expression (of an alternation set
>>> of numerical values).
>>>
>>> The min vs typ vs max choice is taken at runtime and is
>>> dependent on the simulator. We are talking about
>>> syntax here (at least, that was my intention).
>>>
>>> The compiled and elaborated module will represent a parameter with
>>> a value of "x:y:x", in which x, y, and z will be numbers. The
>>> implementation of x:y:z COULD be as you say; or it could be something
>>> else, such as a string, linked list, or array.
>>>
>>> I agree that x:y:z could be a string value, or a subset value, and
>>> would
>>> NOT be a numerical value.
>>>
>>> Nevertheless, the assignment statement, parameter = x:y:z; should
>>> be syntactically correct. That was what I meant to be the point
>>> of my original Email.
>>>
>>> On 08/02/2010 07:09 PM, Steven Sharp wrote:
>>>>
>>>>> Date: Mon, 02 Aug 2010 10:28:55 -0700
>>>>> From: John Michael Williams<john@svtii.com>
>>>>
>>>>> The new statement makes sense, because a parameter should
>>>>> be able to store things such as delay triplets:
>>>>>
>>>>> parameter MyDelay = 3:4:5;
>>>>
>>>> A mintypmax_expression is not a value, nor would a parameter ever
>>> store it.
>>>> It is an expression, which evaluates to a single numerical value
>>> based on
>>>> which delay is selected during elaboration. The parameter would hold
>>> the
>>>> single value that was selected, not the triplet. It is similar to
>>> writing
>>>>
>>>> parameter MyDelay = min_selected ? 3 : (typ_selected ? 4 : 5);
>>>>
>>>> The parameter doesn't hold that expression; it holds the result of
>>> it.
>>
>> ---------------------------------------------------------------------
>> 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.
Received on Wed Aug 4 12:49:24 2010

This archive was generated by hypermail 2.1.8 : Wed Aug 04 2010 - 12:52:00 PDT