In the SmartXplorer result, there are runs with non-zero Timing Score but positive Worst Case Slack, as shown in the following screen capture.
Why does this occur?
This is a known issue with Smartxplorer.
This issue occurs when the Worst Case Slack comes from a hold error and the setup slack of the corresponding constraint is positive.
SmartXplorer only honors the setup slack but not the hold, so it extracts the positive setup slack value as the Worst Case Slack.
SmartXplorer extracts the Worst Case Slack value from the timing summary table in the PAR report.
The 3.622ns in the above example in the Description comes from the Worst Case Slack of the first constraint in the following table:
This constraint is listed in the first place because its hold slack is the worst case slack in the design.
However, SmartXplorer incorrectly uses the setup slack as the Worst Case Slack in the SmartXplorer result.
To determine the best strategy from SmartXplorer, refer to the Timing Score.
The Worst Case Slack is only for reference.
If you want to know the actual Worst Case Slack when this issue occurs, please refer to the PAR report.