Tips & Hints

Synplify Pro Software

Q. How do you set Synplify timing constraints to work with the OFFSET delay for Xilinx

A. IO delays are very important constraints in timing computations of any designs. IO delays are the delays that exist in the logic around the pads of FPGA, but the tool has no way of knowing them unless you specify the delays using a timing constraint.

These timing constraints in the Synplify tool are “define_input_delay” and “define_output_delay”. While in Xilinx, they are “OFFSET.”

The following illustrates how the Synplify software interprets the Xilinx timing delay.

Definitions:

Synplify delay constraints:

Define_input_delay specifies the external input delays on top-level input ports in the design. It is the delay outside the chip before the signal arrives at the input pin.
Define_output_delay specifies the delay of the logic outside the FPGA driven by the top-level output ports. The default delay outside the FPGA is 0.0 ns.

Xilinx delay constraint:

OFFSET is a basic timing constraint. It specifies the timing relationship between an external clock and its associated data-in or data-out pin.

Xilinx method:

For Xilinx, OFFSET can be used to declare delays either internal or external to FPGA. There are 4 combinations to declare OFFSET:

• IN_BEFORE
• IN_AFTER
• OUT_AFTER
• OUT_BEFORE

Synplify method:

With the Synplify software, both Input and Output delays are the delays outside the FPGA with reference to the clock edge on which external logic is triggered. These delay values are considered while computing the timing for the respective I/O paths.
When the delays are specified in the UCF (Xilinx constraints file) with reference to IN_AFTER OFFSET and OUT_BEFORE OFFSET, then

Define_input_delay = <OFFSET> value
Define_output_delay = <OFFSET> value

And when the delays are specified in the UCF with reference to “IN_BEFORE” or “OUT_AFTER” then

Define_input_delay = <clock time period> value – <OFFSET> value.
Define_output_delay = <clock time period> value – <OFFSET> value.

Note: The above calculations can be done manually or by using a utility called “UCF2SDC” provided in the $BIN directory of your Synplify installation.

The Synplify tool forward annotates IO delays to the Xilinx PAR tool in terms of the OFFSET constraint in the NCF file where the following rule are being used.

• Always written with respect to rising edge of clock.
• Always written in OFFSET IN_BEFORE combination for Input delay.
• Always written in OFFSET OUT_AFTER combination for Output delay.

Example

SDC

define_clock -name {clk} -period 10.000 -clockgroup clkgroup_clk
define_input_delay {sften} 6.00 -improve 0.00 -route 0.00 -ref {clk:r}

NCF

NET "clk" TNM_NET = "clk";
TIMESPEC "TS_clk" = PERIOD "clk" 10.000 ns HIGH 50.00%;

NET "sften" TNM = "sften";
TIMEGRP "sften" OFFSET = IN: 4.000 : BEFORE clk;

Q. Can you choose a particular version of Quartus PAR for a clearbox file?

A. Yes. There are two parts to this process:

Part A – Choosing the Correct Quartus Version in the Synplify Pro tool

The Altera Megawizard generated clearbox files are not always compatible with all the versions of Quartus because of the constant updates made in Quartus. This incompatibility results in PAR errors.

The Synplify Pro software provides a way to choose a particular version of Quartus for a clearbox file.
To choose the correct version of Quartus –
1) In the main Synplify Pro UI, click “Implementations Options”.
2) Click on the Implementations Results Tab.
3) Select the pull-down list of Quartus Versions by clicking the down arrow
4) Select the appropriate version.

If you are in doubt about which Quartus version to choose, the header of the Megawizard generated file should have the Quartus Version from which it was created.

// megafunction wizard: %ALTACCUMULATE%
// GENERATION: STANDARD
// VERSION: WM1.0
// MODULE: altaccumulate
// ============================================================
// File Name: test.v
// Megafunction Name(s):
// altaccumulate
// ============================================================
// ************************************************************
// THIS IS A WIZARD-GENERATED FILE. DO NOT EDIT THIS FILE!
//
// 6.0 Build 178 04/27/2006 SJ Full Version
// ************************************************************
//Copyright (C) 1991-2006 Altera Corporation

Part B – Marking the Megawizard generated file as a clearbox file in the Synplify Pro software.

To mark a Megawizard generated file as a clearbox file –
1) In the main Synplify Pro UI, right click on the the Megawizard generated file.
2) Select “File Options”
3) Select “Clearbox Verilog” in the drop down menu for “File Type”
4) A separate folder “Clearbox Verilog” will be created.

Once the file is marked as a Clearbox Verilog, the Synplify Pro tool makes sure that this file gets copied into the PAR directory.

Synplify Premier Software

Q. During Graph-Based Physical Synthesis, are there any intermediate files generated for debugging purposes?

A. Yes. Graph-Based Physical Synthesis generates two intermediate HDL Analyst Technology View files for debugging purposes. The first file, labeled ìpreplace.srmî, captures the netlist immediately before global placement and is analogous to results that would be obtained via logic synthesis. The second file, called ìpostplace.srmî, captures the netlist immediately after global placement but before physical optimizations. Exact global placement locations are preserved in ìpostplace.srmî before physical optimizations take effect. Both ìpreplace.srmî and ìpostplace.srmî files can be found in the physical synthesis implementation directory. To open either the ìpreplace.srmî or ìpostplace.srmî HDL Analyst Technology View, place the cursor over the desired file and hit the right mouse button to select the open option from the menu.

Identify RTL Debugger Software

Q. Can you trigger one Identify Debugger from another?

A. Yes. Identify has a feature called “Remote triggering” which allows one debugger executable to send a software trigger event to terminate data collection in the other debugger executables, effectively creating a remote stop button.

You can selectively set the remote trigger to:

• Trigger all IICEs in all Debugger executables
• Trigger all IICEs in a specific Debugger executable
• Trigger a specific IICE in a specific Debugger executable

A common design configuration is to trigger all FPGAs on a single board-level event. When that event occurs, data collection is stopped and the sample data is downloaded by the corresponding Debugger executables for all FPGAs.

Remote triggering is a scripting application. The IICE/debugger targets are defined by the remote_trigger command.

As an example, the scripting sequence

run ; remote_trigger -pid 12

waits for the trigger condition in the current IICE and then sends a trigger to all IICE units in the debugger executable identified by processID 12.