Read latency of block ram disappears when ram is clocked from bufgce

[Sam Duncan]

Hi

I'm developing with ISE 4.2, XST and ModelSIM, targeting a Virtex II. I'm
using Xilinx Coregen to generate a block ram with a read latency of 1 cycle
(no input or output registers). When I clock the ram with the system clock
directly, this latency is clearly visible in the simulation results.
However, if I clock the ram with the output of a BUFGCE (with enable held
permanently high), then the simulation results show a zero cycle latency.
ie. the ram data is output in the same cycle that the address is set. If I
regenerate the ram core to include an output register (effectively
increasing the read latency to 2 cycles), then the simulation results show a
latency of 1 cycle.

Am I doing something stupid or is there another explanation?

Many thanks

Sam Duncan

--

[Allan Herriman]

On Mon, 7 Oct 2002 12:49:39 +0200, "Sam Duncan" <s...@peralex.com>
wrote:

This is one of those times when simulation doesn't match synthesis.

The BUFGCE adds a delta delay to the clock signal. This makes the
block ram sense its inputs just after the original clock has changed,
leading to the symptoms you describe. IOW, you have a race condition.

(Use a fixed width font)

Original (that works)

clk
----+--------+--
| |
| |
+---+ +---+
| c | | c |
->|d q|--->|d q|->
| | | |
+---+ +---+
FF BRAM

Version with BUFGCE (and race problem)
BUFG
clk |\
----+-| -----+--
| |/ |
| |
+---+ +---+
| c | | c |
->|d q|--->|d q|->
| | | |
+---+ +---+
FF BRAM

Fix1:

BUFG
clk |\
------| -----+--
|/ |
|
+--------+
| |
| |
| |
+---+ +---+
| c | | c |
->|d q|--->|d q|->
| | | |
+---+ +---+
FF BRAM

Fix2:

BUFG
clk |\
----+-| ---------+--
| |/ |
| |
+---+ +---+
| c | | c |
->|d q|-DELAY->|d q|->
| | | |
+---+ +---+
FF BRAM

(The delay could be a signal assignment like:

sig1 <= sig2 after 1 ns;

BTW, make sure you simulate with +notimingchecks in modelsim.

Regards,
Allan.

[Sam Duncan]

Thanks Allan for your swift and very helpful response. Just one last
question - is it safe to get around this problem by increasing the read
latency to two cycles for simulation, but setting it to one for synthesis?

Thanks again

Sam

"Allan Herriman" <allan_herrim...@agilent.com> wrote in message
news:3da26d7e...@netnews.agilent.com...

[Allan Herriman]

On Tue, 8 Oct 2002 09:20:06 +0200, "Sam Duncan"
<sam_xxn...@peralex.com> wrote:

>Thanks Allan for your swift and very helpful response. Just one last
>question - is it safe to get around this problem by increasing the read
>latency to two cycles for simulation, but setting it to one for synthesis?

I can't say that what you are doing is incorrect (if it works, it
works, right?) but I believe that changing your source files between
simulation and synthesis is bad practice, and will make the design
harder to maintain.

BTW, I suspect some problem with your system level design. Passing
data between "synchronous elements" clocked from different BUFGs in a
xilinx part often means that these signals should be treated as
asynchronous.

Regards,
Allan.