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!

Reply
Visitor
Posts: 14
Registered: ‎10-22-2014
Accepted Solution

MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

Hi there:

 

I am posting this after trying to find some help on the Internet without success.

 

So, I made a synchronizer with two D FlipFlops in series. According to what I read, the greater the Slack (The sooner the signal makes it from the first Flip Flop output to the next FlipFlop input) the better, because Mean Time Between Failure will be higher.

Ok, in order to calculate how small Slack should be I want to calculate the MTBF and in order to do that I need some constants that depend on the FPGA manufacture process. I am not able to find these constants neither on the Internet nor in the documentation.

 

I want to apply this equation => MTBF= (exp(slack/C_2)) / (C_1 f_CLK f_data)

 

I found many posts on the Internet talking about the "Astronomical low" chance of failure with this approach (two FlipFlops in series) but I want to calculate the constraints I have to include in my *.ucf file so I can be sure this issue is sorted out.

Where can I find this information?

 

Thanks a lot


Fran


Accepted Solutions
Highlighted
Historian
Posts: 4,540
Registered: ‎01-23-2009

Re: MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

You don't tell us if you are using ISE or Vivado.

 

In Vivado, Xilinx is taking a much more serious approach to clock synchronizers and metastability. We are seeing a larger number of tools to help us in this area.

 

The first thing is that all the flip-flops in your metastability resolution chain (whether it be 2, 3, or more), should (really must) have the ASYNC_REG property set on them. This can be done via Tcl commands

 

set_property ASYNC_REG TRUE [get_cells <names_of_ffs>]

 

or can be done in your RTL code. You can read more about how to infer it (and more details on the property) in the Properties Reference Guide (UG912 v2104.3 p. 105).

 

This property does a LOT of things

  - it prevents the FF output from going "unknown" when its setup/hold time is violated during back-annotated simulations

  - it applies a DONT_TOUCH to the cells, preventing any optimization from merging/replicating/moving them

  - it prevents them from being placed in an SRL or pulled into another block (DSP, block RAM)

  - it forces the placer to keep the FFs in the chain (with the attribute) "as close together as possible" - generally within the same slice

    - this reduces the routing, and hence increases the amount of time you get for metastability resolution

 

In order to help you make sure you have your synchronizers right, Vivado has a number of commands to help you visualize your cross-clock paths. The command "report_clock_interaction" lets you see all combinations of clocks, and the constraints that apply to them. Vivado 2014.3 has a new command "report_cdc", which looks at all paths between clock domains and sees if it can recognize the clock crossing circuit between them - it even reports if they have the ASYNC_REG property set.

 

