Forum Discussion

BillP_'s avatar
BillP_
Icon for New Contributor rankNew Contributor
2 years ago
Solved

Calculate MTBF for asynchronous inputs

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 devi...
  • BillP_'s avatar
    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_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).