Wierd Fifo RdReq problem

[Altera_Forum]

Hello All, How are you? 

 I am kinda new to altera and FPGA's so mind me for my simple mindedness.  Anyways I am designing a Colorization Unit for a 12bit gray scale video feed. Basicaly this block contains two fifos.  A Receive Fifo and tx Fifo. The unique problem is that the Receive Fifo works perfectly fine and always stores and gives the data it is suppose to. I have confirmed this using simultation and Signaltap.   But for some reason the Tx fifo which is used to send data to a scaler unit messes up once( skips a read req) and does not deliver the requested data, Hence causing the whole system to be out of sync. I find this a really weird problem , as after this one messup the system stays in sync and does not mess up any more.  Hope some one can help.  Thanking you Nadeem

[Altera_Forum]

Does the "mess-up" always occur in the same manner? Is it always the first read after configuration/reset? What has happened to the FIFO(have there been a good number of writes to the FIFO, i.e are you sure data is in it and it's not empty)? Is it synchronous or asynchronous?

[Altera_Forum]

Thanks Rsyc for your reply. 

 Well I have got buffer overflow and underflow protection, but at the same time i have made in built protection, so the module does not messup. Well its Odd as this messup happens some around 4000 reads. But mind you it only happens once and does not occur again.  Yes it seems the mess up happens exactly at the same place every time which i find very odd. The fifo is running in Async mode.  hope to hear back from you , regards Nadeem

[Altera_Forum]

Hmmm. A few more questions... Is this in simulation or in SignalTap? How deep is the FIFO and what are the usedwords at(is it near a thresh-hold, full or empty)? Do you see the rdreq actually strobing(or is it just held high and you're streaming). My initial guess is that you've hit a full/empty threshold and the the rdreq or wrreq is ignored. Note that if you're even near the threshhold's the flag's can "act funny" in an asynch FIFO, because they need to be pro-active. (An example is that you might be approaching empty, but not really quite there yet, and the wrempty flag goes high for a clock or two. If you do a read, it will be ignored. But even if you don't do anything, a clock or two later the empty flag would then go low, and that's because the rdpointer and wrpointers have synched up.) Also make sure you're using the right domain pointer, i.e. the rdempty flag to stop reads because the FIFO is empty and the wrfull flag to stop writing because it is full.

[Altera_Forum]

Hi Rysc, 

 Well i am observing this problem through both signal tap and simulink simulation.  Well I have put logic in there to prevent the fifo from hitting its thresh hold. It makes sure not to allow to write to it if almost full and not to read from it when almost empty.  This particular fifo has a with of 512 words of 8 bits and is set to be a show ahead fifot.( mind you i changed it to be a show ahead fifo thinking it might solve the problem).  The unusual thing is this fifo works fin with any other block except the scaler block. It seems the problem occurs when the scaler requests for data in burst mode and then suddenly switch to continuous mode( 1 byte at a time), causing the fifo to miss one read request.  I have tried my block with other blocks and they work fine.  hope to hear from you soon. regards Nadeem

[Altera_Forum]

It sounds like the scaler block is doing something unexpected, not the FIFO. Now, the fact that it occurs in the simulink simulation makes me guess this is the way it is supposed to work. Are you able to do an RTL simulation(easier than SignalTap in that you can quickly and easily access all the nodes.) But the fact that simulation agrees with hardware usually means it's working as it's supposed to, this just may not be as expected. 

I don't know anything about the scaler, but you might want to try simulating it by itself and just see what happens "differently" when it switches mode. My hunch is you'll find something(if it worked the same way, it wouldn't make sense that this is what initiates the change.) One other thing is that you probably only have one SignalTap clock, which means it is either related to the write clock or the read clock, but not both. So maybe you're missing an extra pulse in the other clock domain, or something like that. Maybe two writes occur when the scaler switches, which looks like it's missing a read in the read domain. But again, it really sounds like the FIFO is not the problem.