Vendor Specific Notes for Incremental Synthesis

Vendor Specific Notes for Incremental Synthesis

Use the following procedures for the synthesis tool you are using. If the tool is not listed, refer to the tool’s user documentation.

Incremental Synthesis Using Leonardo Spectrum

Leonardo Spectrum supports both a bottom-up and a top-down methodology for Incremental Synthesis, but suggests using the bottom-up methodology. A description of how to use each method and example TCL scripts for each are provided below.

Bottom-Up Methodology

The bottom-up methodology requires that all logic groups and the top level be synthesized separately and that separate EDIF netlists be created for each logic group and for the top level. This method is recommended because only the synthesis script for the changed logic group needs to be rerun when a small design change is made. The steps to use this method are provided below.

Note: The example TCL scripts below assume a design with three logic groups, a,b,c and a top level, top.

For more information on logic groups, refer to the “Identifying Logic Groups” section.

Synthesize each logic group and write out a separate EDIF file for each. When synthesizing each logic group, it is important to use macro mode, which will automatically disable I/O and clock buffer insertion.

An example TCL script for logic group “a” follows:

#Clear database and libraries of any previously existing designs

clean_all

#Set the technology environment for a Virtex-II

set part 2V80fg256

set process 5

set wire_table xcv2-80-5_avg

load_library xcv2

#Read in the design file or files for this Logic Group

read -technology "xcv2" { a.v }

#Set the timing constraints

set input2register 9

set register2output 14

set_clock -name .work.a.INTERFACE.clk -clock_cycle "10.000000"

set_clock -name .work.a.INTERFACE.clk -pulse_width "5.000000"

#Optimize the Logic Group in macro mode to prevent I/O or clock buffer insertion

optimize .work.a.INTERFACE -target xcv2 -macro -area -effort standard -hierarchy auto

#Optimize for timing

optimize_timing .work.a.INTERFACE

#Disable NCF creation

set novendor_constraint_file TRUE

#Write out the Logic Group as a binary XDB database and EDIF netlist

auto_write a.edf

Note: The above script synthesizes logic group “a.“ A separate script is needed for logic groups “b” and “c.”

Synthesize the top level. Each of the previously optimized logic groups are read in and the DONT TOUCH and NOOPT attributes are applied to each. The DONT TOUCH attribute is used to prevent the previously optimized logic groups from being reoptimized. The NOOPT attribute is used to prevent the previously optimized logic groups from being written out inside the top level EDIF.

An example TCL script is provided below:

#Clear database and libraries of any previously existing designs

clean_all

#Set the technology environment for a Virtex-II and enable register mapping to the I/Os

set part 2V80fg256

set process 5

set wire_table xcv2-80-5_avg

set virtex_map_iob_registers TRUE

load_library xcv2

#Load previously optimized Logic Groups

read -technology "xcv2" { a.xdb }

read -technology "xcv2" { b.xdb }

read -technology "xcv2" { c.xdb }

#Read in and elaborate the top level

read -technology "xcv2" { top.v }

#DONT_TOUCH attribute prevents each Logic Group from being reoptimized

DONT_TOUCH .work.a.INTERFACE

DONT_TOUCH .work.b.INTERFACE

DONT_TOUCH .work.c.INTERFACE

#NOOPT attribute prevents each Logic Group from being written into the top level edif

NOOPT .work.a.INTERFACE

NOOPT .work.b.INTERFACE

NOOPT .work.c.INTERFACE

#Set timing constraints

set input2register 10

set register2output 15

set_clock -name .work.top.INTERFACE.clk -clock_cycle "10.000000"

set_clock -name .work.top.INTERFACE.clk -pulse_width "5.000000"

#Optimize top level and preserve hierarchy

optimize .work.top.INTERFACE -target xcv2 -chip -area -effort standard -hierarchy preserve

optimize_timing .work.top.INTERFACE

#Generate Reports

report_area area.txt -cell_usage

report_delay delay.txt -num_paths 1 -longest_path -clock_frequency

#Enable NCF creation

set novendor_constraint_file FALSE

#Write out the top level as a binary XDB database and EDIF netlist

auto_write top.edf

The design is now ready to be run through the Xilinx implementation tools. When a design change is made, only the script for the changed logic group needs to be rerun and thus only one EDIF file will be changed.

Note: It is also possible for Leonardo Spectrum to combine the entire design into one top level EDIF file. To do this, remove the NOOPT attribute.

Without the NOOPT attribute, the previously optimized logic groups will be written out into the top level EDIF. This is not recommended, as both the script for the changed logic group and the script for the top level must be rerun when a design change is made, but it can be done if it is required to only have one EDIF file.

Top-Down Preserving Hierarchy Methodology

