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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor russ.dill
Visitor
13,249 Views
Registered: ‎03-28-2011

FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

I'm getting a DRC error on programming file generation:

 

ERROR:PhysDesignRules:2022 - Issue with pin connections and/or configuration on
block:<input_fifo/INPUT_FIFO[0].FIFO_DUALCLOCK_MACRO_inst>:<FIFO36E1_FIFO36E1
>. RST pin should always have ACTIVE signal for FIFO operation.

 

I've tied the RST port of the FIFO to 0, (.RST(1'b0)). Are the tools asking me to manually enable and disable the reset after configuration? Doesn't everything get reset during configuration anyway?

0 Kudos
12 Replies
Historian
Historian
13,241 Views
Registered: ‎02-25-2008

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.


@russ.dill wrote:

I'm getting a DRC error on programming file generation:

 

ERROR:PhysDesignRules:2022 - Issue with pin connections and/or configuration on
block:<input_fifo/INPUT_FIFO[0].FIFO_DUALCLOCK_MACRO_inst>:<FIFO36E1_FIFO36E1
>. RST pin should always have ACTIVE signal for FIFO operation.

 

I've tied the RST port of the FIFO to 0, (.RST(1'b0)). Are the tools asking me to manually enable and disable the reset after configuration? Doesn't everything get reset during configuration anyway?


You don't say which FPGA family you're using, but with Virtex 4 the FIFO had to be explicitly reset after configuration.

----------------------------Yes, I do this for a living.
0 Kudos
Professor
Professor
13,239 Views
Registered: ‎08-14-2007

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

Some hard IP blocks require an active reset signal after configuration.  It looks like

you're using the built-in FIFO logic, which is probably one of those that needs a reset

signal.

 

If you don't have an actual reset input to the FPGA (I rarely do) then you can make one

using a short shift register initialized to all 1's, that gets 0 shifted in after configuration.

In Verilog this looks something like:

 

parameter RES_WIDTH = 4;

