Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20765 Discussions

MegaWizard FIFO misses first write

Altera_Forum
Honored Contributor II
1,578 Views

I'm using a MegaWizard FIFO in my CPLD design and it always misses the first data written to it after a reset. I've done everything I could think of in changing the edge of the write signal, creating a special clock using a state machine and nothing i do will result in the FIFO getting the first byte of data. Every write after that works perfectly. Has anyone experienced that? Is there a defect in the FIFO plugin? 

 

Here is the interface to the FIFO: 

fifo tx_fifo( .aclr(rst), .data(tx_byte), .rdclk(clk), .rdreq(tx_read_fifo), .wrclk(tx_wrclk), .wrreq(tx_wrreq), .q(tx_fifo_data), .rdempty(tx_fifo_empty), .wrfull(tx_fifo_full));  

Basically all you need to do is set the wrreq true, put data on the data input and then give it a wrclk (pos edge signals). I can see that this cycle works fine in subsequent writes, but something is screwy with the first one after a reset (aclr).
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
862 Views

Is your reset synchronized to the write clock within the MegaFunction(there's an option to do that). That basically pipelines the reset to the write domain, which means it won't come out of reset for a clock or two later than you'd expect. Just a guess.

0 Kudos
Altera_Forum
Honored Contributor II
862 Views

I used the asynchronous clear. I've tried letting a bunch of clock cycles go by before trying to write. Does not improve the situation.

0 Kudos
Altera_Forum
Honored Contributor II
862 Views

Further puzzles: after a reset (with plenty of cycles after reset goes false) I write 3 bytes in then start reading them out. The first byte is always 0 regardless of what I wrote in. The second byte I read is the first byte I wrote in. As soon as I read the second byte the rdempty signal goes true so my code thinks there are no more bytes. But later when I write more in and then read them out I get that 3rd byte that I originally wrote. 

 

It seems like the internal logic of the fifo is all off by one byte, both what it stores and what the rdempty reports. Am I crazy or what?
0 Kudos
Altera_Forum
Honored Contributor II
862 Views

Can you please verify that your tx_read_fifo, tx_fifo_empty and tx_fifo_dat are clocked with clk. Furthermore, tx_byte, tx_wrreq and tx_fifo_full should be synchronous with tx_wrclk.

0 Kudos
Altera_Forum
Honored Contributor II
862 Views

Any new solutions here? I have the same problem, but with a single clock fifo.

0 Kudos
Reply