DCFIFO megafunction simulation problem

[Altera_Forum]

Hi, 

 I'm attempting to use a DCFIFO megafuction in my design, but, at least during functional simulation (ModelSim-Altera), the last word in the FIFO isn't being read. The rdempty signal asserts once the second last word has been read out. So, either the final read or the final write operation isn't working here. I've been at it for ages, and ss far as I can tell, all of my signals are reading / writing at the correct times, so I can't see where the error is.  I've tried simulating the megafunction on its own, and I can get it working then, so it's just when I use it in my design.  I've attached a couple of images to show the simulated FIFO signals for reference.  Is there something I'm missing?  Cheers,  Alex

[Altera_Forum]

first of all, why are your clocks not clocks (50-50 mark space ratio?) 

 secondly - why is the data changing at a much faster rate than the write clock?  thirdly - in the first picture I cannot see any of the input data. in the second I cannot see any of the rd data in the write data stream.  So I dont think you're using the DCFIFO correctly.

[Altera_Forum]

Probably wrreq signal is misplaced with wrclk...

[Altera_Forum]

First of all, I somehow fixed the problem I was having simply by switching to show-ahead mode. Why did this work? That tells me that the problem was with the read cycle rather than the write cycle. 

    --- Quote Start ---  secondly - why is the data changing at a much faster rate than the write clock?  --- Quote End ---    Tricky, I am reading in data one bit at a time, causing the write data to change at a faster rate. than the write clock. Only once all 8 bits have been read in does the "clock" sample the data. I need to check some bytes of the the data that is coming in, which is why I form words and then send the data to the FIFO, as opposed to having a FIFO that takes in one bit at a time.    --- Quote Start ---  first of all, why are your clocks not clocks (50-50 mark space ratio?)  --- Quote End ---    Again, I am reading in data one bit at a time, and this data rate may change, or the stream of bits may be delayed for some reason, so the write clock signal is asserted only when a new byte of data is available to be written to the FIFO. The same goes for the read "clock". As far as I am aware, it is only the rising edge that matters when writing / reading. Am I wrong? Should I extend the HIGH period of my "clocks"?    --- Quote Start ---  thirdly - in the first picture I cannot see any of the input data. in the second I cannot see any of the rd data in the write data stream.  --- Quote End ---    I'm aware of this. Which is why I put in both pictures. Perhaps I should have explained that the second is a zoomed in version of the first, so you can see the final few write cycles of the clock more clearly. The both show the final few read / write cycles of the FIFO. If you look carefully you'll notice that the last few words written (in the second image) match the last few words read (in the first), with the exception that the last word is missing from the read cycle. This is my problem.  Yeah, I know I'm not using the FIFO completely correctly, and that's the reason for this post. But I am getting 255 of my 256 test words behaving correctly through the FIFO.    --- Quote Start ---  Probably wrreq signal is misplaced with wrclk...  --- Quote End ---    As shown in the images, the wrreq signal is asserted the entire time. Can this still be the problem? I have turned on overflow and underflow protection, if that helps.

[Altera_Forum]

The usage of fifo is wrong. The entire style of doing such design is wrong. You have to understand what is clock and what there are wrreq and rdreq signals for.

[Altera_Forum]

You are very mistaken. Your read clock and write clock should be using the same clock as the data (even if the data is comming in serially) and then the wr-req is high when the data is ready. It is the write request that enables the data into the fifo, not the clock. There is other logic inside the fifo that requires that the clock is always running, not just when you need to write data in (like the address counters, and the logic to cross the counters over the clock domain boundaries). 

 As for lookahead mode, it basically removes an output register from the fifo. With lookahead mode, you use the read request as an acknowledge rather than a request (ie. the q output is valid until you assert rdreq) and with lookahead off, the data only appears when rdreq is assertert, and valid until rdreq is asserted again.  I suggest you read up on the fundamentals of digital logic.