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