Calculate MTBF for asynchronous inputs

Incidentally, if I run the TCL command line,

quartus_sta.exe -s

tcl> project_open xxx

tcl> create_timing_netlist

tcl> report_metastability -nchains 0 -panel_name {Report Metastability} -multi_corner

I get messages like,

Info (332114): Worst-Case MTBF values are calculated based on the worst-case silicon characteristics, with worst-case operating conditions.
Info (332114): - Under worst-case conditions, an increase of 100ps in available settling time will increase MTBF values by a factor of 7.8

This information is not displayed in the GUI afair. I think the above info is incorrect as the MTBF is 9billion years no matter what I do.

Also, I retried with a virtual clock at 32kHz for the input, but it then still says the 'SYNCHRONIZER_TOGGLE_RATE' is invalid for the register. Although I do not have timing closure issues any more. Also, the 'invalid fitter assignment' for the 'SYNCHRONIZER_TOGGLE_RATE' reappears and the Timing analysis GUI says there are no MTBF analysis.

--start--

My goal is determine the number of synchronizers and have details to provide hardware designers to add schmitt triggers or other external element condition signals for the FPGA.

--end--

>> Do you want to get the list of synchronizers in the design? You can apply synchronizer identification settings

(Auto/Forced if Asynchronous) globally to automatically list all possible synchronizers. This can set with the Synchronizer identification option on the Timing Analyzer page in the Settings dialog box.

--start--

It warns about an ignored SYCHRONIZER_TOGGLE_RATE.... it then still says the 'SYNCHRONIZER_TOGGLE_RATE' is invalid for the register.

--end--

>> Could you provide the details of the warning message or a screenshot? Do you see any message or report from Quartus that might indicate why it is ignored? In the Synchronizer Summary Report, are both rENCODER_A and rENCODER_B, identified as synchronization register?

--start--

This information is not displayed in the GUI afair. I think the above info is incorrect as the MTBF is 9billion years no matter what I do.

--end--

>> I'm not sure if I understand correctly. Do you think that the report from the GUI and Tcl is different, and this might be a potential bug?

Best Regards,

Richard Tan

Hi Richard.

Thanks so much for responding. Just a general question first (was at the end of my first post).

Does quartus support MBTF for asynchronous inputs pins? Or you aren't really sure.

Now I will try to answer your questions.

-----

Could you provide the details of the warning message or a screenshot? Do you see any message or report from Quartus that might indicate why it is ignored? In the Synchronizer Summary Report, are both rENCODER_A and rENCODER_B, identified as synchronization register?

I have 'ignored' some and forced some synchronizers.

The register has the motor vendor name, which I blurred. It is just a verilog register. I try to pack the register or not into the I/O cell.

Report Metastability then give 'No synchronizer chains to report.'

[from project.fit.rpt excerpts]
+----------------------------------------------------------------------------------------------------------------+
; Ignored Assignments ;
+--------------------------+-----------------+--------------+-------------------+---------------+----------------+
; Name ; Ignored Entity ; Ignored From ; Ignored To ; Ignored Value ; Ignored Source ;
+--------------------------+-----------------+--------------+-------------------+---------------+----------------+
; Synchronizer Toggle Rate ; stroma_fpga_poc ; ; rXXXXXX_ENCODER_A ; 32000 ; QSF Assignment ;
; Synchronizer Toggle Rate ; stroma_fpga_poc ; ; rXXXXXX_ENCODER_B ; 32000 ; QSF Assignment ;
+--------------------------+-----------------+--------------+-------------------+---------------+----------------+

