Subject: RE: always_comb semantics
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Oct 03 2002 - 12:46:05 PDT
> From owner-sv-bc@server.eda.org Thu Oct 3 11:26:55 2002
> From: "Karen Pieper" <Karen.Pieper@synopsys.com>
>
> >
> >This says that to be useful as a 'What I See In Simulation Is What I
> >Get From Synthesis' (WISISIWIGFS) feature, then the always @(*) /
> >always_comb, et cetera should NOT add hierarchical references to the
> >sensitivity list.
>
> Worse, it means that hierarchical references should not exist in the code
> at all.
>
> Are we willing to eliminate them entirely?
Unlikely :-)
I was wondering if we could add a keyword like "passive" to indicate that
a section of code (or function) is not to be included in @(*) sensitivity?
E.g.:
reg x,y;
passive function f() return x; endfunction
always_comb z = y | f(); // sensitive to y - f() is ignored
or
reg x,y;
int i;
always @(*) // sensitive to x but not $root.memory
begin
i = x;
passive begin
z = $root.memory[i];
end
end
alternatively use a reference -
int &rm[];
initial rm := $root.memory;
always @(*) z = rm[x]; // sensitive to x only
// - can't follow dynamic reference
Just a thought,
Kev.
> > >
> > > Flip-flops and latches are inferred from always blocks. In order
> > > for a latch to be inferred, the @() list in the block must have no
> > > edge sensitive logic. Any variable that is not completely defined
> > > on every path through the always block will become a latch.
> > > Flip-flops are inferred for variables that are not fully defined
> > > where the @() expression has edge sensitive logic in it.
> >
> >So, would a synthesis tool use different rules than the above to
> >process an 'always', 'always_ff', or 'always_latch' block in System
> >Verilog; or would it treat all of them as it today treats an always
> >block? If it is the later, then I again question why we are using up
> >keywords.
>
>
> From the synthesis perspective, the always_ff, always_latch, and
> always_comb forms would produce error checking.
>
> I believe that the users will find value in being able to indicate in an
> enforced way that the code they are creating is the code that actually
> exists. For example always_comb loops must not create latches or ff,
> always_ff must not create latches and must have at least one ff,
> and so on.
>
> One principle of good language design is to allow the user to express
> his intent to solve his problem. At least some users find being able
> to express their intent for always blocks important enough to add
> them to the language.
>
> K
>
>
>
>
This archive was generated by hypermail 2b28 : Thu Oct 03 2002 - 12:48:01 PDT