Leonardo Spectrum Level 3 provides the necessary hierarchy control and optimization capabilities necessary to accommodate the top-down preserving hierarchy methodology. Using this flow, one EDIF file will be created. One script is used to run an initial synthesis and a second script is used for Incremental Synthesis passes.

Initial Synthesis Using Top-Down Preserving Hierarchy

This section contains an example script for running the Initial Synthesis pass for the top-down preserving hierarchy method. When running this pass, it is important to set bubble_tristates to FALSE and to set no_boundary_optimization to TRUE. These settings will keep the hierarchy “pure” and unchanged. It is also important to preserve hierarchy when synthesizing. Below is an example TCL script:

#Clear database and libraries of any previously existing designs

clean_all

#Set bubble_tristates FALSE to ensure that the tristates will not moved across hierarchy boundary.

#Users must place all tristate I/O at the top level to use a block-based flow

set bubble_tristates FALSE

#Set no_boundary_optimization to prevent constant propagation and other boundary

#effect optimizations. This may cause degradation in QoR if the design makes use

of constants across hierarchical boundaries

set no_boundary_optimization TRUE

#Set the technology environment for a Virtex-II and enable register mapping to the I/Os

set part 2V80fg256

set process 5

set wire_table xcv2-80-5_avg

set virtex_map_iob_registers TRUE

load_library xcv2

#Read the entire design with top.v as the top level module

read -technology "xcv2" {

    a.v

    b.v

    c.v

    top.v}

#Set timing constraints

set input2register 10

set register2output 10

set_clock -port -name .work.top.INTERFACE.clk -clock_cycle "10.000000"

set_clock -port -name .work.top.INTERFACE.clk -pulse_width "5.000000"

#Optimize the design and preserve hierarchy

optimize .work.top.INTERFACE -target xcv2 -chip -area -effort standard -hierarchy preserve

optimize_timing .work.top.INTERFACE

#Generate reports

report_area area.txt -cell_usage

report_delay delay.txt -num_paths 1 -longest_path -clock_frequency

#Write out entire design as a binary XDB database and EDIF netlist

auto_write top.edf

After running the above script, the design is ready for an initial implementation pass. When small design changes are made to one of the logic groups, the incremental script in the next section must be used to update the EDIF file.

Incremental Synthesis Using Top-Down Preserving Hierarchy

When a change is made to a logic group, the commands for synthesizing the design are slightly different in this flow. The key to a successful Incremental Synthesis is to ensure that only the modified logic group is modified in the EDIF netlist. To achieve this, Leonardo Spectrum has the ability to reload and re-optimize a changed logic group, while leaving the other logic groups unchanged.

An example TCL script is provided below:

#Clear database and libraries of any previously existing designs

clean_all

#Set bubble_tristates FALSE to ensure that the tristates will not moved across hierarchy boundary.

#Users must place all tristate I/O at the top level to use a block-based flow

set bubble_tristates FALSE

#Set no_boundary_optimization to prevent constant propagation and other boundary

#effect optimizations. This may cause degradation in QoR if the design makes use

#of constants across hierarchical boundaries

set no_boundary_optimization TRUE

#Set the technology environment for a Virtex-II and enable register mapping to the I/Os

set part 2V80fg256

set process 5

set wire_table xcv2-80-5_avg

set virtex_map_iob_registers TRUE

load_library xcv2

#Reload the previously optimized design

read -technology "xcv2" { TOP.xdb }

#Read in the modified Logic Group

read -technology "xcv2" { b.v }

#Set Timing Constraints

set input2register 10

set register2output 10

set_clock -name .work.top.INTERFACE.clk -clock_cycle "10.000000"

set_clock -name .work.top.INTERFACE.clk -pulse_width "5.000000"

#Optimize the modified Logic Group in macro mode

optimize .work.b.INTERFACE -target xcv2 -macro -delay -effort standard -hierarchy preserve

#Set top as the present design

present_design .work.top.INTERFACE

#Optimize the timing of the modified Logic Group

optimize_timing .work.b.INTERFACE

#Generate Reports

report_area area.txt -cell_usage

report_delay delay.txt -num_paths 1 -longest_path -clock_frequency

#Write out the entire design as a binary XDB database and EDIF netlist

auto_write top.edf

The new EDIF is now ready to be run through the Incremental Design flow. Each time a logic group is modified, this script is used to update the EDIF file.

Incremental Synthesis Using Synplify/Synplify Pro

When using Synplify Pro for Incremental Synthesis, a separate project is created for each logic group and for the top level. When changes are made to a logic group, the project for that logic group is used to generate a new EDIF file, while the EDIF files for the top level and for the unchanged logic groups will remain the same. This will allow the design to be used with the Incremental Design flow.

Creating an EDIF for the Top Level

