Subject: Re: Fwd: [sv-bc] Re: Static prefix proposal (always_comb andlogic refinements)
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Tue Mar 11 2003 - 06:23:22 PST
Francoise Martinolle wrote:
>
> 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?
Yes, but you can't do a select on the result.
This should probably be made a bit more precise.
>
> > 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...):
I thought about "borrowing" the wording from VHDL as well, but decided
to just write it directly. The positive variant is fine with me too;
the end result is the same.
> 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.
I think that this covers indexed part selects since the "whose select
range is a constant range" would require that the index be constant.
Since part selects are always constant, we could make this more
explicit by saying "part select or indexed part select whose index
expression is a constant expression".
>
> 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
Good point.
>
> > 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?
Yes.
> > 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?
I think that it needs to be the expansion of any expression written within
the block. This is still isn't completely precise since we aren't covering
LHS concats, but I hope the intent in that situation is obvious.
> 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?
This is to keep the sensitivity list down to the useful parts. The
LRM already requires that written variables are only written within
the always_comb. Having such variables in the sensitivity list is
useless. Obviously an implementation could drop such variables anyways,
but if we want vpi access to the senstivity list (do we?), we need
to have a canonical list. Local variables in a function are slightly
different. One could argue that static functions can't be called
by more than one always_comb if they have locals since such locals
are static and thus would be written by more than one always_comb.
The "ignore the locals" rule is bypassing that and treating the logic
in the way that synthesis would (Karen, any input here?). In fact,
we really should fix the "only one writer" rule to reflect this as
well. The wording there will be touchy -- we have to disallow
use of a function where a local is written via a hierarchical name
originating from outside the scope of the function but "ignore"
the implicit multiple writes from different calling always_comb
blocks. I didn't want to try to do that wording at the same time.
> > 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 ...?
Yes; I just wouldn't come up with a good word there. "Name" includes
the select part; I had considered that. Any better wording suggestions?
> > 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.”
> >
Thanks for the great feedback!
Gord.
> >> 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
> >
-- ---------------------------------------------------------------------- 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 : Tue Mar 11 2003 - 06:24:09 PST