Forum Discussion
Calculate MTBF for asynchronous inputs
- 2 years ago
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_clkset_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).
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:
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.
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.
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.
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:
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.
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:
- Validate all SYNCHRONIZER_TOGGLE_RATE and SYNCHRONIZER_IDENTIFICATION assignments.
- Check the Cyclone V datasheet for metastability parameters of I/O cell flip-flops and core flip-flops.
- Refine timing constraints with accurate input delays and virtual clocks.
- 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
@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. ]
- BillP_1 year ago
New Contributor
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).