--- Quote Start ---
it may not be right to blame timing on fifo rate problems. Since you lose some data and repeat others, it points more to flow control and possibly fifo being working close to full/empty points. one issue with fifos is when it gets full it may need emptying by reset as it hits near full point and never recovers.
--- Quote End ---
My FIFO is bigger than required for my design, which should ensure that I get no full points, and my logic also looks for the FIFO_FULL flag and will not write to the fifo if it is full.... also once the fifo is filled as with 1 line of data (2400 words of 8 bits each, in a buffer 8 bits wide, and 4069 words long) the data is clocked out until the buffer is empty. So I don't really think that there should be any problems with the fifo with respect to writing to it when its full, or reading from it when it's empty.
I am trying to read the data in on the rising edge of my MULT_CLK, which is 4x faster than my LVDS_CLK. These clks are synchronised as LVDS_CLK is used to generate MULT_CLK using a PLL. I have 3 cycles where a byte of data is clocked into the FIFO, and one rising edge of MULT_CLK where a byte is not clocked in (to avoid any race conditions when the next 24bit word is loaded into the FPGA using the LVDS_CLK).
I have tried to use the mutlicycle function in TimeQuest to ensure that the correct edge of the latch clock is constrained for the corresponding paths for setup. However, when using multicycle to constrain the hold times, rather than my launch and latch clock occuring at 0ns it they occur 1 period of the slower launch clock later. Is this what I should be expecting? As the launch for setup occurs at 0ns but the launch for hold occurs at 30.011...
Regards,
Lee H
Honored Contributor
