We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Page Bookmarked

AR# 12300

5.1i xilinx2primetime - Internal generated Clock is not analyzed the same between PrimeTime and trce


General Description:

My internally generated clocks are analyzed differently between PrimeTime and TRCE. Why?


When creating a clock from flip-flop, PrimeTime users define the clock using create_generated_clock command in terms of a primary clock. That is how PrimeTime understands that the FF's output is a clock. Therefore, PrimeTime will calculate the clock skew relative to the Primary Clock that defines this clock. Use the following command:

report_timing -path_type full_clock

To see how the clock delay is calculated by PrimeTime. Looks like TA has a different understanding of definition for the clock from FF's output. This difference causing the two behavior.

I consider this type of difference between the two tools as one of the facts of life. Since PrimeTime is not a Xilinx sign-off STA yet, we ask user to compare the PT result to TRCE result just to be sure. That is how we are catching the differences. As we are going toward the sign-off, we need to ensure that Primetime is not falsely reporting a violation or hiding a violation as compared to TRCE. For example, we have seen the case, i.e. paths from primary input to negative edge triggered flip-flop will have different slacks in TRCE and PrimeTime. PrimeTime may show violation but TRCE will not due to the method that is used to calculate the slack. We are working to establish correlation between PT and TRCE since for sign-off status this is an issue. For this specific testcase, looks like this deference is not causing PT to hide a violation or falsely report one, but for other cases it may. We will document this difference for time being, and I work with Kate on how to address it in the long term.

It is not recommended to use this type clock generation for FPGAs.

AR# 12300
Date 01/18/2010
Status Archive
Type General Article