Re: [sv-bc] Issue 0000021 always_comb 'static prefix' descripti on unclear

>Message b ounced.

K

>>From pieper Wed Sep 8 06:42:23 2004
>Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131])
> by server.eda.org (8.12.10/8.12.0.Beta7) with ESMTP id i88DgNnE029287
> for <sv-bc@eda.org>; Wed, 8 Sep 2004 06:42:23 -0700 (PDT)
>Received: from svr-orw-exc-04.wv.mentorg.com ([147.34.98.104])
> by relay1.mentorg.com with esmtp
> id 1C52iM-0000Ha-00 from gordon_vreugdenhil@mentor.com ; Wed, 08 Sep 2004 06:42:22 -0700
>Received: by svr-orw-exc-04.wv.mentorg.com with Internet Mail Service (5.5.2657.72)
> id <S1Z55S48>; Wed, 8 Sep 2004 06:42:22 -0700
>Message-ID: <413F0C39.6020105@model.com>
>From: "Vreugdenhil, Gordon" <gordon_vreugdenhil@mentorg.com>
>To: Mark Hartoog <Mark.Hartoog@synopsys.com>
>Cc: Sv-Bc <sv-bc@server.eda.org>
>Subject: Re: [sv-bc] Issue 0000021 always_comb 'static prefix' descripti
> on unclear
>Date: Wed, 8 Sep 2004 06:42:17 -0700
>MIME-Version: 1.0
>X-Mailer: Internet Mail Service (5.5.2657.72)
>Content-Type: text/plain;
> charset="iso-8859-1"
>X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a
> on server
>X-Virus-Status: Clean
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id i88DgNnE029288
>
>The concept of "longest static prefix" was borrowed from
>the VHDL LRM and means the same thing (although VHDL
>distinguishes between locally and globally static values).
>While I agree that a simple motivational example and/or
>term could be used as well, using "longest static prefix"
>makes the intent pretty obvious to the language implementors
>if they've had any exposure to VHDL.
>
>Gord.
>
>
>Mark Hartoog wrote:
>> I agree the longest static prefix is confusing.
>>
>> The LRM refers to the longest static prefix in the following sections:
>>
>> 1) Longest static prefix is mentioned in section 5.6 Nets, regs and
>> logic, but this section refers
>> the reader to section 7.11 for a definition.
>>
>> 2) Section 7.11 Static Prefixes has the best explanation and even
>> includes some examples, but some
>> people still find the recursive definition confusing, although the
>> examples help a lot.
>>
>> 3) Section 9.2.1 Implicit always_comb sensitivities has another
>> definition of longest static prefix,
>> which is less clear and less detailed than section 7.11. I think this
>> definition is the one that
>> leaves most readers confused, and since there is no reference to 7.11 in
>> this section, the reader
>> does not even know to look in 7.11.
>>
>> I think the explanation of longest static prefix in section 9.2.1 should
>> be removed and replaced by
>> a reference to section 7.11.
>>
>> The explanation of longest static prefix in section 7.11 is still hard
>> to understand because it is
>> recursive. It might be clear if the formal definition was preceded by a
>> simple explanation of what
>> the longest static prefix is trying to accomplish.
>>
>> The examples in section 7.11 could also be enhanced. I think we should
>> add an example with struct
>> field and array accesses. I also think that ‘1’ and ‘i’ look too close
>> to each other and I would
>> like to change the current example to make it more obvious.
>>
>> The other question here is one of terminology. Is “longest static
>> prefix” a good name for this
>> concept? The term ‘static’ here means the access can be determined from
>> elaboration time constants,
>> but it can be confused with ‘static’ variables in System Verilog and the
>> concept of a ‘prefix’ is
>> not otherwise defined or used in the LRM.
>>
>> If we want to replace the term “longest static prefix” with a better
>> term, what should it be?
>>
>> We are basically trying to end up with the minimum range of bits on the
>> sensitivity list of an
>> always_comb block that can be determined at compile time, so maybe
>> something like “minimum compile
>> time bit range” of an expressions, but I don’t like that either.
>>
>> Mark Hartoog
>> 700 E. Middlefield Road
>> Mountain View, CA 94043
>> 650 584-5404
>> markh@synopsys.com
>>
>
>--
>--------------------------------------------------------------------
>Gordon Vreugdenhil, Staff Engineer 503-685-0808
>Model Technology (Mentor Graphics) gordonv@model.com
Received on Wed Sep 8 09:51:51 2004