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> ] [-multi_corner] [-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 | |||
-multi_corner | When set, running this command with the -panel option will create a folder containing versions of this report for multiple operating conditions. This option has no effect when used with the -stdout or -file options. | |||
-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. | |||
Description |
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. ---------- Background ---------- 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. ------ Output ------ 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. -------- Settings -------- 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 algorithms. 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. ------------- 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. Please refer to the Metastabiliity Optimization section in the Timing Optimization Advisor for further information. |
|||
Example Usage |
project_open top create_timing_netlist read_sdc update_timing_netlist report_metastability delete_timing_netlist project_close |
|||
Return Value | Code Name | Code | String Return | |
TCL_OK | 0 | INFO: Operation successful |