Subject: Re: Fwd: [sv-bc] Re: Static prefix proposal (always_comb and logic refinements)
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Mar 07 2003 - 12:21:49 PST
Gordon,
I have some comments on this proposal.
Embedded.
At 04:09 PM 3/3/2003 -0800, Karen Pieper wrote:
>For those of you who don't have access to Word, or who are reading this
>off the website:
>
>Proposal:
>I) ADD:
>
>Section 7.12 “Static Prefixes”
>
>Informally, the “longest static prefix” of a select is the longest part of
>the select for which an analysis tool has known values following
>elaboration. This concept is used when describing implicit sensitivity
>lists (see Section 9.2) and when describing error conditions for drivers
>of logic ports (see Section 5.6). The remainder of this section defines
>what constitutes the “longest static prefix” of a select.
>
>A field select is defined as a hierarchical name where the RHS of the last
>“.” hierarchy separator identifies a field of a variable whose type is a
>struct or union declaration. The field select prefix is defined to be the
>LHS of final “.” hierarchy separator in a field select.
>
>An indexing select is a single indexing operation. The indexing select
>prefix is either an identifier or, in the case of a multidimensional
>select, another indexing select. Array selects, bit selects, part
>selects, and indexed part selects are examples of indexing selects.
I think we may want to treat part selects separately because we have to
talk about the
part select range rather than a sole constant expression.
>The definition of a static prefix is recursive an is defined as follows:
>1) an identifier is a static prefix
Not all identifiers are static prefix. For example a function call is not a
static prefix.
In SV, can we have function calls which return structures, or arrays, or
vectors?
>2) a field select is a static prefix if the field select prefix is a
>static prefix
>3) an indexing select is a static prefix if the indexing select prefix is
>a static prefix and the select expression is a constant expression.
>
>The definition of the longest static prefix is defined as follows:
>1) an identifier that is not the field select prefix or indexing select
>prefix of an expression that is a static prefix
>2) a field select that is not the field select prefix or indexing select
>prefix of an expression that is a static prefix
>3) an indexing select that is not the field select prefix or indexing
>select prefix of an expression that is a static prefix.
Your recursive definition is good but on the negation side. I would prefer
a positive one.
I propose to define it the following way (I stole it from another language...):
A name is said to be a static name IFF only one of the following conditions
holds:
. the name is the simple name of an identifier, or a hierarchical
reference name to a static name, or a field select that does not denote a
function call and whose prefix is a static name.
. the name is an indexing select whose prefix is a static name and every
select
expression that appears as part of the name is a constant expression.
. the name is a partselect whose prefix is a static name and whose
select range is a constant range.
The longest static prefix of a (wire or variable or reg) name is:
. the name itself, if the name is a static name;
. otherwise, it is the longest static prefix of the name that is a
static name.
>Examples:
> localparam p = 7;
> reg [7:0] m [5:1][5:1];
> integer i;
>
> m[1][I] // longest static prefix is m[1]
> m[p][1] // longest static prefix is m[p][1]
> m[i][1] // longest static prefix is m
>
>II) CHANGE:
>Section 9.2, the bullet:
> - There is an inferred sensitivity list that includes every variable
> read by the procedure.
>TO:
> - There is an inferred sensitivity list that includes the expressions
> defined in Section 9.2.1.
>
>ADD:
>
>Section 9.2.1 “Implicit always_comb sensitivities”
>
>The expansion of longest static prefix “P” is defined to be:
>a) P itself if the P is not a memory or indexing select or if P is a
>legal word or bit select.
>b) if P is a memory or indexing select, the expansion is every possible
>legal memory word select
or index select
>with a static prefix that matches P.
>
>The implicit sensitivity list of an always_comb includes the expansions of
>the longest static prefix of each variable or select expression that is
>read within the block or
>within any function called within the block with the following exceptions:
Do you mean any variable which is read inside the function body?
>1) any expansion of a variable declared within the block or within any
>function called within the block.
>2) any expression that is also written within the block or within any
>function called within the block
Is 2) any expression ? or is it the longest static prefix or any
expression? or the expansion of the
longest static prefix of the expression?
These exceptions rules seem odd to me. I don't understand them at all. For
example
why do we care about the variables declared inside the block?
>III) CHANGE:
>
>It shall be an error to have a continuous assignment and a procedural
>assignment write to the same logic variable, even through ports.
>
>TO (change in bold)
>
>It shall be an error to have a continuous assignment and a procedural
>assignment write to any term in the expansion of a written longest static
>prefix of a logic variable, even through ports (See Section 9.2.1 for the
>definition of the expansion of a longest static prefix).
What is "term" do you mean any name resulting from the expansion of a ...?
>Notes:
>· An implication of Proposal II is that the name of the “function
>return variable” is not added to the sensitivity list of an
>always_comb. This means that always_comb treats any form of function
>return variable assignment (via return or direct assignment to the
>function name) in the same manner. This also means that always_comb is
>not sensitized to subsequent function calls from other blocks. Note that
>I have not dealt with the assignment definition to clarify that an
>assignment to a “function name” does not count as an assignment when
>considering whether a variable is assigned by more than one process.
>
>· I have not restricted the expansions in Proposal III to “word”
>selects only. At this point the definition would allow a continuous
>assign to one bit of a word and a procedural assign to a different
>bit. There was some sentiment from Steven and I to require the same
>designation on all bits of a packed word. We can further restrict this by
>adding wording such as “It shall be an error any bits in a packed data
>element have continuous assignments and others have procedural assignments.”
>
>
>>Date: Mon, 03 Mar 2003 13:26:02 -0800
>>From: Gordon Vreugdenhil <Gordon.Vreugdenhil@synopsys.COM>
>>X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
>>X-Accept-Language: en
>>To: SV_BC List <sv-bc@eda.org>
>>Subject: [sv-bc] Re: Static prefix proposal (always_comb and logic
>>refinements)
>>Sender: owner-sv-bc@eda.org
>>
>>Of course, I forgot the attachment in the first email. Here it is.
>>
>>Gord.
>>
>>Gordon Vreugdenhil wrote:
>> >
>> > Attached is a Word doc with my static prefix ideas in proposal form.
>> > There are also proposals for applying the definitions to always_comb
>> > sensitivity lists and logic procedural/continuous writer determination.
>> >
>> > This definitely needs review! Please let me know if you have
>> > recommended changes and I will amend as needed.
>> >
>> > Gord.
>> > --
>> > ----------------------------------------------------------------------
>> > Gord Vreugdenhil gvreugde@synopsys.com
>> > Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054
>> > Synopsys Inc., Beaverton OR
>>
>>--
>>----------------------------------------------------------------------
>>Gord Vreugdenhil gvreugde@synopsys.com
>>Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054
>>Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2b28 : Fri Mar 07 2003 - 12:22:36 PST