Setting Up Designs for Incremental Design

This section describes how designs should be set up and implemented for Incremental Design.

Identifying Logic Groups

For Incremental Design to significantly reduce runtime and maintain performance for unchanged portions of the design, the place and route implementation tools must see the design in separate logic groups. Each logic group should occupy an assigned space on the device. When a logic group is changed, the implementation tools can completely re-place and re-route the logic group inside of its assigned area without affecting the implementations of unchanged logic group. Having assigned ranges, which are completely open for re-placing and re-routing, allows the implementation tools to find the optimal configuration. For unchanged logic groups, the placement and routing is guided from a previous implementation of the design.

Logic groups are typically defined as the Verilog modules or VHDL entities instantiated in the top level. If lower levels of hierarchy are considered logic groups, the partitioning usually leaves some logic ungrouped. Having ungrouped logic in a design is not recommended because ungrouped logic can be placed anywhere on the device and may become an obstacle when re-placing and re-routing a changed logic group. If ungrouped logic cannot be avoided, the ungrouped logic should be locked down outside of any AREA GROUPs.

It is important to identify the logic groups and assign them to their own AREA GROUP RANGEs before trying to run the Incremental Design flow. If each logic group is not assigned to its own area, logic from different AREA GROUPs may be placed together.

All logic in the design, except IOB logic and clock logic, should be part of a logic group. This rule applies for making runtime improvements. The more a design is grouped, the less reimplementing there is when a change is made.

Each logic group should be assigned to an AREA GROUP using an AREA GROUP constraint.

Outputs of the logic group should be registered.

Logic groups should be single, hierarchical instances in the top level netlist. Lower level instances cannot be separated from top level instances using AREA GROUPs.

Creating AREA GROUPs

AREA GROUP floorplanning is the most important step in the Incremental Design flow. Poor AREA GROUP floorplanning can increase runtime, reduce performance, and possibly create an unroutable design.

An AREA GROUP constraint should be created for each logic group in the design with the PACE floorplanning tool. After logic groups are selected and drawn, the AREA GROUP and AREA GROUP RANGE constraints are written to the user constraints file (UCF).

Note: Automatic floorplanning is invoked when rangeless AREA GROUPs are present in a design. See the Automatic Floorplanning section of this chapter for details.

Lock down all I/Os, if already specified.

Place AREA GROUPs near the I/Os that they communicate with.

Position communicating AREA GROUPs next to each other.

Place AREA GROUPs on CLB tile boundaries. PACE will snap to this grid when drawing the AREA GROUP RANGEs. Floorplanner will show these boundaries as double lines when zoomed in.

Do not overlap AREA GROUPs.

Keep the slice utilization inside each AREA GROUP similar. One AREA GROUP should not be 99% full and another 10% full.

If an AREA GROUP contains multiple components such as TBUFs, Block RAMS, and Multipliers, it may be necessary to create separate ranges in the AREA GROUP to avoid consuming an unnecessary amount of slice logic. If an AREA GROUP contains all of these types of components, the syntax should look something like the following:

INST Logic_Group_A AREA_GROUP = AG_Logic_Group_A ;

AREA_GROUP "AG_Logic_Group_A" RANGE = SLICE_X0Y20:SLICE_X20Y30 ;

AREA_GROUP "AG_Logic_Group_A" RANGE = RAMB16_X0Y2:RAMB16_X0Y2 ;

AREA_GROUP "AG_Logic_Group_A" RANGE = MULT18X18_X0Y1:MULT18X18_X0Y1;

AREA_GROUP "AG_Logic_Group_A" RANGE = TBUF_X0Y0:X1Y0;

Note: This Syntax is for Virtex-II™ and Virtex-II Pro™ only. Refer to the Constraints Guide for more information.

Separate ranges for an AREA GROUP can be defined using PACE. See the PACE online help for additional information.

Automatic Floorplanning

