UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 22462

Virtex-4 FPGA - Why are the FIFO16 flags not working correctly?

Description

Keywords: flags, almost, empty, full

FIFO16 Error Condition and Work-Around Overview

The FIFO16 flags (ALMOSTFULL, FULL, ALMOSTEMPTY, EMPTY), after a very specific sequence of events, transition into a state in which they operate incorrectly. Erroneous settings of the FULL and EMPTY flags can jeopardize even basic FIFO functionality. This answer record details the error condition and describes synchronous and asynchronous clock work-arounds available to ensure robust operation under all operating conditions.

FIFO16 Error Condition

The basic Virtex-4 FPGA FIFO16 will cease to correctly generate the ALMOSTEMPTY and EMPTY flags after the following sequence occurs:

1. A sequence of read and/or write operations makes the number of words in the FIFO equal to the ALMOST_EMPTY_OFFSET threshold (either coming from a higher level as a result of a read operation, or from a lower level as a result of a write operation). This is then followed by either a write or a read operation.
2. If (and only if) the operation immediately following this particular read or write operation is a simultaneous read/write operation, where the enabled read and write active clock edges are coincident or very close (<500 ps) together, the ALMOSTEMPTY flag will be incorrect. Since ALMOSTEMPTY is a condition for decoding EMPTY, the EMPTY flag will also be wrong.

A similar sequence of operations around the ALMOST_FULL_OFFSET will cease to generate correct ALMOSTFULL and FULL flags.

Solution

Synchronous Clock Workaround

In a synchronous design, simultaneous operation can be avoided by offsetting the read and write clocks by about 1 ns. This is easily achieved by using opposite clock edges for the read and write clocks. In most applications, this will require data resynchronization registers to bring read and write back together in the same clock domain. Figure 1 describes the concept. This resynchronization must be done on the input side so that the critical Empty flag avoids any latency. The Full flag is eliminated, as it would not be useful with its 2-clock latency; use AlmostFull instead. You must tightly constrain the connections between the input registers and the FIFO16, as this part of the circuit effectively runs at twice the clock rate.

Figure 1 - Synchronous Clock Work-Around
Figure 1 - Synchronous Clock Work-Around


Asynchronous Clock Work-Around

In an asynchronous design, it is inevitable that the two clocks will occasionally come very close (<500 ps) to each other, which might cause the problem described above, and no clock delay manipulation can then avoid this problem. For this case, Xilinx has developed a solution that uses additional circuitry to ensure that the FIFO16 never gets into the erred state. This solution operates in a similar manner to the basic FIFO16 and works under all conditions and clock frequencies.

The composite FIFO adds a small LUTFIFO, acting as an asynchronous buffer that allows the FIFO16 to always operate in synchronous mode. It is necessary to connect the faster clock to the FIFO16 port so that the smaller LUTFIFO never becomes a bottleneck. This constraint leads to two separate designs, as described below and shown in Figures 2 and 3.
In a case where you do not know which clock is faster, the "WRCLK faster than RDCLK" design should be used. This design will work for any clock frequency combination, including WRCLK faster than RDCLK, WRCLK identical to and/or phase-shifted with respect to RDCLK, and even if the WRCLK and RDCLK relationship is unknown. When this design is used, and RDCLK is faster than WRCLK in the system, it is possible for the EMPTY flag to assert before the ALMOSTEMPTY flag asserts (note that if the two clocks are nominally the same, this will not occur). This is because the intra-FIFO control logic is running off of WRCLK, which is designated as the faster clock but is really the slower clock in the system. This will not cause data corruption or incorrect FIFO behavior in any other manner. If this situation exists and this behavior is not acceptable, it is recommended that you use the CORE Generator FIFO Generator Block RAM work-around described below.

Some additional logic controls the transfer of data between the two FIFOs for both designs. Resynchronization of specific signals and handshaking between the two FIFOs results in a small uncertainty of the composite FIFO depth and of the Almost_Full_offset and Almost_Empty_offset. Refer to Table 1 for details.

