Subject: RE: always_comb semantics
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Thu Oct 03 2002 - 11:22:50 PDT
>
>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?
> >
> > 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 - 11:27:04 PDT