Name ; Pin # ; I/O Bank ; X coordinate ; Y coordinate ; Z coordinate ; Combinational Fan-Out ; Registered Fan-Out ; Global ; Input Register ; PCI I/O Enabled ; Bus Hold ; Weak Pull Up ; I/O Standard ; Termination ; Termination Control Block ; Location assigned by ; Slew Rate ;
; POSITIVE_ENCODER_SIGNAL_A ; W21 ; 5A ; 68 ; 11 ; 20 ; 1 ; 0 ; no ; no ; no ; no ; Off ; 3.3-V LVTTL ; Off ; -- ; User ; no ;
; POSITIVE_ENCODER_SIGNAL_B ; Y24 ; 5A ; 68 ; 13 ; 54 ; 1 ; 0 ; no ; no ; no ; no ; Off ; 3.3-V LVTTL ; Off ; -- ; User ; no ;

; Location ; Pad Number ; I/O Bank ; Pin Name/Usage ; Dir. ; I/O Standard ; Voltage ; I/O Type ; User Assignment ; Bus Hold ; Weak Pull Up ;

; W21 ; 173 ; 5A ; POSITIVE_ENCODER_SIGNAL_A ; input ; 3.3-V LVTTL ; ; Row I/O ; Y ; no ; Off ;

; Y24 ; 180 ; 5A ; POSITIVE_ENCODER_SIGNAL_B ; input ; 3.3-V LVTTL ; ; Row I/O ; Y ; no ; Off ;

+------------------------------------------------------------------------------------------------------------------------------------------+
; Delay Chain Summary ;
+---------------------------+----------+----+------+------+----+------+-------+--------+------------------------+--------------------------+
; Name ; Pin Type ; D1 ; D3_0 ; D3_1 ; D4 ; D5 ; D5 OE ; D5 OCT ; T11 (Postamble Gating) ; T11 (Postamble Ungating) ;
+---------------------------+----------+----+------+------+----+------+-------+--------+------------------------+--------------------------+
;
; POSITIVE_ENCODER_SIGNAL_B ; Input ; -- ; -- ; (3) ; -- ; -- ; -- ; -- ; -- ; -- ;
; POSITIVE_ENCODER_SIGNAL_A ; Input ; -- ; -- ; (4) ; -- ; -- ; -- ; -- ; -- ; -- ;

+--------------------------------------------------------------------------------------------------------------------------+
; Pad To Core Delay Chain Fanout ;
+--------------------------------------------------------------------------------------------+-------------------+---------+
; Source Pin / Fanout ; Pad To Core Index ; Setting ;
+--------------------------------------------------------------------------------------------+-------------------+---------+
;
; POSITIVE_ENCODER_SIGNAL_B ; ; ;
; - rXXXXXX_ENCODER_B~feeder ; 1 ; 3 ;
; POSITIVE_ENCODER_SIGNAL_A ; ; ;
; - rXXXXXX_ENCODER_A~feeder ; 1 ; 4 ;

; Pin/Rules ; IO_000001 ; IO_000002 ; IO_000003 ; IO_000004 ; IO_000005 ; IO_000006 ; IO_000007 ; IO_000008 ; IO_000009 ; IO_000010 ; IO_000011 ; IO_000012 ; IO_000013 ; IO_000014 ; IO_000015 ; IO_000018 ; IO_000019 ; IO_000020 ; IO_000021 ; IO_000022 ; IO_000023 ; IO_000024 ; IO_000026 ; IO_000027 ; IO_000045 ; IO_000046 ; IO_000047 ; IO_000034 ;
; POSITIVE_ENCODER_SIGNAL_B ; Pass ; Inapplicable ; Pass ; Inapplicable ; Inapplicable ; Pass ; Pass ; Inapplicable ; Pass ; Pass ; Pass ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Pass ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ;
; POSITIVE_ENCODER_SIGNAL_A ; Pass ; Inapplicable ; Pass ; Inapplicable ; Inapplicable ; Pass ; Pass ; Inapplicable ; Pass ; Pass ; Pass ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Pass ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ; Inapplicable ;

; Source Register ; Destination Register ; Delay Added in ns ;
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+
; POSITIVE_ENCODER_SIGNAL_A ; rXXXXXX_ENCODER_A ; 4.673 ;
; POSITIVE_ENCODER_SIGNAL_B ; rXXXXXX_ENCODER_B ; 4.331 ;

