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: 
Scholar ronnywebers
Scholar
1,147 Views
Registered: ‎10-10-2014

XPM_FIFO_ASYNC reset behaviour

I'm performing some simulations on the XPM_FIFO_ASYNC to understand better the wr_rst_busy and rd_rst_busy outputs.

 

1) 'power on reset' of the XPM_FIFO_ASYNC

 

There seems to be some 'automatic' internal reset of the XPM_FIFO_ASYNC, if you keep rst = '0' at the beginning of the simulation.

 

power_on_reset.png

 

-> after I discovered this, I generated my actual 'rst' pulse only after 1000ns. I was not expecting such 'automatic' reset, could someone clarify why this happens? 

 

in the following 2 items, I generate a 'manual' reset of 1 wr_clk cycle in width, 1000ns after simulation started. This 'single cycle rst' is sufficient for the XPM_FIFO macro, see here.

 

2) reset behaviour when wr_clk is faster than rd_clk

 

wr_clk = 200Mhz, rd_clk = 20MHz

wr_clk_faster.png

some observations

  • wr_rst_busy = 96 cycles = 480ns
  • rd_rst_busy = 5 cycles = 250ns
  • also, rd_rst_buys seems to 'kick in' only on the 2nd rd_clk edge after wr_rst_busy goes high

3) reset behaviour when wr_clk is slower than rd_clk

 

wr_clk = 20Mhz, rd_clk = 200MHz

wr_clk_slower.png

some observations :

* wr_rst_busy = 6 cycles = 300ns

* rd_rst_busy = 40 cycles = 200ns

  • also, rd_rst_buys seems to 'kick in' only on the 2nd rd_clk edge after wr_rst_busy goes high

Now I know it's important to keep wr_en and rd_en at '0' during reset. 

 

Q2 : I dont' see much 'logic' in the duration fo the rd_rst_busy cycles, I hould probably not wonder too much (And rely on the solution that I think I need, see Q3), but if someone could shed a light on this, that would be great.

 

I use the fifo to CDC between 2 clock domains. ADC sits on the wr_clk domain, soft-core cpu sits on the rd_clk domain. In my case, rd_clk is 8 times faster than wr_clk. I also add a 'software' clear of the fifo, controlled by a soft core processor.

 

Now the soft-core needs to know when the soft-reset of the fifo has completed. I can of course just 'wait long enough', but I'd prefer to have a status bit in a register that says 'rst busy', which the soft-core can poll.

 

Q3 : how should I create such 'reset busy' flag that covers both the wr_rst_busy and rd_rst_busy ? put a CDC on the wr_rst_busy, and then logic-or this with the rd_rst_busy signal? 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
4 Replies
Scholar austin
Scholar
1,095 Views
Registered: ‎02-27-2008

Re: XPM_FIFO_ASYNC reset behaviour

I am always concerned with simulation of some built-in blocks,

 

They may not model all behavior exactly.

 

Look in:

 

https://www.xilinx.com/search/site-keyword-search.html?searchKeywords=xpm%20fifo%20async

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Scholar ronnywebers
Scholar
1,085 Views
Registered: ‎10-10-2014

Re: XPM_FIFO_ASYNC reset behaviour

@austin I checked the forum for XPM_FIFO_ASYNC, but didn't find much. 

 

If I can't really rely on the sim behaviour, what would be another solution? Use a bitstream + ILA to see what's really happening? 

 

I was actually working on a 'reset_done' signal  for use in the rd_clk domain, that covers both the wr_rst_done and rd_rst_done signal. Guess I better make a small FSM that checks both (and properly CDC  the wr_rst_done singal to the rd_clk domain). That would be a usefull extension to the XPM_FIFO_ASYNC macro I think : a reset_done signal for each clock domain.

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Scholar austin
Scholar
1,081 Views
Registered: ‎02-27-2008

Re: XPM_FIFO_ASYNC reset behaviour

Yes,

 

ILA plus your code looks like the only real way to get that behavior (other than the designer reading this and telling us whet they think they implemented ... on second thought, I like ILA better!).

 

It is a stated goal for all hardened IP in our devices that simulation models all be vetted, and accurate.  Some, like ICAP, remain intractable as their complexity is that of the entire device.

 

Definitely a work in progress to chip away at.

Austin Lesea
Principal Engineer
Xilinx San Jose
Scholar ronnywebers
Scholar
1,055 Views
Registered: ‎10-10-2014

Re: XPM_FIFO_ASYNC reset behaviour

thanks @austin, I'll definitely check that reset behaviour with the ILA as soon as my IP gets packaged and built into an application. I'll post the results here.

 

I found the SystemVerilog source file of the XPM_ASYNC_FIFO macro (xpm_fifo.sv) in the Vivado install directory. I'm a VHDL programmer, so I might be incorrectly reading the SystemVerilog code, but it looks like the wr_rst_busy waits until rd_rst_busy completes, so wr_rst_busy is always the last signal to deassert. Also, my simulation shows the same behaviour (checked this with different freq ratios)

 

Q: if I want a rst_done signal in my rd_clk domain, I guess I just need to cdc this wr_rst_done signal to the rd_clk domain (?)

I should probably use XPM_CDC_SINGLE for this?

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos