report_metastability (::quartus::sta)

The following table displays information for the report_metastability Tcl command:

Tcl Package and Version

Belongs to ::quartus::sta 1.0

Syntax report_metastability [-h | -help] [-long_help] [-append] [-file <name> ] [-length <number> ] [-max_length <number> ] [-min_length <number> ] [-nchains <number> ] [-panel_name <name> ] [-stdout]
Arguments -h | -help Short help
-long_help Long help with examples and possible return values
-append If output is sent to a file, this option appends the result to that file. Otherwise, the file will be overwritten. This option is not supported for HTML files.
-file <name> Sends the results to an ASCII or HTML file. Depending on the extension
-length <number> Reports only the synchronizer chains of an exact length
-max_length <number> Specifies the maximum length of a chain that appears in the report (default=no limit)
-min_length <number> Specifies the minimum length of a chain that appears in the report (default=0)
-nchains <number> Specifies the number of chains to report (default=1)
-panel_name <name> Sends the results to the panel and specifies the name of the new panel
-stdout Send output to stdout, via messages. You only need to use this option if you have selected another output format, such as a file, and would also like to receive messages.
Report can be directed to the Tcl console ("-stdout", default), a file
("-file"), the Timing Analyzer graphical interface ("-panel_name"), or any
combination of the three.

The report_metastability function can be used to estimate the robustness
of asynchronous transfers in your design.  


Synchronization register chains should be used when transferring data
between unrelated clock domains to greatly reduce the probability of the
captured data signal becoming metastable.  A synchronization register
chain is a sequence of registers with the same clock, that is driven by a pin, 
or logic from an unrelated clock domain.  The output of all but the last 
register in the chain must connect only to the next register, either directly 
or indirectly through logic.

When a register is metastable, its output hovers at a voltage between high
and low for a length of time beyond the normal Tco for the register.  The
design can fail if subsequent registers that use this metastable signal
latch different values.  Therefore, it is important to properly
synchronize data signals to prevent such occurrences.


The report_metastability function generates a list of synchronization
register chains found in the design, and can provide estimates of the Mean 
Time Between Failures (MTBF) of each chain.  The design MTBF is an estimate 
of the overall robustness of the design, computed from the MTBF results from
all synchronization chains with calculated MTBFs.  The design MTBF metric is 
reported only when the design meets timing.  Therefore, it is important to 
fully timing constrain your design.

The typical MTBF result assumes typical silicon characteristics for the 
selected device speed grade, with nominal operating conditions. 

The worst case MTBF result uses the worst case silicon characteristics for 
the selected device speed grade, with worst case operating conditions.


To get a list of possible synchronization chains, set "Synchronizer
Identification" to AUTO in the Timing Analyzer Page in the Settings 
dialog box.  This will set the "Synchronizer Identification" QSF 
assignment in your QSF file.  The Timing Analyzer will use timing constraints to 
automatically detect synchronization chains in the design. Metastability
analysis checks for signal transfers between circuitry in unrelated or 
asynchronous clock domains, so clock domains must be related correctly 
with the timing constraints. 

Set the maximum number of registers to consider as part of one 
synchronization chain, via the "Synchronization Register Chain Length" 
setting under Analysis and Synthesis Page in the Settings dialog box.  
The default length is 2. All the registers in a chain (up to this length) 
will be protected from optimizations that can decrease MTBF.  

Note that if you change the "Synchronizer Identification" setting, you 
should rerun the Fitter, as this setting can impact some optimization 

Use the -nchains option to limit the number of chains to report. If you
do not specify this option, only the single worst-case chain is reported.

To filter the synchronizer chains by their lengths, use the -min_length option
to set the minimum chain length to be reported, and use the -max_length
option to set the maximum chain length to be reported. Alternatively, use 
the -length option to report only chains with a specific length.

Report Panels

The MTBF Summary report provides the estimated mean time between failure 
for the design.  This is an estimate for the overall robustness of the 
design in terms of metastability, and it is computed from all available 
synchronization chain MTBFs present in the design.

The MTBF metric of automatically identified synchronization chains is not 
computed.  To compute the MTBF of a synchronization chain, set 
"Synchronizer Identification" to "Forced If Asynchronous" or "Forced" 
for all registers of the synchronization chain.  By explicitly specifying 
that this synchronization chain is valid, this chain will then be optimized 
during the Fitter, and its MTBF will be computed.  Its MTBF will then be 
included in the computation of the design MTBF.

The Synchronizer Summary table lists all the synchronization chains
found in your design.  It is possible that the analysis performed might
erroneously interpret certain structures, such as shift registers, as
synchronization chains.  If some synchronization chains are misidentified
and you wish to remove them from the report, you can turn off analysis of
these paths by making node-based assignments via the Assignment Editor,
set "Synchronizer Identification" to "Off" for the first register in these
synchronization chains.  Conversely, if there are synchronization
chains in your design that were not detected, you can set "Synchronizer
Identification" assignment to "Forced If Asynchronous" for all registers in 
this chain through the Assignment Editor, and this chain will be 
reported if it meets the criteria for being a synchronization chain.  This 
can often occur if there is logic present between the registers of the 
synchronization chain.  In the automatic mode of synchronizer identification,
these structures are not considered to be synchronizers. If you want to 
force a register to be identified as the head of a synchronizer, set the 
"Synchronizer Identification" assignment to "Forced" to the register, 
and it will always be identified as the first of a synchronization chain.
This setting should not be applied to the entire design, since this will 
identify every register in the design as a synchronizer.  

The MTBF estimates assume the data being synchronized is switching at a 
toggle rate of 12.5% of the source clock frequency.  That is, the estimates 
assume that the arriving data signal switches once every 8 source clock 
cycles.  If multiple clocks apply, the highest frequency is used.	If no 
source clocks can be determined, then the data rate is taken as 12.5% of 
the synchronization clock frequency.  

If you know the approximate rate at which the data changes, and would like
to obtain a more accurate MTBF, use the "Synchronizer Toggle Rate" assignment
in the Assignment Editor.  Set the data toggle rate, in number of transitions
per second, on the first register of a synchronization chain.  The Timing
Analyzer will then take the specified rate into account when computing the MTBF
of that particular chain.  You can also apply this assignment to an entity or the
entire design. Since a "Synchronizer Toggle Rate" assignment of 0 indicates 
that the data signal never toggles, the affected synchronization chain will 
not be reported since it does not affect the relibility of the design.
Example Usage
project_open top


# Reports only 10 chains that are between 2 and 4 registers long
report_metastability -min_length 2 -max_length 4 -nchains 10

Return Value Code Name Code String Return
TCL_OK 0 INFO: Operation successful