AR# 12824: 6.1i PrimeTime - How does the Xilinx verification flow work with PrimeTime?
6.1i PrimeTime - How does the Xilinx verification flow work with PrimeTime?
Keywords: TRACE, 4.1i, 5.1i
General Description: How does the Xilinx verification flow work with PrimeTime?
To participate in this evaluation program, you must have access to the Xilinx 5.1i design tools. If you do not have the design tools installed at your site, contact your Xilinx FAE or Hamid Agah (email@example.com) for more information. You must also be familiar with TRCE, the UCF format, PrimeTime, and the SDC (Synopsys Design Constraint) format to participate effectively in the evaluation program.
You must also review the "Xilinx/Synopsys PrimeTime Interface" document before proceeding with this evaluation. For support throughout this evaluation, contact your Xilinx FAE or Hamid Agah (firstname.lastname@example.org).
The focus of this evaluation is twofold:
1. To use a set of designs that are targeted to Virtex-II, and to identify areas of discrepancy between TRCE and PrimeTime timing reports. 2. To evaluate the usability and effectiveness of the PrimeTime interface for analyzing and isolating timing issues for Virtex-II-targeted designs in PrimeTime.
Architecture and Test Case Selection Criteria
Xilinx recommends the following:
Target architecture: Virtex-II Pro (Preferred)
Test cases: To become familiar with the flow, use a small design that has known timing characteristics (TRCE reports). Then, use two real designs with medium to high complexity. In this case, "complexity" refers to the number of clocks (number of DCMs), the use of various Virtex-II resources, and size (system gates).
The PrimeTime Verification Flow for Xilinx Devices:
The following information describes the proposed PrimeTime flow as presented in the Xilinx Application Note "Xilinx/Synopsys Formality Verification Flow" (Xilinx XAPP414):
1. Synthesize the design in FC2 (or your preferred synthesis tool) using the following global constraints:
PERIOD OFFSET IN OFFSET OUT P2P
(NOTE: Do not use the MAXDELAY to constrain input-to-register paths or register-to-output paths. The MAXDELAY constraint should be replaced by either an OFFSET IN constraint (for input-to-register paths) or an OFFSET OUT constraint (for register-to-output paths).
2. Implement your design in Xilinx 6.1i design tools. (NOTE: If your design was implemented in 5.1i, it must be re-implemented using 6.1i.)
The global constraints defined in Step 1 should be used to drive the timing-driven PAR. These constraints are either written by the synthesis tool in the form of an NCF file, or a UCF file is created by the Xilinx Constraints Editor.
3. Consult the TRCE report for each global constraint:
For each global constraint, instruct TRCE to display at least 10 worst-case paths (if possible). Identify and take note of paths with a reported zero clock skew. (TRCE reports zero clock skew if the calculated clock skew is a very small number or is a positive number.) PrimeTime might report different timing numbers for these paths; this known area of discrepancy between TRCE and PrimeTime will be addressed in the next major release of the design tools.
Path_Tracing Control: By default, TRCE enables or disables a number of special timing paths. For example, the register reset/set-to-output time delay is disabled, and the RAM write enable-to-output propagation delay is enabled by default. PrimeTime enables all these paths by default unless instructed otherwise.
4. Generate a back-annotated (time_sim) netlist in Verilog format and SDF files with NetGen.
5. Back-annotated (time_sim) Verilog netlist processing is required before the netlist can be read into PrimeTime.
The SDF file written by the 6.1i design tools requires no modification and can be read into PrimeTime as is.
6. Generate PrimeTime Constraints (SDC).
PrimeTime accepts only SDC-formatted timing constraints. Xilinx provides a "pcf2sdc" command that translates the timing constraints used to drive place-and-route. The "pcf2sdc" command can translate only the four global constraints mentioned above.
7. Read the SimPrims synthesis library, the PrimeTime-friendly Verilog netlist, and SDF/SDC constraints into PrimeTime.
Resolve any issues related to reading this information in PrimeTime before continuing.
8. Prepare the PrimeTime environment for timing analysis.
9. Run a timing analysis in PrimeTime and establish a correlation with TRCE.
Analyze the design's timing in PrimeTime by using "report_timing -input -net" to obtain at least 10 worst-case paths; compare these to the TRCE report that was obtained in Step 3. (The TRCE report should contain 10 worst-case timing slack instances for each global constraint.)
Your comments and feedback are crucial to the success of this flow. Our objective is to elevate PrimeTime so that it is supported as a Xilinx endorsed sign-off STA tool in 2003. We need your help, and ask that you:
1. Share with us the list of PrimeTime SDC constraints that you use to analyze your design in PrimeTime. This provides us with the types of SDC constraints that are being used to constrain FPGA designs.
2. Assist us in identifying PrimeTime and TRACE correlation issues.
3. Share your comments on the usability of the existing flow and the list of required enhancements that contribute to your productivity in using PrimeTime with Xilinx devices.
1. The "pcf2sdc.pl" script can create an SDC command that might cause a PrimeTime error when the "Pad-to-pad combinational delay" constraint is translated into its equivalent SDC command, "set_max_delay." The following examples illustrate the automatically translated SDC command (BAD) and manually corrected command (GOOD) :
set_max_delay -from [all_inputs -clocks] to [all_outputs] delay_number (BAD)
set_max_delay -from [remove_from_collection [all_inputs] [get_port name_of_the_clock]] to [all_outputs] delay_number (GOOD)
2. The "pcf2sdc.pl" script translates the PERIOD timing information in the PCF into the equivalent SDC command "create_clock"; however, some of the PERIOD timing information relates to the outputs of DLL/DCM, which must be translated into "create_generated_clock". Carefully examine the output "pcf2sdc.pl" and modify it manually as needed; failure to do so will result in improper analysis.
3. In PrimeTime, an error might be reported after the "read_ver" command is executed to read in the PrimeTime-friendly Verilog netlist. The error might relate to a very long ASSIGN line in the netlist. This is a known defect in PrimeTime versions 2000.11 and earlier.
There are two ways to work around the problem:
a. Edit the netlist and modify the long ASSIGN statement into individual ASSIGN statements. b. Switch to PrimeTime version 2001.06, because the defect has been fixed in this version.
4. After the "read_sdf" command is executed in PrimeTime, warning messages similar to the following might be reported:
"Warning: The timing arc ( 0->1 1->0 ) of cell `PMcbuf10/OBUFT` from `CTL` to `O` could not be annotated. (SDF-019)"
This warning is generated for each instance of an "X_TRI" element in the Verilog netlist. Although hundreds of warning messages could potentially be generated, these warnings can be safely ignored. We will keep you posted on resolution of this item.