Re: [sv-bc] $readmemb and always_latch/always_ff

My thoughts on the subject:

The restriction on always_comb is important to ensure that it behaves
like combinational logic.  The restriction on always_ff is a more arbitrary
one intended to help users avoid mistakes, surprises, and code that won't
synthesize.  So that can be less strict if it helps users.  I think the
answer may be different for always_comb and always_ff, with always_latch
being unclear.

Since always_comb is supposed to represent combinational logic, allowing
the use of $readmem to set any variables it writes is a problem.  It
would make those variables hold that state until the next time an
input changes.  That is not correct combinational behavior.  This would
be surprising and undesirable, and doesn't seem useful anyway.

On the other hand, always_ff is supposed to represent flip-flops.  These
always hold state, and $readmem is just a way of initializing that state.
While having their state set by a mechanism other than normal clocking
is "incorrect", it is easy to understand and they immediately go back to
behaving "correctly" like flip-flops.  It is not surprising and seems
very useful.

With always_latch, it is less clear.  As latches, they are supposed to
have state.  So the fact that $readmem is initializing state within them
is not surprising.  However, when the latch (or perhaps one element in
the case of a RAM) is transparent, it is supposed to behave combinationally.
The sensitivity is defined the same way as always_comb.  So if you do a
$readmem while the latch is transparent, it can cause the output to be
wrong until there is an input change.

Steven Sharp
sharp@cadence.com