LPM_FIFO+ problem

--- Quote Start ---

Hi,

I have used a couple of dual clock fifo's in my design and have experienced problems with reading data from them. It seems that I have to flush two null words out of the fifo's after a reset, before getting the real data. I have looked at the writing and reading on a logic analyzer and there is no evidence that those two words were written to the fifo by my design. The dual clock nature was necessary for the circuit, because the design requires simultaneous reading and writing to the fifo. The clocks are asynchronous. The write clock is a 4MHz clock, whereas the read clock is the rdreq signal delayed by one 16MHz clock cycle. The asynchronous rdclk is necessary because it is not possible to use a standard clock. The fifo is only read when it is greater than 1/8 full, so it is not a read empty problem. Anyone experienced this problem and have a solution ?

--- Quote End ---

lpm fifos including dual clock are mature and well known to be bug-free provided they pass timing.

your write clock is 4MHz (on every clock).

your rd clock is not clear. what do you mean by 16MHz delay. what do you connect to read clock and what do you connect to rd request.

Hi Kaz,

The write clock is a 4MHz clock, created from a master 32MHz clock. The wrreq pulse is timed to be wide enough to accept one 4MHz clock edge. The rdreq is asynchronous in that no fixed clock will give me a guaranteed clock edge during the time that rdreq is high, so I have taken the rdreq signal, delayed it by 60nS and used it as the rdclk to clock the data through the fifo. The wrreq and rdreq signals are only about 120nS wide. The design works just fine, apart from the first time the fifo is read after a reset. I have to read out two null value words before the valid data apears at the output. Once those two null words have been flushed out of the fifo, the design is absolutely solid without loss of data for hours with millions of read/writes. This anomaly is experienced in both fifos that use the same basic idea.

--- Quote Start ---

Hi Kaz,

The write clock is a 4MHz clock, created from a master 32MHz clock. The wrreq pulse is timed to be wide enough to accept one 4MHz clock edge. The rdreq is asynchronous in that no fixed clock will give me a guaranteed clock edge during the time that rdreq is high, so I have taken the rdreq signal, delayed it by 60nS and used it as the rdclk to clock the data through the fifo. The wrreq and rdreq signals are only about 120nS wide. The design works just fine, apart from the first time the fifo is read after a reset. I have to read out two null value words before the valid data apears at the output. Once those two null words have been flushed out of the fifo, the design is absolutely solid without loss of data for hours with millions of read/writes. This anomaly is experienced in both fifos that use the same basic idea.

--- Quote End ---

I understand then your rdclk is combinatorial. Did you pass timing?

why not use rdreq as clokenable or as rdreq but clock fifo by suitable read clock.

--- Quote Start ---

There were no reported timing problems for this circuit. If the timing did not pass, I would expect the design to fail over a period of time, but it does not. Only at the beginning. The rdreq is effectively used to create a single clock pulse in the middle of the rdreq pulse. The rdclk clock pulse simply looks like a delayed rdreq pulse, so it is guaranteed to clock in the middle of the asynchronous rdreq pulse. The problem as I see it is that if I use a fixed clock input for the rdclk signal, I may or may not get a clock edge during the period when rdreq is actively high, so the words do not clock through the fifo during the read. I tried this originally and I could see on my logic analyzer that the rdreq pulse was not synchronized to any clock and if I used a faster rdclk, I sometimes got more than one clock edge when rdreq was asserted. This caused data loss at the output. The rdreq pulse is generated by PCI local bus register read, so the rdreq timing is dependent upon the PCI local bus cycle. At the moment I am thinking of creating two dummy reads of the fifo in hardware, immediately after doing an aclr, instead of handling dummy reads of the fifo in software. Am I explaining it ok ?

--- Quote End ---

When you say rdreq is decided by PCI then surely it is asking for data read relevant to some clock (not just rdreq) then use that clock as rd clock and use rdreq as it is rdreq. what stops you doing that.

Moreover I feel your write clk is also not a clean 4MHz clock but some combinatorial clk based on 32MHz clk.

If it works then I wouldn't worry now but problems could pop up later.

Hi Kaz,

All I can say is that the rdreq that I saw on my logic analyser was not synchronous with any of my available clocks, probably because of arbitration on the PCI Local Bus. That is why I could not use a fixed clock for the rdclk signal. My 32MHz is a master clock from a crystal input to the FPGA and all other clocks down to 1MHz are created from it, so the 4MHz clock is pretty stable. I will let you know how I get on with the hardware dummy reads.

All,

I am have a similar issue.

My setup:

Quartus 9

MAX II

Windows 10

Write clk 200ns

Read clk 200ns(shifted in phase from Write clk)

small 8bit x 8words (for testing now, will get larger when I understand what is going on)

My problem is not at the beginning but trying to read out the last word. I can write into the LPM_FIFO+. I have it set up as dual clock, but not using the DC module, (it acts the same way). My write clock is 200ns (MHz) which seems ok. I can see the address increment on my write clocks. Example: I can write 4 words without any issues, and I can read out the first 3 words, but no matter what I do, I can not read out the last word.

NOTES:

The write-empty flag goes LO upon the first write clock.. (on I expect that),

The read-empty flag goes LO around 1us after the 2nd write.????

Then the read-empty flag goes HI upon the 3rd read, the write-empty flag stays LO.

No matter how many reads I try after that, I can not read my 4th word I stored......

Also, my wr-address never decrements after each Read??? (shouldn't this count back down??) (the read address KINDA works as expected, it is delayed while writes are being made, but even though it sees the 4th read-clk, the address counts back down to 0, but no new data is available. the data that is on the OUTPUT is the 3rd word).

I do get this warning!

Warning: Assertion warning: Current device family (MAX II) does not support dual-port synchronous RAM -- implementing the synchronous RAM as a DFFE array instead

but I am assuming !! that it behaves the same way as if it was implemented using RAM.

Any ideas?

Keith