WRCLK faster than RDCLK design

In this case, the WRCLK of the FIFO is connected to WRCLKFIFO16. The RDCLKFIFO16 and WRCLKLUTFIFO are driven from WRCLKbar, which is a 180-degree phase-shifted version of WRCLK. The RDCLK of the FIFO is connected to RDCLKLUTFIFO. FIFO16 forms the write interface of the composite FIFO; its read side is clocked by the inverted write clock, which is also used to write into the small LUTFIFO.

Figure 2 - WRCLK faster than RDCLK design
Figure 2 - WRCLK faster than RDCLK design


RDCLK faster than WRCLK design

In this case, the WRCLK of the FIFO is connected to WRCLKLUTFIFO. The RDCLKLUTFIFO and WRCLKFIFO16 are driven from RDCLKbar, which is a 180-degree phase-shifted version of RDCLK. The RDCLK of the FIFO is connected to RDCLKFIFO16. The LUTFIFO forms the write interface of the composite FIFO; its read side is clocked by the inverted read clock, which is also used to write into the FIFO16. LUTFIFO flags are combined and synchronized to the write clock to generate the AlmostFull flag.

Figure 3 - RDCLK faster than WRCLK design
Figure 3 - RDCLK faster than WRCLK design


User-programmable flag settings in the Composite FIFO

The offset ranges for user-programmable AlmostEmpty and AlmostFull flags along with the FIFO capacity are listed in Table 1. Since the full capacity of any FIFO is normally not critical, most applications use the ALMOSTFULL flag not only as a warning but also as a signal to stop writing. The ALMOSTEMPTY flag can be used as a warning that the FIFO is approaching Empty, but to ensure that the very last entries in the FIFO are read out, you should continue reading until Empty is asserted.

When setting the offset ranges in the provided Perl script (refer to Design Files below), use decimal notation.

Table 1 - FIFO Capacity and Effective almostfull/ almostempty Flag Offsets
Table 1 - FIFO Capacity and Effective almostfull/ almostempty Flag Offsets


NOTES:
FIFO16 = Capacity of FIFO16. Refer to the Virtex-4 FPGA User Guide (UG070), Chapter 4: Block RAM, Table 4-9: FIFO Capacity:
http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=User+Guides&iLanguageID=1
Navigate to FPGA Device Families -> Virtex-4 -> Virtex-4 User Guide.

AFFIFO16 = Set by user in Perl script, sets the FIFO16 ALMOST_FULL_OFFSET. Refer to the Virtex-4 User Guide (UG070), Chapter 4: Block RAM, Table 4-13: FIFO Almost Full/Empty Flag Offset Range:
http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=User+Guides&iLanguageID=1
Navigate to FPGA Device Families -> Virtex-4 -> Virtex-4 User Guide.

AEFIFO16 = Set by user in Perl script, sets the FIFO16 ALMOST_EMPTY_OFFSET. Refer to the Virtex-4 User Guide (UG070), Chapter 4: Block RAM, Table 4-13: FIFO Almost Full/Empty Flag Offset Range:
http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=User+Guides&iLanguageID=1
Navigate to FPGA Device Families -> Virtex-4 -> Virtex-4 User Guide.
All values may vary by up to 3 words, depending on the read/write clock rates and the read/write patterns.

Status Flags

While the functionality of the status flags on the composite FIFO remain the same, the assertion/deassertion latencies for some of the signals have increased. Note that the assertion values for key signals have remained the same as on the FIFO16 (EMPTY, FULL, ALMOSTEMPTY, ALMOSTFULL, RDERR and WRERR). Table 2 lists the latency values for the status flags. Also note that the values have an uncertainty that is affected by the frequency ratios of the read/write clock, as well as the read/write patterns.

Table 2 - Clock Cycle Latency for Status Flag Assertion and De-assertion
Table 2 - Clock Cycle Latency for Status Flag Assertion and De-assertion


NOTE: Latency values in bold vary with the ratio between the read/write clock frequencies and read/write pattern. In certain conditions for WRCLK > RDCLK, the ALMOSTEMPTY flag deasserts before the EMPTY flag. This behavior will be reflected in simulations, and increasing the ALMOST_EMPTY_OFFSET will rectify the behavior.

Resource Utilization

The design was implemented using ISE 8.1i with default settings for MAP, Place, and Route. The approximate LUT count for a x4 design varies from 55 to 70 LUTS. For a x9 the LUT count varies from 65 to 80 LUTs, and for a x18 design the LUT count varies from 85 to 100 LUTs. The LUT count for a x36 design varies from 125 to 130 LUTs.

Performance Expressed in Maximum Read and/or Write Clock Frequency

The maximum read and/or write clock rate is >500 MHz for all configurations and modes, except for the 512 x 36 configuration with write clock > read clock, where the max frequency for standard mode is 473 MHz, and for FWFT mode it is 488 MHz.

Design Files

All the necessary files required for the asynchronous solution can be downloaded from the linked zip files below. A Perl script is provided to generate the "ngc" file and simulation model for the different FIFO configurations. A "readme" file is also included to instruct you on how to use the Perl script and resulting files. The Perl script provides three clocking options: write clock > read clock (Figure 2), read clock > write clock (Figure 3), and write clock = read clock (also uses Figure 2). Note that for the synchronous case, Figure 1 is not implemented in the Perl script. If this design is desired, you should insert the registers as illustrated in Figure 1.

The ZIP file containing the Perl script can be found here:
http://www.xilinx.com/xlnx/xweb/xil_publications_file.jsp?iLanguageID=1&ipoid=24332297&category=-1210766&filename=v4_fifo16_1_0_1.zip&file=531

or here:
http://www.xilinx.com/xlnx/xweb/xil_publications_file.jsp?iLanguageID=1&ipoid=24332297&category=-1210766&filename=v4_fifo16_1_0_1.tar.gz&file=532


This solution has been tested with ISE version 7.1i Service Pack 4, 8.1i, and 8.1i Service Pack 1, and ModelSim version 6.1SE.
NOTE : When the script is used the RDCOUNT and WRCOUNT may not be an accurate representation of the number of bits read and written to the FIFO.

CORE Generator Workaround
FIFO Generator 3.2 (onwards) automatically implements the workaround detailed above. The device utilization is detailed in the core data sheet.
http://www.xilinx.com/bvdocs/ipcenter/data_sheet/fifo_generator_ds317.pdf

Both synchronous and asynchronous FIFOs can be implemented using FIFO Generator block RAM FIFOs available from CORE Generator instead of using the FIFO16 primitives. The block RAM-based implementations will be slower than FIFO16-based implementations, because the FIFO control logic is implemented in the fabric of the device. The FIFO16 built-in FIFO configurations from the FIFO Generator Core will incur the same issues described above. Please review the FIFO Generator Data Sheet for more information:
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=PRODUCTS&sSecondaryNavPick=Intellectual+Property&key=FIFO_Generator

Software Updates

Starting with ISE 8.1i Service Pack 1 software, the tools will automatically detect when a synchronous FIFO16 (RDCLK and WRCLK are connected) has been inserted into a design and will issue the following warning:

"WARNING:PhysDesignRules:1447 - FIFO16 XLXI_1 has been found to have both RDCLK
and WRCLK input pins connected to the same source XLXN_5_BUFGP. Under certain
circumstances, the flag behavior to the FIFO may be undeterministic. Please
consult the Xilinx web site for more details."

To remove this warning, use the downloadable Composite FIFO solution or the Synchronous FIFO work-around described above.

Software IP Cores

For information on what software IP Cores are affected by this issue, please check the following page:
http://www.xilinx.com/ipcenter/coregen/advisories/ip_cores_impacted_by_fifo16_ar22462_issue.htm

AR# 22462
Date Created 09/04/2007
Last Updated 07/28/2009
Status Active
Type General Article