The first step is to create a top level EDIF that instantiates the lower level EDIF files as black boxes. Below is an example of the steps used to create the top level EDIF file.

Create a new Project File named TOP.

Click on Impl Options to select the target device

Add the library file for the target device. For example, if the design is coded in Verilog and a Virtex-II device is being targeted, add virtex2.v. The library files are located under \lib\xilinx in the directory where Synplify is installed.

Add the top level file:

In the Top Level, “/* synthesis syn_black_box */” must be applied to each instantiated logic group. This will tell Synplify to treat each instantiation as a black box.

"/* synthesis syn_isclock = 1 */” should be applied to the clock ports of instantiated logic groups. This will instruct Synplify to infer a BUFG if one has not already been assigned to the signal that drives the port.

Press Run.

At this stage, a top level EDIF file should be created. The EDIF contains all of the I/O and clock logic, as well as black box instantiations of all of the logic groups in the design.

Save the Project.

Creating an EDIF for each Logic Group

The following steps describe how to create an EDIF file for a logic group:

Create a new Project File with the name of the logic group.

Click on Impl Options

Select the target device.

Check the option to Disable I/O insertion. This will also disable clock buffer insertion.

Add the library file for the target device.

Add the file or files for this logic group.

Press Run.

Save the Project.

Note: The above steps must be followed for each logic group in the design. After EDIF files have been created for each logic group, all of the EDIF files can be copied to an implementation directory where the Xilinx Incremental Design flow can be run.

When a design change is made, reopen the project for the changed logic group and recreate the EDIF file; then copy the new EDIF file into the implementation directory and rerun the Incremental Design flow.

Incremental Synthesis Using XST

XST supports block level incremental synthesis. An HDL change in one of these logic groups will only affect that logic group; the rest of the logic groups will not be changed. The unmodified portions of the design will still be parsed, but new netlists (.ngc files) will not be written.

Logic groups are defined using the incremental_synthesis attribute. Attributes to define logic group boundaries are entered in the XST constraints file (.xcf) or within the HDL source itself. The top level does not require this attribute. An NGC file will be created for each logic group and for the top level. If a module/entity is instantiated within a design more than once and is defined as the top of a logic group, a unique .ngc file will be created for each instance.

When a logic change is made to any module/entity within one of the logic groups, only that logic group should be reoptimized. For VHDL designs, XST automatically detects any changes to the source HDL files and resynthesizes only the logic groups containing modified modules/entities. For Verilog designs, the resynthesize attribute is required for XST to be made aware of logic changes.

You will see evidence of Incremental Synthesis in the XST log file in a number of locations. First, when the Incremental Synthesis attributes are parsed, you will see:

Reading constraint file C:\design\top.xcf.

Set property "INCREMENTAL_SYNTHESIS = yes" for unit <a>.

Set property "INCREMENTAL_SYNTHESIS = yes" for unit <b>.

Set property "INCREMENTAL_SYNTHESIS = yes" for unit <c>.

XCF parsing done.

During the initial synthesis run, you will see that each logic group is optimized and multiple .ngc files are created:

======================================================================

* Low Level Synthesis *

======================================================================

Optimizing unit <top> ...

Optimizing unit <a> ...

Optimizing unit <b> ...

Optimizing unit <c> ...

…

======================================================================

* Final Report *

======================================================================

Final Results

Top Level Output File Name : top

Output File Name : a.ngc

Output File Name : b.ngc

Output File Name : c.ngc

…

Finally, during the incremental pass, you will see that only the modified Logic Group is reoptimized:

======================================================================

* Low Level Synthesis *

======================================================================

Incremental synthesis: Unit <a> is up to date ...

Incremental synthesis: Unit <b> is up to date ...

Incremental synthesis: Unit <top> is up to date ...

Optimizing unit <b> ...

…

Here is an example XCF file. Consult the XST Users Guide for more details about XST constraint file syntax.

# Use the "incremental_synthesis" attribute to denote Logic Groups

MODEL "a"

incremental_synthesis=yes;

MODEL "b"

incremental_synthesis=yes;

MODEL "c"

incremental_synthesis=yes;

# The "resynthesize" attribute is only required for Verilog designs

MODEL "top" resynthesize=no;

MODEL "a" resynthesize=no;

MODEL "b" resynthesize=yes;

MODEL "c" resynthesize=no;

# End .XCF file

Note: If you have previously synthesized your design without the Incremental Synthesis attributes, or if you have changed the structure of the logic groups of the design, you must remove the existing .ngc files before you can synthesize again. This is easily done within Project Navigator by selecting Project > Cleanup Project Files.

XST needs to have an initial set of .ngc files that build the current proper hierarchy before an Incremental Synthesis run can be performed.