If there are rangeless AREA GROUPS present in the design, automatic floorplanning is invoked during the first phase of the placer. For every rangeless AREA GROUP that contains at least one slice, a slice range is assigned. The subsequent placer phases treat these assigned ranges as HARD constraints to generate a placement. In addition, automatic floorplanning assigns individual sites to all BRAMs, MULTs, and DSPs that are contained in any rangeless AREA GROUPs.

For automatically generated slice ranges, sites are assigned for optimum wire usage and timing. Components are then soft located to the assigned sites for all subsequent phases of the placer. This provides initial sites for BRAMs, MULTs, and DSPs to the placer. The placer moves these components if QOR improves.

Slice ranges and soft locates generated by automatic floorplanning are placed in the NCD file for subsequent PAR runs and also appear in the PAR report file (.par).

Note: The output NCD file can be used as a guide file for running Incremental Enabled Mode. This requires cutting and pasting the constraints generated by automatic floorplanning from the PAR report file (.par) into the UCF.

The total number of AREA GROUPs should not exceed 200.

Some AREA GROUPs may have assigned ranges.

A large portion (more than 90%) of the components in the design should be contained in all AREA GROUPs.

Components not included in AREA GROUPs should be true context logic, meaning they should not form modules (tightly connected design parts) that are not area grouped.

Incremental Synthesis

With an “Incremental Synthesis” approach, unchanged logic groups are preserved and only changed logic groups are affected. Any changes to logic groups must meet timing in a flat compile for Incremental Design to work, and only changed logic groups should have updated netlist outputs.

Currently, synthesis tools re-synthesize the entire design, even for an incremental design change, which means that Incremental Synthesis is needed to keep the output the same for any unchanged logic groups. See the following sections for information on how specific synthesis tools work with Incremental Synthesis.

Mentor Leonardo Spectrum

Mentor supports both a bottom-up and a top-down methodology for Incremental Synthesis, but suggests using the bottom-up methodology. Using the bottom-up methodology, separate EDIF files are created for each logic group and for the top level. This flow is suggested because only one script needs to be rerun when a design change is made, making it easier to manage design changes. Since the bottom-up methodology is suggested, it is the only method described in this section.

The first step in the bottom-up method is to synthesize the lower level logic groups. Each lower level logic group is synthesized in macro mode, which automatically disables I/O and clock buffer insertion. A separate EDIF file is created for each.

The second step is to synthesize the top level file. The previously synthesized logic groups are read into the database and then the top level is read. The dont_touch attribute is assigned to each logic group to prevent any optimization and the noopt attribute is used to prevent the logic groups from being written out in the top.edf file.

The Xilinx translation tool, NGDBuild, reads in the top level EDIF and the lower level EDIF files to create one design file, design.ngd.

Synplicity Synplify/Synplify Pro

Synplify Pro always resynthesizes the entire design. This often results in different signal and component names in unchanged logic groups. This causes the Xilinx Incremental Design flow to assume that this is changed logic and will re-place and re-route the entire design. In order to preserve unchanged logic groups, separate projects must be created for each logic group and for the top level.

The goal is to create a top level EDIF that instantiates the lower level EDIF files. A change in one EDIF file will not affect the other EDIF files. This has the advantage of faster synthesis runtimes, because only a portion of the design will be resynthesized. Synplify attributes are used to guide the synthesis.

The first step is to create a top level EDIF that instantiates the lower level EDIF files as black boxes.

The second step is to create all of the lower level EDIF files. The logic group EDIF files must be synthesized without inferring I/Os or clock buffers.

To disable I/O insertion, select Disable I/O Insertion in the Synplify Pro GUI.

No clock buffer will be inferenced when Disable I/O Insertion is turned on.

The Xilinx translation tool, NGDBuild, reads in the top level EDIF and the lower level EDIF files to create one design file, design.ngd.

Xilinx Synthesis Tool (XST)

XST supports block level incremental synthesis, within a single project. Attributes are applied to each logic group in the XST constraints file (.xcf) to define logic group boundaries. 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.