For UltraScale (only) the tools also have a "report_synchronizer_mtbf" command. This is exactly what you are asking for - a command that can show you the MTBF of your design based on the synchronizers. It understands the FFs characteristics, can analyze the timing slack, knows the clock frequencies and has a mechanism for the designer to set switching activity on the inputs - all the information required to calculate the MTBF. Unfortunately, this is currently supported only for UltraScale (I don't know if we will see it for the 7 series or not).

 

Finally, in UltraScale there is a dedicated synchronizer flip-flop. You can still use back-to-back regular FFs, but there are a certain number of specialized FFs called HARD_SYNC in the block RAM column. These can be used to improve MTBF (but have the disadvantage of being "far away" from other logic).

 

Avrum

View solution in original post


All Replies
Instructor
Posts: 9,052
Registered: ‎08-14-2007

Re: MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

Visitor
Posts: 14
Registered: ‎10-22-2014

Re: MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

Hi Gabor,

 

Thanks a lot for you useful help.

 

So, Austin Lesea states in this thread:

 

"The recommendation is to use three DFF, and make sure the routing between them is short (small delay) as the faster the path, the better the synchronizer."

 

This is exactly my point, I want to know how short is good enough for my application. I mean, how small is "small" to be sure you are not going to have issues with metastability between two clock domains? For instance, in terms of CLK periods, 1/5 of a Period should be ok?

 

I would love to have a figure for MTBF so I can say "Ok, so in order to have a particular failure rate I have to ensure less than this delay between my DFFs in my synchronizer".

 

Thanks again!

 

Fran

Instructor
Posts: 9,052
Registered: ‎08-14-2007

Re: MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

It's not so much a portion of the clock period as the actual slack in nanoseconds.  i.e. the probability of a metastable event living longer than a certain amount of time does not depend on how often you clock the flops.  It's a fast decaying number that just depends on the time to live of the event.  So if you find that for example 1 ns is enough to get the probability down to an acceptable MTBF, then you need to allow for 1 ns slack in the path between flops.  If the clock period is 4 ns, then this is 25%.  If the clock period is 2 ns this is 50%.  In general you'd like to make the slack as much as possible, and this is easiest if you RLOC the flops to be in the same slice.  If your clock is really slow like 20 ns period, then you shouldn't need to worry about 3 flops in a row.

 

Another point is that the fabric flops are much better than SRL flops, so you need to turn off shift-register inference for these paths, either using a synthesis directive or by adding an asynch reset to prevent the possibility of using SRL.

-- Gabor
Highlighted
Historian
Posts: 4,540
Registered: ‎01-23-2009

Re: MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

You don't tell us if you are using ISE or Vivado.

 

In Vivado, Xilinx is taking a much more serious approach to clock synchronizers and metastability. We are seeing a larger number of tools to help us in this area.

 

The first thing is that all the flip-flops in your metastability resolution chain (whether it be 2, 3, or more), should (really must) have the ASYNC_REG property set on them. This can be done via Tcl commands

 

set_property ASYNC_REG TRUE [get_cells <names_of_ffs>]

 

or can be done in your RTL code. You can read more about how to infer it (and more details on the property) in the Properties Reference Guide (UG912 v2104.3 p. 105).

 

This property does a LOT of things

  - it prevents the FF output from going "unknown" when its setup/hold time is violated during back-annotated simulations

  - it applies a DONT_TOUCH to the cells, preventing any optimization from merging/replicating/moving them

  - it prevents them from being placed in an SRL or pulled into another block (DSP, block RAM)

  - it forces the placer to keep the FFs in the chain (with the attribute) "as close together as possible" - generally within the same slice

    - this reduces the routing, and hence increases the amount of time you get for metastability resolution

 

In order to help you make sure you have your synchronizers right, Vivado has a number of commands to help you visualize your cross-clock paths. The command "report_clock_interaction" lets you see all combinations of clocks, and the constraints that apply to them. Vivado 2014.3 has a new command "report_cdc", which looks at all paths between clock domains and sees if it can recognize the clock crossing circuit between them - it even reports if they have the ASYNC_REG property set.

 

For UltraScale (only) the tools also have a "report_synchronizer_mtbf" command. This is exactly what you are asking for - a command that can show you the MTBF of your design based on the synchronizers. It understands the FFs characteristics, can analyze the timing slack, knows the clock frequencies and has a mechanism for the designer to set switching activity on the inputs - all the information required to calculate the MTBF. Unfortunately, this is currently supported only for UltraScale (I don't know if we will see it for the 7 series or not).

 

Finally, in UltraScale there is a dedicated synchronizer flip-flop. You can still use back-to-back regular FFs, but there are a certain number of specialized FFs called HARD_SYNC in the block RAM column. These can be used to improve MTBF (but have the disadvantage of being "far away" from other logic).

 

Avrum

Visitor
Posts: 14
Registered: ‎10-22-2014

Re: MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

Hi Avrum,

 

I am using ISE not Vivado but after reading your suggested manual I decided to add it to my synchronizer. Thanks a lot.

 

Too bad I was not able to find those factor to use the MTBF equation but at least I can be sure those register will behave properly due to all these features ASYNC_REG provides.

 

Thanks a lot!

 

Fran

 

Historian
Posts: 4,540
Registered: ‎01-23-2009

Re: MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

Fran,

 

Just a word of warning. The ASYNC_REG attribute does exist in ISE, but it only does the first of the things I listed in my earlier posting - prevents the flip-flop from going X when its setup/hold is violated in timing simulations.

 

All the other wonderful things the ASYNC_REG property does only applies to Vivado.

 

In ISE, the only way to constrain your metastability flip-flops is with a MAXDELAY constraint. This, too, can be put in your RTL code on the net between the first and second stage.

 

  (* MAXDELAY = "2ns" *)  reg [WIDTH-1:0] signal_meta;

 

This will constrain the delay on the net between the two FFs to 2ns, which will allow one clock period minus 2ns for metastability resolution.

 

Avrum

Visitor
Posts: 14
Registered: ‎10-22-2014

Re: MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

Oh...

The more I hear about Vivado the more I like it.

 

I realized something was not going well after adding this statement. It synthesized the first Flip-Flop in the synchronizer chain as a single register instead of 16 separated registers. 

 

So, I end up at the same point: I don't know what is the proper value for the net delay so I can end up having a particular MTBF value. Ok, I will try again using schreg statement and  asking XST for a ridiculous delay value so I can assume no issue will happen.

 

Thanks a lot guys.

 

Best regards

Fran

MTBF equation factors for Metastability synchronizers slack calculations in a Virtex7

Accepted Solution Solved