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: 
Highlighted
Visitor spajas
Visitor
876 Views
Registered: ‎08-20-2018

XPM FIFO wr_rst_busy/rd_rst_busy strange behaviour

Jump to solution

We are currently developing a product with a VUP13 and encounter strange fifo reset behaviour. I'm aware of the fifo_generator and XPM documentation. The first mentions clearly that wr_rst_busy/rd_rst_busy cannot be used for non-common clock fifo memories (bram, distributed ram). Those can only be used by the dedicated internal FIFOs and common clock memory fifo's. The latter link does not mention this at all for the XPM ASYNC fifo.

Because we did not have this knowledge a week ago, we have developed a component that makes use of the XPM async FIFO with an explicit distributed memory implementation and NO common clocks. That XPM macro has both wr_rst_busy and rd_rst_busy pins on its entity and we make use of those in a FIFO controlling state machine. This component is then instantiated multiple times in a higher level component.

With this implementation we see strange behaviour. Some of the instantiated FIFO components we developed are working as expected. They get a reset sometimes and both wr_rst_busy and rd_rst_busy behave as expected. After some time the signals are both low ('0') and the state machine continues.

However for some other instantations of the very same component, this does not work correctly. They receive the same reset once in a while but both the wr_rst_busy and rd_rst_busy stay high ('1') all the time. We are 100% sure all the instantiations have a free-running clocks with no interruptions of any kind.

Our XPM async FIFO generic config:

   xpm_fifo_async_inst : xpm_fifo_async
    generic map (
      CDC_SYNC_STAGES       => 2,                  -- DECIMAL
      DOUT_RESET_VALUE      => "0",                -- String
      ECC_MODE              => "no_ecc",           -- String
      FIFO_MEMORY_TYPE      => "distributed",      -- String
      FIFO_READ_LATENCY     => 1,                  -- DECIMAL
      FIFO_WRITE_DEPTH      => 32,                 -- DECIMAL
      FULL_RESET_VALUE      => 0,                  -- DECIMAL
      PROG_EMPTY_THRESH     => 4,                  -- DECIMAL
      PROG_FULL_THRESH      => 28,                 -- DECIMAL
      RD_DATA_COUNT_WIDTH   => 6,                  -- DECIMAL
      READ_DATA_WIDTH       => 24,                 -- DECIMAL
      READ_MODE             => "std",              -- String
      RELATED_CLOCKS        => 0,                  -- DECIMAL
      USE_ADV_FEATURES      => "1F0F",             -- String
      WAKEUP_TIME           => 0,                  -- DECIMAL
      WRITE_DATA_WIDTH      => 24,                 -- DECIMAL
      WR_DATA_COUNT_WIDTH   => 6                   -- DECIMAL
    )

 

My questions:

  1. Is it correct that we cannot make use of wr_rst_busy/rd_rst_busy pins when we make use of the XPM async FIFO with no common clocks and distributed memory?
  2. If so, shouldn't this limitation be mentioned in the XPM FIFO documentation (and even in the comment-block of the Vivado XPM FIFO templates)?
  3. If so, what can we do to detect that the async FIFO reset is finished and we can reliably write/read from it? A reset counter?
  4. If so, why do wr_rst_busy/rd_rst_busy show undefined behaviour? Should it not be better to tie them to '1' or '0'?
  5. If we are incorrect @1, why do we get different behaviour between exact same instances of our component?
  6. If we are incorrect @1, why does the fifo_generator documentation mentions the limitation?
  7. If we are incorrect @1, would it be a suggestion to explicitly state in the XPM FIFO documentation that the limitation mentioned in the fifo_generator does not apply for the XPM FIFOs?

 

Please enlighten me... Thanks!

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
823 Views
Registered: ‎08-08-2017

Re: XPM FIFO wr_rst_busy/rd_rst_busy strange behaviour

Jump to solution

Hi @spajas 

Please find the answeres to your question

  1. Is it correct that we cannot make use of wr_rst_busy/rd_rst_busy pins when we make use of the XPM async FIFO with no common clocks and distributed memory? 

      -> No it is not correct , you can use the wr_rst_busy signal and rd_rst_busy signal in this configuration. The reset timing diagram is applicable to BRAM and DRAM based implementation.

Capture.JPG

      2. If so, shouldn't this limitation be mentioned in the XPM FIFO documentation (and even in the comment-block of the Vivado XPM FIFO templates)?

     -> Follow answer 1

       3. If so, what can we do to detect that the async FIFO reset is finished and we can reliably write/read from it? A reset counter?

     -> Wr_rst_busy transition from 1 to '0'.

       4. If so, why do wr_rst_busy/rd_rst_busy show undefined behaviour? Should it not be better to tie them to '1' or '0'?

     -> Follow answer 3.

Can you please share the ILA screenshot depicting any anamolous behaviour which is not as expected ?

 