reg [RES_WIDTH-1:0] reset_pipe = {RES_WIDTH{1'b1}};

reg reset = 1'b1;

 

always @ (posedge clk) {reset,reset_pipe} <= {reset_pipe,1'b0};

 

-- Gabor
0 Kudos
Visitor russ.dill
Visitor
13,232 Views
Registered: ‎03-28-2011

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

This is with the Virtex-6 LXT.

 

I've tried the short reset, and it does work, but it produces timing errors. Its an asyncronous FIFO with a slow clock and fast clock.

 

 

================================================================================
Timing constraint: PERIOD analysis for net "serial_clk" derived from NET "clk" PERIOD = 10 ns HIGH 50%; multiplied by 7.00 to 70 nS
For more information, see Period Analysis in the Timing Closure User Guide (UG612).
2864 paths analyzed, 2101 endpoints analyzed, 6 failing endpoints
6 timing errors detected. (6 setup errors, 0 hold errors, 0 component switching limit errors)
Minimum period is 71365.000ns.
--------------------------------------------------------------------------------

Paths for end point input_fifo/INPUT_FIFO[2].FIFO_DUALCLOCK_MACRO_inst (RAMB36_X3Y29.RSTRAMARSTRAMLRST), 2 paths
--------------------------------------------------------------------------------
Slack (setup path): -2.037ns (requirement - (data path - clock path skew + uncertainty))
Source: fifo_rst (FF)
Destination: input_fifo/INPUT_FIFO[2].FIFO_DUALCLOCK_MACRO_inst (RAM)
Requirement: 0.002ns
Data Path Delay: 2.056ns (Levels of Logic = 0)(Component delays alone exceeds constraint)
Clock Path Skew: 0.209ns (2.388 - 2.179)
Source Clock: hash_clk_BUFG rising at 4199.998ns
Destination Clock: serial_clk_BUFG rising at 4200.000ns
Clock Uncertainty: 0.192ns

Clock Uncertainty: 0.192ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.070ns
Discrete Jitter (DJ): 0.126ns
Phase Error (PE): 0.120ns

Maximum Data Path at Slow Process Corner: fifo_rst to input_fifo/INPUT_FIFO[2].FIFO_DUALCLOCK_MACRO_inst
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
----------------------------------------------------------- -------------------
SLICE_X105Y151.CQ Tcko 0.246 fifo_rst
fifo_rst
RAMB36_X3Y29.RSTRAMARSTRAMLRST net (fanout=7) 1.557 fifo_rst
RAMB36_X3Y29.CLKBWRCLKU Trrec_RST 0.253 input_fifo/INPUT_FIFO[2].FIFO_DUALCLOCK_MACRO_inst
input_fifo/INPUT_FIFO[2].FIFO_DUALCLOCK_MACRO_inst
----------------------------------------------------------- ---------------------------
Total 2.056ns (0.499ns logic, 1.557ns route)
(24.3% logic, 75.7% route)

 

0 Kudos
Historian
Historian
13,218 Views
Registered: ‎02-25-2008

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.


@russ.dill wrote:

This is with the Virtex-6 LXT.

 

I've tried the short reset, and it does work, but it produces timing errors. Its an asyncronous FIFO with a slow clock and fast clock.

 


Check the data sheet to see if the reset is synchronized internal to the FIFO with one of the clocks. You might need to put a timing ignore on it.

 

See this in the timing report:

 

Source Clock: hash_clk_BUFG rising at 4199.998ns
Destination Clock: serial_clk_BUFG rising at 4200.000ns

 

which indicates that the reset signal is in one domain and the FIFO expects it to be in the other. It's only 2 picoseconds, you know!

----------------------------Yes, I do this for a living.
0 Kudos
Visitor russ.dill
Visitor
13,202 Views
Registered: ‎03-28-2011

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

I switched to the other clock and the violation followed it, again off my 2ps.

0 Kudos
Professor
Professor
13,187 Views
Registered: ‎08-14-2007

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.


@russ.dill wrote:

I switched to the other clock and the violation followed it, again off my 2ps.


This implies that the signal is used in both clock domains, and must therefore be treated

as asynchronous.  You should put a TIG constraint on this to prevent it from using too

much effort during place & route.

-- Gabor
Explorer
Explorer
10,519 Views
Registered: ‎11-16-2012

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

Dear colleague,

 

Could you please help me in solving this issue!!

 

Regards

0 Kudos
Visitor maszoka
Visitor
9,374 Views
Registered: ‎04-22-2015

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

Gabor,

 

I tried this techinque, but the tools did not recognize the reset source as an ACTIVE signal (whatever that might be).

BTW my FIFO is reset by the ~locked of an MMCM, so this sustained PWRON reset should not be necessary in my case.

 

Xilinx support folks, and guys "doing this for a living" - other ideas on what the tools recognize as an active reset source?

 

Thanks, Gabor Becker

0 Kudos
Scholar dwisehart
Scholar
9,367 Views
Registered: ‎06-23-2013

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

Start a new topic.
0 Kudos
Historian
Historian
5,880 Views
Registered: ‎02-25-2008

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.


@maszoka wrote:

Gabor,

 

I tried this techinque, but the tools did not recognize the reset source as an ACTIVE signal (whatever that might be).

BTW my FIFO is reset by the ~locked of an MMCM, so this sustained PWRON reset should not be necessary in my case.

 

Xilinx support folks, and guys "doing this for a living" - other ideas on what the tools recognize as an active reset source?

 


What I do for things that need such a reset is to use the DCM (or PLL, or whatever) locked signal as a sort of reset trigger, and then hold the reset asserted for some number of clocks after the locked goes true. Locked false holds a short shift register in preset (all 1), and then when the locked goes true, you clock a 0 into the shift register and after a bit the shift register output is a 0. 

 

    signal clk : std_logic;  -- could be DCM output or whatever)

    signal iResetSR : std_logic_vector(15 downto 0) := (others => '1');

    alias gReset : std_logic is iResetSR(15);

 

MyReset : process (clk, dcmlocked) is

begin

    if dcmlocked = '0' then           -- not locked

        iResetSR <= (others => '1');  -- ensure our reset remains asserted

    elsif rising_edge(clk) then   

        iResetSR <= iResetSR(iResetSR'left - 1 downto 0) & '0'; -- clock in 0

    end if;

end process MyReset;

 

So at initialization time and whenever the DCM is not locked, the reset is asserted.

16 clocks after the DCM locks the reset will be deasserted. And it will be deasserted synchronous with the clock, so it's ideal for use as a synchronous reset in whatever downstream logic you have.

----------------------------Yes, I do this for a living.
0 Kudos
Visitor maszoka
Visitor
5,499 Views
Registered: ‎04-22-2015

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

Yidfal, 

 

This was suggested before, and I tried this as well.

Every now-and-then when I bump into this error, I keep debugging until I realize the workaround is not to use the built-in FIFO, just revert back to BRAM based FIFOs. Voila, it works.

I think the bitgen DRC error should be caught and reported in the synthesis stage, and the phrase "active signal" should be elaborated more.

 

Regards, Gabor

0 Kudos
Moderator
Moderator
5,405 Views
Registered: ‎02-16-2010

Re: FIFO36E1: RST pin should always have ACTIVE signal for FIFO operation.

active signal would mean which is not a constant and have some logic associated with it.

If you are going forward to use BRAM based FIFO, mark this thread as answered to close it.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos