Calculate MTBF for asynchronous inputs

[BillP_]

I have a quadrature decoder with phase A/B that is basically a gray scale of either increment or decrement.  Given a maximum motions and the encoder size, frequency of A/B signals is 32kHz.

The device is currently a Terasic Cyclone V board.

These stanza work to get a metastability report.

[qsf]

set_location_assignment PIN_W21 -to POSITIVE_ENCODER_SIGNAL_A
set_location_assignment PIN_Y24 -to POSITIVE_ENCODER_SIGNAL_B
set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to POSITIVE_ENCODER_SIGNAL_A
set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to POSITIVE_ENCODER_SIGNAL_B
set_instance_assignment -name CURRENT_STRENGTH_NEW 16MA -to POSITIVE_ENCODER_SIGNAL_A
set_instance_assignment -name CURRENT_STRENGTH_NEW 16MA -to POSITIVE_ENCODER_SIGNAL_B
#set_instance_assignment -name FAST_INPUT_REGISTER ON -to POSITIVE_ENCODER_SIGNAL_A
#set_instance_assignment -name FAST_INPUT_REGISTER ON -to POSITIVE_ENCODER_SIGNAL_B
set_instance_assignment -name SYNCHRONIZER_IDENTIFICATION FORCED_IF_ASYNCHRONOUS -to rENCODER_A
set_instance_assignment -name SYNCHRONIZER_IDENTIFICATION FORCED_IF_ASYNCHRONOUS -to rENCODER_B
set_instance_assignment -name SYNCHRONIZER_TOGGLE_RATE 32000 -to rENCODER_A
set_instance_assignment -name SYNCHRONIZER_TOGGLE_RATE 32000 -to rENCODER_B

[sdc]

set_false_path -from [get_ports {POSITIVE_ENCODER_SIGNAL*}]

This give an MTBF report of 1 billion years, yet if I change the sample rate or use the I/O cell packed register, the MTBF values do not change.  My first guess to us a virtual clock and specify input delays for slew of the signals.  I can guess the 'metastable' window from the slew and the rate.  But the tools starts to put in extra I/O delays and doesn't meet timing specs.  Also, it warns about an ignored SYCHRONIZER_TOGGLE_RATE.

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.

Also, from reading, it would seem that the I/O cell flip-flop/register would have better metastable constants (quicker decay) to increase MTBF.  Also, for the quadrature encoder, both values should not go metastable at the same time, but i do emit errors if illegal transitions are encountered.  I could add filters as well, but wonder if I am misplaced in believing,

1. Quartus/Timing Analyzer can not do MTBF analysis on asynchronous inputs.

2. The I/O cell registers are better (and how much) for decreasing MTBF.

I am using Quartus Prime Lite 21.1 currently.

[BillP_]

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.

[BillP_]

---

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 available in the GUI.  You have to click different tabs to see it.

[RichardTanSY_Intel]

--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

[BillP_]

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?

[RichardTanSY_Intel]

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

[BillP_ · Accepted solution]

It is correct that I had a reset line to the registers.  I removed it, but is still ignores the synchronizer.

I think I found an issue.

This SDC results in the ignored SYNCHRONIZER_TOGGLE_RATE.

The 'INPUT_TRANSITION_TIME' is a mechanism to indicate slew.

[SDC]

# A 32Khz virtual clock for maximum speed.
# Clocks are 180 degrees out of phase, but can not express.
create_clock -period 31250ns -name io_virt_encoderA_clk
create_clock -period 31250ns -name io_virt_encoderB_clk

set_input_delay -clock io_virt_encoderA_clk 1.5 [get_ports {POSITIVE_ENCODER_SIGNAL_A}]
set_input_delay -clock io_virt_encoderB_clk 1.5 [get_ports {POSITIVE_ENCODER_SIGNAL_B}]

[/SDC]

This SDC will give what seems to be large MTBF reports.  Ie, the synchronizer register is not ignored and some sort of analysis is performed.

[SDC]

set_false_path -from [get_ports {POSITIVE_ENCODER_SIGNAL*}]

[/SDC]

So, the SDC seems to affect whether the input is treated as asynchronous or not.  I guess, as I have added a virtual clock, the tool thinks the input is no longer ASYNCHRONOUS.  The correct method is,

set_instance_assignment -name SYNCHRONIZER_IDENTIFICATION FORCED -to register_name

set_instance_assignment -name SYNCHRONIZER_TOGGLE_RATE 32000 -to register_name

Where 'register_name' is the synchronizer?  I was using the virtual clock as it seems the only way to specify a slew of the signal.  Faster inputs versus the duty cycle will give a lower probability of a meta-stable input when the synchronizer is clocked.  So, I believe the slew rate of an input is ignored in the MTBF calculation.

Help on 'Synchronization Register Chain Length'

> Synchronization chains are sequences of registers with the same clock, no fanout in between, such that the first register is fed by a pin, or by logic in another clock domain.

And not reset.  But a virtual clock is not the same 'with the same clock'.  So, the option 'SYNCHRONIZER_IDENTIFICATION FORCED_IF_ASYNCHRONOUS ' is also wrong.  It needs to be 'SYNCHRONIZER_IDENTIFICATION FORCED' as a virtual clock makes it synchronous (to quartus).  This is the reason for the SDC behaviour above.  Now, I have the same 1 Billion year MTBF analysis in both cases.

The answer is in this page,

https://www.intel.com/content/www/us/en/docs/programmable/683082/21-3/force-the-identification-of-synchronization.html

It is just difficult to understand what it is saying as there are various options (QSF and GUI) which influence the behaviour.  So the stanza SYNCHRONIZER_IDENTIFICATION accepts things that the fitter option 'Synchronizer Identification'  accept (and vice-versa?), but it is really only sensible to apply 'FORCED|OFF' for a specific register, to counteract (or supplement) the 'Synchronizer Identification' GUI option.

Unfortunately, no matter what I try, an input synchronizer always says the MBTF is 1 billion years no matter what slew is used (or size of the chain, even with a single register).  So perhaps the Cyclone V at 100MHz is quick to leave metastable no matter what.

A final reason for ignored synchronizer is if the output of the register is unused (the fitter reports it as a ignored assignment as reported elsewhere).

[RichardTanSY_Intel]

'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