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# 9794

6.1i CORE Generator - Asynchronous FIFO: "Warning: */X_FF RECOVERY Low VIOLATION ON SET WITH RESPECT TO CLK;" is reported when an Asynchronous FIFO is simulated

Description

When I simulate a design with an Asynchronous FIFO, the MTI simulator reports a timing violation similar to the following:

(This applies to post-NGDBuild, post-MAP, and post-PAR (timing) simulation.) This is applicable to SETUP and HOLD violations as well.

# ** Warning: */X_FF RECOVERY Low VIOLATION ON SET WITH RESPECT TO CLK;

# Expected := 0.556 ns; Observed := 0.036 ns; At : 473.85 ns

# Time: 473850 ps Iteration: 0 Instance: /control_tb/u1/u6_notri_reg_noe

# ** Warning: */X_FF RECOVERY Low VIOLATION ON SET WITH RESPECT TO CLK;

# Expected := 0.556 ns; Observed := 0.036 ns; At : 473.85 ns

# Time: 473850 ps Iteration: 0 Instance: /control_tb/u1/u6_notri_reg_port

# ** Warning: */X_FF RECOVERY Low VIOLATION ON RST WITH RESPECT TO CLK;

# Expected := 0.556 ns; Observed := 0.508 ns; At : 473.862 ns

# Time: 473862 ps Iteration: 0 Instance: /control_tb/u1/u3_reg_head_hsi2

# ** Warning : */X_FF SETUP Low violation on I with respect to CLK;

Expected := 1ns; Observed := 0ns; At : 28306ns

Instance /u2_u1_u1_n1541_ffx_sync_ff

The actual message might be different, depending upon the simulator being used.

Source of the Problem:

One cause of this problem might be that the CORE Generator Asynchronous FIFO has different speeds for RD_CLK and WR_CLK. Although different frequencies are allowed, the Asynchronous FIFO has internal signals that cross two clock domains; this means that a synchronization circuit depends on both RD_CLK and WR_CLK. This circuit is needed for the asynchronous feature of the FIFO. The FIFO will still function properly, regardless of timing violations.

If your Asynchronous FIFO has different speeds for RD_CLK and WR_CLK at some point in simulation, the active edges of RD_CLK and WR_CLK might be overlapping; this causes setup time, hold time, and recovery violations on X_FF (SimPrim model), which is being used within the FIFO. Because of the way the X_FF SimPrim model is designed, whenever there is a timing violation, X_FF is designed to output "x" or "unknown." This "x" might propagate throughout your design, causing a problem in the simulation.

In the actual silicon, the "x'' state does not exist, and the flip-flop will always settle to a known value of "0" or "1". The CORE Generator Asynchronous FIFO is designed to work in either case, regardless of the timing violation.

If the violation is indeed coming from the flip-flops crossing the two clock boundaries, this violation can be ignored.

解决方案

If the violations are coming from the Asynchronous FIFO, they can be safely ignored. Regardless of the timing violation, the Asynchronous FIFO will function in the silicon.

If "x" state propagation through your design is a problem, ASYNC_REG attribute can be applied to the failing register element to prevent the "x" state from being produced in your simulation output. The simulator will continue to perform the timing check and will still output the timing violation messages, but you will not see "x" in your simulation. Instead, the X_FF will remain at the previous value in the event of a timing violation.

See (Xilinx Answer 15969) on how to apply ASYNC_REG attribute.

With the FIFO Generator Core, the register elements which crosses the RD_Clk and WR_Clk domains has "ASYNC_REG" attributes applied and will not have this issue. If possible, use FIFO Generator Core.

For Verilog, the simulator directive "+notimingchecks" can be used to prevent the "x" from harming the rest of the simulation. However, this will turn off all timing checks, so working around this issue in this way might not be feasible.

Also, the "no_notifier" switch can be used to turn off "x" propagation when a setup/hold violation occurs.

AR# 9794
创建日期 08/21/2007
Last Updated 12/15/2012
状态 Active
Type 综合文章