a problem in using the fifo

[Altera_Forum]

Recently, i designed a project, in the project i used fifo ip core. the fifo has wraddr and rdaddr port.  

As my understanding , if i read the fifo , these two address should decrease, if i write the fifo , these two address should increase. And i use the signaltap logic analyzer verifed it is right.  But when my project runs in the fpga, the fpga is not stable, the problem is caused by the fifo . i use the signaltap test the fifo and found that the fifo 's two address(wraddr and rdaddr)always decreased even i write the fifo .  i don't know why? because design time is limited , i have to use the following method to solve this problem: when the fifo is in wrong runing , i reset the fifo. Using this method , i basically solve this problem.  Can someone tell me where the fifo 'problem is?

[Altera_Forum]

Decrease? The FIFO counters should always increase. A write increases the write pointer and a read increases the read counter. The difference between these two counters is basically how many words are in your FIFO. Now technically, the FIFO should always count up, but there's a very strange situation where it can "flip" and always count down. The only way this will happen is if you have a glitchy clock. There's a thread on here about it.  

http://www.alteraforum.com/forum/showthread.php?t=1615&highlight=gray+counter I would first signaltap when it's working and make sure they always increase, then find what the do when its not working(it's hard to debug since it's a gray counter, not binary, and so the direction isn't obvious). If it's truly flipping to counting down, then you have a glitch on your clock.

[Altera_Forum]

thank you Rysc, the name i typed two address yesterday is wrong, the two address is not wraddr and rdaddr, it is rdusedw and wrusedw. i used the fifo module. the verilog logic is as following: 

 fifo_receiver U1(  .aclr(fifo_aclr),  .data(fifo_data_in),  .rdclk(clk_out),  .rdreq(clk_out_en & rd),  .wrclk(clk_in),  .wrreq(write_fifo_8_req),  .q(data_out),  .rdempty(fifo_empty),  .rdusedw(fifo_8_rdusedw[9:0]),  .wrfull(fifo_full),  .wrusedw(fifo_8_wrusedw[9:0])  );   the wrclk and the rdclk are asynchronous. the wrclk is 100MHz clock in burst mode. the rdclk is a stable 27MHz clock. i.e.the fifo is read by a constant 27MHz clock, when the fifo is almost empty, the 100MHz write clock write some byte into the fifo, when the fifo is almost full, the write clock stops write.   normally, the wrusedw and rdusedw increase together in the writing period and decrease in the not-writing period.   the problem i met is sometimes the wrusedw and rdusedw always decrease in the writing period and Not-writing period. And sometimes the two address always increase. This makes the system work in the wrong condition.

[Altera_Forum]

Is this for long periods of time, or just a few writes? The usedwds can be a little finnicky to do their cross-clocking latency, so sometimes they might act unexpectedly for a few clocks. But over time, this naturally shouldn't be occurring.

[Altera_Forum]

for a long time , the two address always decrease until overflow or empty.

[Altera_Forum]

It may be the clock glitch issue. The core problem is that a toggle flip-flop gets inverted in the gray counter, and there's no way for it to recover from this. So every time that counter gets a signal to increment, it instead decrements(and the FIFO gray counters should always increment). I would signaltap those counters and study them. Since they're gray coded, it's not obvious which way they're counting. I signaltapped a long stretch of them, and looked at the sequence when it was working, then realized when it stopped working it was going in the opposite order. 

By the way, I "think" this is fixed in Q9.1, where the gray counters would do one count in the wrong direction and then recover back to the right direction. This would still corrupt your data stream, but only a word or two rather than a continous problem. Of course, more fundamentally, having a clock glitch is a bigger problem and should be fixed at the source. (Is your clock coming from a PLL? If it is, there should be no glitch. The only cases I've seen is when they bypassed the PLL and had a noisy external clock. In one case, adding the PLL cleaned it up...)

[Altera_Forum]

thank you very much. 

the write clock comes from the transceiver's rxclkout, the read clock comes from a vcxo from outside.  now when the fifo is in wrong state , other logic will reset the fifo. but this can not totally solve the fifo's problem.  The problem always appeared as the device just startup. When the device is working , the problem will not appear.

[Altera_Forum]

Out of power-up? You've got a recovery/removal problem.  

http://www.alteraforum.com/forum/showthread.php?t=5026&highlight=recovery+removal I imagine your write flag is high out of reset? Either delay it, or synchronize your reset to the write clock domain(and have it meet recovery/removal timing, which should occur automatically). I think there are some other posts about the reset of the FIFOs. Anyway, either method should fix your problem.