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

From: John Michael Williams <john@svtii.com>
Date: Wed Aug 04 2010 - 13:19:55 PDT

Hi Neil.

OK. Others had referred to vendor behavior, but
perhaps I was being too specific.

On 08/04/2010 12:47 PM, Neil Korpusik wrote:
> 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.
>>>
>>>
>>
>

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Aug 4 13:17:42 2010

This archive was generated by hypermail 2.1.8 : Wed Aug 04 2010 - 13:20:16 PDT