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