cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Explorer
Explorer
4,292 Views
Registered: ‎07-10-2013

Built-in FIFO Reset

Jump to solution

UG573 (v2017.4) has the following reset-related warning paragraph at the top of p.53:

 

"IMPORTANT: Both the block RAM and FIFO require clean, free running clocks. The FIFO cannot be recovered if it is in reset while an unstable clock is applied. If any of the FIFO clocks become unstable, it is recommended to...only reset the FIFO after a stable clock has returned..." [emphasis added]

 

a) What was intended to be meant by the obscure wording that "the FIFO cannot be recovered"?  What does this mean?

 

b) It would seem that there is some ambiguity in the paragraph regarding asserting the FIFO reset input, versus performing a reset sequence (i.e., asserting the reset input and later then deasserting it, to complete the resetting procedure).

 

It would be rather off-the-wall if random assertion of the reset input could result in the FIFO being bent out of shape forever afterwards, with a subsequent reset sequence not able to effect correct resetting, which is what the "The FIFO cannot..." sentence seems to imply.

 

It is reasonable to suppose that if a reset sequence is attempted, involving clean assertion of the reset input followed later by clean deassertion of the reset input, that if the clock(s) are not nice anytime from the time reset is asserted until when reset is later deasserted (and afterwards), that the FIFO might well be unhappy.

 

It is also reasonable to suppose, no matter what behavior the clocks or reset had previously had, if a reset sequence is again attempted once the clocks are stable and expected to remain so, that following that final reset sequence the FIFO should then be (and remain) properly functional.

 

c) Based on the above, the paragraph should perhaps be rewritten along the following lines:

 

"IMPORTANT: Both the block RAM and FIFO require clean, free running clocks. Proper functioning of the FIFO will not result if it is being reset while an unstable clock is applied. If any of the FIFO clocks become unstable, it is recommended to... reset the FIFO once again after a stable clock has returned..."

 

Please comment; thanks!

 

 

Tags (1)
0 Kudos
Reply
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
5,095 Views
Registered: ‎06-12-2008

The UG573 important statement is accurate. The FIFO can get into an unrecoverable state (i.e. does not work again until after a power-cycle) if there is an unstable (has glitches or is outside of operating range) clock input while reset asserted. 

View solution in original post

6 Replies
Teacher
Teacher
4,276 Views
Registered: ‎07-09-2009

What do you know about FIFO's ?

 

there are two types, Asynchronous, which used to be the common type, and synchronous, which are now the normal.

 

Asynchronous were very very resilient to their 'clocks', used to call the write and read clock.

 

But the MUCH bigger ones now, are synchronous, and are effectively state machines, all be it one for the read and one for the write.

 

As all state machines, they really need constant and good clock,

     

which us older ones can forget , as we were used to asynchronous.

 

so this is effectively a big warning to remember that in the simple case, clocks must always be present to the fifo.

 

If you meet that , then all is easy ,

 

You 'CAN' gate the clocks to the FIFO's, BUT, that needs lots of in depth study of the data sheets.

 

You could also feed the FIFO's with a wobbly clock, say from an external PLL, that is trying to lock.  Its going to be all over the place.

  

Again the note is saying , these need a good clock ,

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Reply
Xilinx Employee
Xilinx Employee
5,096 Views
Registered: ‎06-12-2008

The UG573 important statement is accurate. The FIFO can get into an unrecoverable state (i.e. does not work again until after a power-cycle) if there is an unstable (has glitches or is outside of operating range) clock input while reset asserted. 

View solution in original post

Adventurer
Adventurer
4,010 Views
Registered: ‎03-15-2012

This seems very dangerous to me, since the designs mostly perform a startup reset sequence and hold everything in reset until at least the clock is stable (eg. PLL locked). Do i understand it correct: In this situation a build-in fifo can get lost and is not recoverable via a proper reset sequence afterwards without POR?

Xilinx Employee
Xilinx Employee
3,993 Views
Registered: ‎10-11-2007

The user guide points out that an unstable clock during reset may set the hard FIFO into a non-recoverable state that would require reprogramming of the part. The typical use case for this is when a cable is removed that connects to GTs (say HDMI, DISPLAY PORT or so). The GT's CDR will loose alignment and the user clock  driving the hard FIFO is therefore unstable (the GT PLL at the end of the day). If a reset is issued during this time the FIFO may randomly lock up or not. This is not related to metastabilty but very similar in it's symptoms . The cable may be pulled 100s or 1000s of time without issues, but randomly the problem will eventually occur randomly. There is no formular by which this can be predicted. The solution is to a) stop the clock once the CDR losses alignment or b)  do not issue a reset until the GT has re-locked after the cable was re-inserted. The GTs do require a reset anyway.

3,345 Views
Registered: ‎03-24-2011

Does anyone have information about what a fifo "lock up" looks like? I have a situation where once in a very long time it appears a fifo DBITERR pin is stuck high and will not return low until the FPGA is reprogrammed. Since this happens so infrequently, I do not know if the rest of the fifo is operational or not at that point.

0 Kudos
Reply
413 Views
Registered: ‎08-15-2016

I have seen what I believe to be exactly this issue, and just like mentioned above it is because the write side of the FIFO is clocked by the GT recovered clock.

They symptoms that I see are that WR_RST_BUSY and RD_RST_BUSY FIFO signals get stuck at '1', and any attempted write or read results in an error (as per the data sheet).

We are using a Zynq Ultrascale+, a software reset and reload of the FPGA seems to clear the problem.