Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21147 Discussions

Calculate MTBF for asynchronous inputs

BillP_
Novice
1,720 Views

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.

Labels (1)
0 Kudos
1 Solution
BillP_
Novice
1,566 Views

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

View solution in original post

0 Kudos
10 Replies
BillP_
Novice
1,678 Views

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.

 

0 Kudos
BillP_
Novice
1,561 Views

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.

0 Kudos
RichardTanSY_Intel
1,622 Views

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


0 Kudos
BillP_
Novice
1,605 Views

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.

BillP__0-1700508018136.png

quartus-syncrhonizer.png

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?


0 Kudos
RichardTanSY_Intel
1,591 Views

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


0 Kudos
BillP_
Novice
1,567 Views

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

0 Kudos
RichardTanSY_Intel
1,522 Views

'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


0 Kudos
James113
Beginner
194 Views

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

0 Kudos
AlHill
Super User
165 Views

@James113   This thread is a year old, and your answer is a typical chatgpt answer, which is pretty lame.

 

Doc (not an Intel employee or contractor)
[Fear and the desire for control are primary motivators for shadow dwellers. ]

0 Kudos
BillP_
Novice
88 Views

https://stackoverflow.com/questions/77463250/analyzing-synchronizer-mtbf-in-quartus

The subsequent answer does look like GPT generated content.  The answer is that Quartus is not going to do MTBF for inputs (and metastability).  The slew rate is a different issue and you can add synchronizer chains, but it is not really for metastability.  The MTBF analysis is for clock domain crossing.  Also, some of the mentioned QSF values are used for power analysis (although they might double purpose for some of this analysis).


0 Kudos
Reply