-------------------------------------------------------------------------------------------------------------------------------
Reply if you have any queries, give kudos and accept as solution
-------------------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
4 Replies
Moderator
Moderator
824 Views
Registered: ‎08-08-2017

Re: XPM FIFO wr_rst_busy/rd_rst_busy strange behaviour

Jump to solution

Hi @spajas 

Please find the answeres to your question

  1. Is it correct that we cannot make use of wr_rst_busy/rd_rst_busy pins when we make use of the XPM async FIFO with no common clocks and distributed memory? 

      -> No it is not correct , you can use the wr_rst_busy signal and rd_rst_busy signal in this configuration. The reset timing diagram is applicable to BRAM and DRAM based implementation.

Capture.JPG

      2. If so, shouldn't this limitation be mentioned in the XPM FIFO documentation (and even in the comment-block of the Vivado XPM FIFO templates)?

     -> Follow answer 1

       3. If so, what can we do to detect that the async FIFO reset is finished and we can reliably write/read from it? A reset counter?

     -> Wr_rst_busy transition from 1 to '0'.

       4. If so, why do wr_rst_busy/rd_rst_busy show undefined behaviour? Should it not be better to tie them to '1' or '0'?

     -> Follow answer 3.

Can you please share the ILA screenshot depicting any anamolous behaviour which is not as expected ?

 

-------------------------------------------------------------------------------------------------------------------------------
Reply if you have any queries, give kudos and accept as solution
-------------------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
Visitor spajas
Visitor
812 Views
Registered: ‎08-20-2018

Re: XPM FIFO wr_rst_busy/rd_rst_busy strange behaviour

Jump to solution

@pthakare Thank you for your answer. You mention 1) is not correct. However, if I read this from the "fifo_generator 13.1", page 19:

wr_rst_busy
Output: When asserted, this signal indicates that the write domain is in reset state.
Note:Available only for UltraScale device built-in FIFOS.

And on page 24:

wr_rst_busy
Output: When asserted, this signal indicates that the write domain is in reset state.
Note:Available only for UltraScale device built-in FIFOs, and 
Common Clock Block RAM/Distributed RAM/Shift Register FIFOs with synchronous reset.

Finally, when we select distrubuted RAM for the FIFO logic with NO common clock using the IP .XCI-merthod (graphical configuration), the wr_rst_busy/rd_rst_busy signals are not available. The option "Enable Safety Circuit" is grayed out and cannot be selected.

To confure the reader (me), the following is stated on page 79:

wr_rst_busy: Available for UltraScale architecture built-in FIFOs and UltraScale architecture non-built-in FIFOs with synchronous reset.

So for me, it is still not clear if you can use wr_rst_busy/rd_rst_busy with distributed RAM with no common clocks. Please explain why you say it is possible. Any other docs?

 

Some other notes:

  • I know how to use wr_rst_busy/rd_rst_busy. We use this in several other components with no problem (those FIFO's are block-rams with common and no common clocks). 
  • Sadly, I do not have the ILA output anymore. But for the affected instantiations, Write enable was low when the FIFO is reset. The reset input was more than 100-clocks long and the clock was not disrupted. wr_rst_busy went from '0' -> '1' and stayed there. 'Forever'. Even long after the reset-input was de-asserted
0 Kudos
Moderator
Moderator
804 Views
Registered: ‎08-08-2017

Re: XPM FIFO wr_rst_busy/rd_rst_busy strange behaviour

Jump to solution

Hi @spajas 

The documentation you are following is for FIFO generator IP and not for XPM.  FIFO IP uses direct primitive instatiations whereas XPM is BRAM/URAM primitive plus

some logic around it. 

Morevover Buiilt in FIFO impelmentation is not supported through XPM. 

In case of XPM , Wr_rst_busy and wr_rst_busy are derived signal and not directly coming from RAMB36E2/RAMB36E1 primitive.

XPM_FIFO_ASYNC section in UG74 will give you the better inisght of this

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_3/ug974-vivado-ultrascale-libraries.pdf

 

 

-------------------------------------------------------------------------------------------------------------------------------
Reply if you have any queries, give kudos and accept as solution
-------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Visitor spajas
Visitor
798 Views
Registered: ‎08-20-2018

Re: XPM FIFO wr_rst_busy/rd_rst_busy strange behaviour

Jump to solution

Hi @pthakare 

Thank you for your quick response. You answered a question I forgot to ask: "Does XPM add additional logic so wr_rst_busy/rd_rst_busy always work, in any configuration?". I'm happy to read it does.

Sadly, I'm not able to show the ILA output as my colleague went for a different implementation: Wait 256 wr clock cycles after reset before accessing the FIFO. This solution works, but is not prefered. As we meet a deadline, we will investigate the stuck wr_rst_busy at a later time.

Thanks again for you support.

0 Kudos