strange behavior of DCFIFO, how to meet the "Functional Timing Requirements"

I posted some FIFO examples in this thread:

http://www.alteraforum.com/forum/showthread.php?t=38988

If you read the notes in altera_fifos/test/dcfifo_tb.vhd you will see ...

-- ----------------------------------------------------------------
-- Notes:
-- ------
--
-- 1. wrempty and wrused have different latencies.
--    Regardless of the showahead/use_eab settings, the first
--    assertion of wrreq causes empty to deassert, and then
--    one clock later wrused transitions to 1. Assertions
--    of wrreq are followed one clock later by increments of
--    wrused.
--
--    The rdempty and rdused signals have a similar 1 clock
--    latency between them after the initial write, and during
--    the last read (empty asserts, but rdused is still 1.
--
--    This inconsistency in timing would complicate the
--    generation of an almost-empty indicator.
--
-- ----------------------------------------------------------------

So basically there is a latency between the flags and the counters. This means you need to be careful when using both the flags and the usedw ports.

You can deal with the latency issue by creating making the thresholds lower than needed, eg., here's some code from a bridge which can be configured for single- or dual-clock mode

-- Write-FIFO almost-full
--
-- The scfifo afull value asserts when the usedw
-- value is greater or equal to the ALMOST_FULL_VALUE.
-- The dcfifo wrusedw value is pipelined by one
-- more clock than the scfifo usedw value, so subtract
-- 1 from the user-specified almost-full value to avoid
-- the possibility of overflow.
--
sbe_wfifo_afull <= '1' when
    (sbe_wfifo_used >= to_slv(
        WFIFO_AFULL_VALUE-1, WFIFO_WIDTHU)) else '0';

Cheers,

Dave