Subject: RE: always_comb semantics
From: Michael McNamara (mac@verisity.com)
Date: Thu Oct 03 2002 - 13:41:35 PDT
Karen Pieper writes:
>
> >
> >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?
Synthesis tools? Sure, lets get rid of them. :-) :-)
> > > 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
Can I infer then, that a simulator should treat always_ff,
always_comb and always in exactly the same manner as one another?
If so, then I would support making this distinction an attribute
rather than a new construct in the language.
-mac
This archive was generated by hypermail 2b28 : Thu Oct 03 2002 - 13:44:00 PDT