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

Presumably the $readmemb is in a procedural block, correct?

Further, $readmemb is really just short hand for a number of file read
statements, and then a number of assignments to various elements of the
memory.

Hence it really does seem to be the case that your testbench is a second
procedural block writing to the memory.
 
Whether it is useful to enforce this rule is a different matter.  But I
can see that indeed by placing a write to the memory in an always_latch
block, one is invalidating the testbench's write.

It might be a useful distinction to allow a second write to an object
which written to by an always_latch block from an initial block; albeit
it would be harder to model reset if the test bench could not place the
$readmemb in an always @(reset) block - the natural way.

Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Stuart Sutherland
Sent: Thursday, April 13, 2006 4:12 PM
To: sv-bc@eda.org
Subject: [sv-bc] $readmemb and always_latch/always_ff


I encountered a compatibility difference between two major simulators
today
during a training class.  One simulator allows a testbench to use
$readmemb
to load a RAM that was modeled using always_latch for the RAM write
logic.
The other simulator gives a compilation/elaboration error, saying that
$readmemb is illegal, because it is a second procedural block writing to
the
memory array.

Which simulator is correct?  While it is true that
always_comb/always_latch/always_ff do not allow multiple procedural
blocks
to assign to the same variable, I do not believe that $readmemb is a
"procedural assignment".  I have a group of students interested in
knowing
if always_latch and always_ff can be used to model RAMs.  Any thoughts
from
SV-BC would be appreciated.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898