-----

Do you want to get the list of synchronizers in the design? You can apply synchronizer identification settings

(Auto/Forced if Asynchronous) globally to automatically list all possible synchronizers. This can set with the Synchronizer identification option on the Timing Analyzer page in the Settings dialog box.

Well, I am actually using this option and it was not recognizing any real synchronizers as I understand it. We only have a single clock in our design to limit CDC issues. However, we have several asynchronous inputs and outputs. Due to a code change an output is multiplexed from different modules. The multiplexer involves a registers which feeds the output. These were recognized as synchronizers, when that was not the intent. Also, I don't really understand why you would want to synchronize an asynchronous outputs (UART Rx on opposite end). So, I have explicitly disabled synchronizers on async outputs.

However, the input that captures could possibly have metastable events (such as UART tx from the opposite (recieve on FPGA side)). Ie, the first flip-flop/register might have a clock exactly as the line is transitioning and the slow of this input could cause meta-stability. Perhaps there is some technology, etc. that I am unaware of in the I/O cells that prevents this. In the Altera paper,

https://cdrdv2-public.intel.com/650346/wp-01082-quartus-ii-metastability.pdf

'FPGA Architecture Enhancements' section talks about FPGA designs which have more meta-stable tolerant properties.

Also, Intel® Quartus® Prime Standard Edition User Guide
Design Recommendations

Has Chapter 3, "Managing Metastability with the Intel Quartus Prime Software" which seems to indicate that different cells (LAB, etc) may have different meta-stable properties and Quartus may be able to optimize for this. Finally, I made a jump of logic that perhaps the I/O blocks would be the best place to put optimal flip-flops and ' FAST_INPUT_REGISTER ON' causes packing of verilog synchronizing registers to the I/O block of the Cyclone V.

----

I'm not sure if I understand correctly. Do you think that the report from the GUI and Tcl is different, and this might be a potential bug?

---

Well, I am not sure it is a bug. Just information. If it is normally offered by the GUI, but not now, then it might be helpful information?

Does quartus support MBTF for asynchronous inputs pins?

>> No, as to enable the metastability MTBF analysis in Quartus tool, we will need to identify which registers are part of a synchronization register chain.

FYI, for Quartus software to identify a synchronization register chain, the registers in the chain must not include any resets.

set_instance_assignment -name SYNCHRONIZER_IDENTIFICATION FORCED_IF_ASYNCHRONOUS -to register_name

set_instance_assignment -name SYNCHRONIZER_TOGGLE_RATE 32000 -to register_name

Best Regards,

Richard Tan

'register_name' is the registers that part of the synchronizer chain.

I'm glad to hear that you were able to find a solution. Thank you for sharing; it was a great discussion. It's valuable to understand that the tool interprets the input as no longer asynchronous when using the virtual clock. Therefore, SYNCHRONIZER_IDENTIFICATION FORCED is the correct approach.

SYNCHRONIZER_IDENTIFICATION in the .qsf file is usually used for a specific synchronizer chain.

If, by GUI, you are referring to the SYNCHRONIZER_IDENTIFICATION setting in the Fitter Advanced Setting, it's important to note that this setting is applied globally to the entire design. So, if at any point, you notice there is a synchronizer chain not detected, you can use SYNCHRONIZER_IDENTIFICATION in the .qsf to instruct the tool to identify that particular synchronizer chain. The 'Forced' option should not be applied to the entire design, because doing so identifies all registers in the design as synchronizers.

Now, I will transition this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out.

Thank you and have a great day!

Best Regards,

Richard Tan

This is a technical question that requires analyzing asynchronous inputs in FPGA design, specifically using Intel's Quartus Prime tools and a Cyclone V FPGA. Here's a structured approach to the problem based on the details provided:

Key Points to Address:

1. Metastability Analysis in Quartus:

   • Quartus Timing Analyzer provides tools for analyzing metastability but has limitations when dealing with asynchronous inputs.
   • The SYNCHRONIZER_TOGGLE_RATE and SYNCHRONIZER_IDENTIFICATION assignments are meant to estimate MTBF. However, they require proper configuration and assumptions about toggle rates and the metastable window to be accurate.
   • Ignored SYNCHRONIZER_TOGGLE_RATE warnings typically mean the settings or paths are not correctly defined or applied.

2. Effectiveness of I/O Cell Flip-Flops:

   • Using I/O cell registers can indeed improve metastability MTBF due to their proximity to the input buffer and optimized physical characteristics for metastability resolution.
   • However, this improvement depends on the specific FPGA family and its hardware characteristics, which are typically outlined in the device datasheet.

3. Challenges with Input Delays:

   • Introducing virtual clocks and input delays to model slew rates is a valid approach but can lead to timing issues if the constraints aren't well-matched to the design's actual operation.
   • Extra I/O delays might indicate misaligned constraints or incorrect assumptions about the signal's arrival time.

4. Design Requirements:

   • Ensure that the quadrature encoder signals are synchronized with the FPGA's clock domain using proper synchronizer chains.
   • Illegal transitions due to metastability can be detected but should ideally be prevented by external signal conditioning (e.g., Schmitt triggers).

Recommendations:

1. Quartus and MTBF Analysis:

• SYNCHRONIZER_TOGGLE_RATE Warnings:

  • Double-check the paths for rENCODER_A and rENCODER_B. Ensure these are properly identified as asynchronous and connected to the designated synchronizers.
  • If warnings persist, manually calculate MTBF using Intel's guidelines and device-specific metastable constants.

• Virtual Clocks and Input Delays:

  • Define a virtual clock to model the asynchronous input signal's behavior without affecting internal timing paths.
  • Set realistic input delay constraints that account for signal slew, jitter, and arrival uncertainties.

2. Synchronizer Design:

• Implement a two or three-stage synchronizer chain for each signal (A and B) to minimize the probability of metastability propagating through the design.
• Use separate synchronizer chains for each input to account for independent metastability events.

3. I/O Cell Flip-Flops:

• Enable FAST_INPUT_REGISTER for the encoder signals to leverage the I/O cell's flip-flops.
• Refer to the Cyclone V device handbook for specific metastability constants of the I/O cell flip-flops and compare them with core flip-flops.

4. Signal Conditioning:

• Add external Schmitt triggers or filters to clean up the encoder signals before they reach the FPGA. This reduces noise and improves signal integrity.

5. Illegal Transition Handling:

• If an illegal transition is detected, implement a robust error-handling mechanism, such as resetting the state machine or issuing a warning signal.

Addressing Specific Questions:

1. Can Quartus/Timing Analyzer perform MTBF analysis for asynchronous inputs?

   • Partially. While it provides tools for metastability estimation (e.g., SYNCHRONIZER_TOGGLE_RATE), you may need to supplement it with manual calculations using Intel’s metastability constants and assumptions about the toggle rate and metastable window.

2. Are I/O cell registers better for reducing MTBF?

   • Yes, I/O cell flip-flops are generally optimized for handling metastability and have faster resolution times due to their proximity to input buffers. However, the improvement depends on the specific device and should be validated against datasheet parameters.

Next Steps:

1. Validate all SYNCHRONIZER_TOGGLE_RATE and SYNCHRONIZER_IDENTIFICATION assignments.
2. Check the Cyclone V datasheet for metastability parameters of I/O cell flip-flops and core flip-flops.
3. Refine timing constraints with accurate input delays and virtual clocks.
4. Consider external signal conditioning if MTBF remains insufficient after FPGA-level adjustments.

These steps should help resolve the metastability challenges and provide accurate data to hardware designers. Learn More