I have a message from Quartus that it found synchronizer chains, but is unable to perform MTBF analysis on them. Yet, nothing is really explained in the manuals except how to recognize synchronizers so the tool does not optimize or retime them.
So far, all I/O have used set_false_path.
My best guess is,
From this, the tool can deduce a meta-stable probability and then deduce from the length of the chain what the compound probability is.
Info (332114): Report Metastability: Found 12 synchronizer chains.
Info (332114): The design MTBF is not calculated because there are no specified synchronizers in the design.
Info (332114): Number of Synchronizer Chains Found: 12
Info (332114): Shortest Synchronizer Chain: 2 Registers
Info (332114): Fraction of Chains for which MTBFs Could Not be Calculated: 1.000
Info (332114): Worst Case Available Settling Time: 8.863 ns
Is the SDC file with set_input_delay and virtual clocks the way to do this? The message there are no specified synchronizers in the design doesn't tell you how to specify the synchronizer and I don't understand how it could calculate the MTBF unless it knows the frequency of time that the signal might be transitioning.
I have looked in the manual and the cook book. The cook book seems like it describes real synchronous I/O and not a synchronizer for an asynchronous input. In my particular instance, I have a quadrature encoded phase A/B where I could sample them as they are changing. I want to make sure the chains are sufficiently sized for the rise fall of the signal. I also know the minimum time between transitions (determined by a maximum speed), which I believe is the virtual clock period.
The report can be found in Timing analyzer under 'Report Metastability' near the bottom of the 'tasks' box/work panel.
Some of these are indeed false synchronizers and they are disabled with,
set_instance_assignment -name SYNCHRONIZER_IDENTIFICATION OFF -to register_name
The 'register_name' is listed under the 'Synchronization Node' in the 'Report Metastability' output.
My best guess is,
I find the rise/fall time of an input.
I create virtual clock that indicates the frequency of the input toggle.
This confounds slew with MTBF and metastability. The metastability is the time that the register needs to settle to a value. The value maybe 'wrong'. However, it is not changing while the clock is not active. When a register/flip-flop is meta-stable, outputs referencing it may have different values resulting is unintended results due to logic optimizations.
Slew should be handled like a debounce circuit (slightly different than a synchronizer). The slew rate through a forbidden range of the I/O gives a length of the debounce to prevent false transitions.
For example, 3.3-V LVTTL has the following voltage ranges,
The time to transition from these voltages can be calculated in clocks and a packed register created to debounce this area.
localparam DEBOUNCE_SIZE = 6;
reg [DEBOUNCE_SIZE-1:0] signal_debounce = DEBOUNCE_SIZE{1'b0}};
always @(posedge clock, negedge reset_n)
if(!reset_n) begin
signal_debounce <= {DEBOUNCE_SIZE{1'b0}};
end
else begin
signal_debounce <= {signal, signal_debounce[DEBOUNCE_SIZE-1:1]};
// - `&signal_debounce` - all high
// - `!(|signal_debounce)` - all low
// - |signal_debounce - at least one is high
end
Signal is collected in the verilog packed array for several clocks. The reduction operator can be used to test that all values are high or low. This will filter values from the transitioning region used by a quadrature encoder or other related asynchronous inputs to prevent false triggers due to slew.
The above code is identical to a synchronizer chain, but all bits of the packed register are used, as opposed to just the 'low bit'. Ie, if t0 is now, then signal_debounce[0] refers to t-6. This delay is a waste in normal logic, but is needed for a synchronizer. If all taps (different signal times) are used, then the logic will never be optimized away. So, the tool doesn't care about that case, but a developer should.
Information can be found in Chapter 3 or the 'Quartus Design Recommendations'. Read the PDF and not google results from the web pages. The PDF has an ordering that is not apparent in the web pages. One mechanism is to specify a SYNCHRONIZER_TOOGLE_RATE to a register/flop-flop.
If I have the following,
set_instance_assignment -name SYNCHRONIZER_IDENTIFICATION FORCED -to register_name
set_instance_assignment -name SYNCHRONIZER_TOGGLE_RATE 32000 -to register_name
The report gives 1 billion years MTBF for a Cyclone V clocked at 100MHz.
The report is the same event Changing
SYNCHRONIZER_TOGGLE_RATEFAST_INPUT_REGISTER ON.INPUT_TRANSITION_TIME.I think that the metastability is only for clock domain crossing (or synchronous I/O) or the lithography is so small that the Cyclone V has next to no change to go meta-stable when clocked at 100MHz.
The paper Understanding Metastability in FPGAs seems to suggest that some flip-flops have better metastability constants than others and this is controlled by process, etc. It would seem reasonable that the I/O cell flip-flops would have the best properties. However, I don't have documentation on this and can not get the timing tools to indicate any difference. It maybe true with prior Altera/Intel logic elements, but is not true with more modern designs.
Also, the Intel staff said that having a reset value to the register would negate synchronizers, but this was not my experience. Again, this might depend on RTL mapping.