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

[Altera_Forum]

Hi, 

 My DCFIFO on Cyclone V is broken. Data is lost. depends on FIFO type, MLAB or M10k, data corruption is severer as FIFO larger.     I wrote to DCFIFO like this:   if(~fifo_full)   fifo_wrreq <= 1'b1  else  fifo_wrreq <= 1'b0;  The above code not work.  I change it like this:  if(~fifo_wrusedw[7])  fifo_wrreq <= 1'b1;  and this works perfectly.   Page 13 of ug_fifo says:   Deassert the wrreq signal in the same clock cycle when the wrfull signal isasserted. &#9632; Deassert the rdreq signal in the same clock cycle when the rdempty signal is asserted  My question is how can I deassert wrreq in the SAME cycle?  Can anybody provide some example code?  Thanks!

[Altera_Forum]

--- Quote Start ---  Hi,  My question is how can I deassert wrreq in the SAME cycle?  Can anybody provide some example code?  Thanks!  --- Quote End ---    use your first code section in a combinatorial way (I assume you have put clock edge statement)

[Altera_Forum]

thanks Kaz, 

 yes, the code is in the always@(posedge clk) block.  So, you mean the following?  wire fifo_wrreq; assign fifo_wrreq = ~fifo_full;  But, how to add the fifo data?  fifo write data has to be registers.

[Altera_Forum]

Also make sure you are using the full flag from the write domain and not the read domain. (It defaults to only bringing out the write domain one, but just in case...)

[Altera_Forum]

Thanks Rysc, 

 currently, the usedw signal works for me. The FIFO behavior at full/empty is really strange.

[Altera_Forum]

What exactly do you find strange? 

Remember that a DC fifo is dual clock, so it takes a few clocks to pass the address pointers accross the domain, so the empty flag will not de-assert for a few clocks after a write operation. Similarly, the full flag will not de-assert until a few clocks after a read operation.

[Altera_Forum]

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

[Altera_Forum]

Hi Tricky, 

 I think Sync FIFO has the same behavior. It is not the sync problem.   Full is caused by wrreq. So, deassert wrreq after the full setting cycle is the user expected, not the same cycle.

[Altera_Forum]

Hi Dave, 

 thanks a lot!  Right now, I am use the same tech to avoid the problem.