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...
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
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,
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.
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).
Thanks so much for responding. Just a general question first (was at the end of my first post).
Does quartus support MBTF for asynchronous inputs pins? Or you aren't really sure.
Now I will try to answer your questions.
-----
Could you provide the details of the warning message or a screenshot? Do you see any message or report from Quartus that might indicate why it is ignored? In theSynchronizer Summary Report,areboth rENCODER_A and rENCODER_B, identified as synchronization register?
I have 'ignored' some and forced some synchronizers.
The register has the motor vendor name, which I blurred. It is just a verilog register. I try to pack the register or not into the I/O cell.
Report Metastability then give 'No synchronizer chains to report.'
Name ; Pin # ; I/O Bank ; X coordinate ; Y coordinate ; Z coordinate ; Combinational Fan-Out ; Registered Fan-Out ; Global ; Input Register ; PCI I/O Enabled ; Bus Hold ; Weak Pull Up ; I/O Standard ; Termination ; Termination Control Block ; Location assigned by ; Slew Rate ; ; POSITIVE_ENCODER_SIGNAL_A ; W21 ; 5A ; 68 ; 11 ; 20 ; 1 ; 0 ; no ; no ; no ; no ; Off ; 3.3-V LVTTL ; Off ; -- ; User ; no ; ; POSITIVE_ENCODER_SIGNAL_B ; Y24 ; 5A ; 68 ; 13 ; 54 ; 1 ; 0 ; no ; no ; no ; no ; Off ; 3.3-V LVTTL ; Off ; -- ; User ; no ;
; Location ; Pad Number ; I/O Bank ; Pin Name/Usage ; Dir. ; I/O Standard ; Voltage ; I/O Type ; User Assignment ; Bus Hold ; Weak Pull Up ;
; W21 ; 173 ; 5A ; POSITIVE_ENCODER_SIGNAL_A ; input ; 3.3-V LVTTL ; ; Row I/O ; Y ; no ; Off ;
; Y24 ; 180 ; 5A ; POSITIVE_ENCODER_SIGNAL_B ; input ; 3.3-V LVTTL ; ; Row I/O ; Y ; no ; Off ;
Do you want to get the list of synchronizers in the design? You can applysynchronizer identificationsettings
(Auto/Forced if Asynchronous) globally to automatically list all possible synchronizers. This can set with the Synchronizer identification option on the Timing Analyzer page in the Settings dialog box.
Well, I am actually using this option and it was not recognizing any real synchronizers as I understand it. We only have a single clock in our design to limit CDC issues. However, we have several asynchronous inputs and outputs. Due to a code change an output is multiplexed from different modules. The multiplexer involves a registers which feeds the output. These were recognized as synchronizers, when that was not the intent. Also, I don't really understand why you would want to synchronize an asynchronous outputs (UART Rx on opposite end). So, I have explicitly disabled synchronizers on async outputs.
However, the input that captures could possibly have metastable events (such as UART tx from the opposite (recieve on FPGA side)). Ie, the first flip-flop/register might have a clock exactly as the line is transitioning and the slow of this input could cause meta-stability. Perhaps there is some technology, etc. that I am unaware of in the I/O cells that prevents this. In the Altera paper,
'FPGA Architecture Enhancements' section talks about FPGA designs which have more meta-stable tolerant properties.
Also, Intel® Quartus® Prime Standard Edition User Guide Design Recommendations
Has Chapter 3, "Managing Metastability with the Intel Quartus Prime Software" which seems to indicate that different cells (LAB, etc) may have different meta-stable properties and Quartus may be able to optimize for this. Finally, I made a jump of logic that perhaps the I/O blocks would be the best place to put optimal flip-flops and ' FAST_INPUT_REGISTER ON' causes packing of verilog synchronizing registers to the I/O block of the Cyclone V.
----
I'm not sure if I understand correctly. Do you think that the report from the GUI and Tcl is different, and this might be a potential bug?
Well, I am not sure it is a bug. Just information. If it is normally offered by the GUI, but not now, then it might be helpful information?
New Contributor
