Subject: Fwd: [sv-bc] Re: Static prefix proposal (always_comb and logic refinements)
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Mon Mar 03 2003 - 16:09:09 PST
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.
The definition of a static prefix is recursive an is defined as follows:
1) an identifier is a static prefix
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.
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 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:
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
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).
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 : Mon Mar 03 2003 - 16:10:00 PST