Large and  complex complex designs are now commonly implemented in FPGAs. Whilst the synthesis tools available to the designer have improved vastly both in speed and in the quality of results there still many designs where incremental synthesis can be of use. There  two main benefits to be gained from using a form of incremental synthesis. These are (a) time to synthesis, (b) The limiting of change in logic structures between design builds.

The benefits of reducing synthesis time are  particularly apparent  when making small changes  to large designs but reduced  benefits can still accrue with larger changes on smaller designs.  If your synthesis time is greater than 10 minutes then you should try incremental synthesis. If you don't like the way of working, or simply don't get good results then revert back to synthesis of the whole design.

Using incremental synthesis to maintain logic structures has benefits where synthesis bugs are causing problems or where timing is difficult to meet. Synthesis bugs can be time consuming to find. Often the are related to a particular style of describing a function in VHDL or Verilog but can appear or disappear with environmental parameters. Changed a synthesis timing constraint or tool switch is often enough to make a difference.

Where logic timing is the problem the benefits of incremental synthesis come by repeating the logic structure over many builds. This can be done as a soft macro and using guiding to repeat designs. Alternatively using semi-hard placement constraints you can generate a RPM (Relationally Placed Macro) and enables you to repeat modules (macros) over many designs.  By  repeating, or maintaining, your good logic and hence timing, your rebuilds don't introduce new timing problems. This leaves you free to concentrate on other modules that have timing or logic problems.

Where you have a synthesiser bug the incremental approach allows you to work on a smaller sub-part of a design making a bug faster and easier to find. When you find a fix to the problem you can then freeze that part of the design as a soft macro (EDIF or NGC netlist) or you can go to further and generate a RPM to preserve timing and relative logic placement. You will simply then not do anything to the module and drag it onto the design during the backend build.

We are going to outline two methods of incremental synthesis aimed at a cheap and cheerful approach to the problem. Both methods assume a hierarchical approach to your design with the incremental synthesis being applied at block, or module, level. This type incremental synthesis is not as sophisticated as those in available in the leading tools which can apply incremental synthesis at a finer level. However you do pay lots of money for these tools. Individual tools also don't tend to support breaking out modules for synthesis by their competitor tools. This is something you can consider doing with the second method described in this article.

The first method described in this article is purely a Xilinx design flow although similar types of switch controlled incremental synthesis is  offered in competitor tools and third party synthesizers. The second method can be applied to the back end tools of most vendors but is described as Xilinx backend design flow. Synthesis for second method can done by any technology supporting synthesizer or even by multiple synthesizers. In both methods the flow described is based on VHDL source files and Xilinx ISE toolset version 6.1 SP3 but it would be applicable to Verilog or mixed source flows. A zip of the source and ISE project setup is here. Please view the included readme file for directory structure instructions.

The article will not cover constraints and guide files as applied to place and route, or the the generation of RPMs. These topics are related but are beyond the scope of this article. We are hoping to cover these a future TechiTips. We should also say that in some designs incremental synthesis is not always the best answer to solving a particular design issue and other methods should always be considered.

Method1 - Using XST Incremental Synthesis

XST has supported block incremental synthesis in many versions. This feature is not to be confused with modular design which is a tool add-on aimed at group based designs. Sometimes this feature of XST has been selectable in the GUI interface of ISE but this not the case for recent editions of ISE.

This synthesis option is still there but is now only accessible via VHDL or Verilog attributes or as we are about discuss via the XST constraints file. Xilinx documentation of the feature is available in the user guide for XST (xst.pdf) and the Constraints Guide (csg.pdf). These documents are available on the Xilinx website and also usually come with paid for versions of ISE tools.

There are some limitations of this synthesis flow. The first limitation is that only families Xirtex (Spartan 2) or later are supported. This usually isn't an issue as most designers are already using these device families. The second, more significant, issue is that incremental synthesis of designs with multiple instantiations of a module won't work . This limitation is listed in the Xilinx documentation. You can work around this by making copies of appropriate modules changing the file and entity names as you copy. However rather than doing this work around, and coping with management thereafter of design changes, you may wish to use the second method listed in this article

Stage1 - Create The Synthesis Constraints File

In the sources window select the top VHDL module and using the right mouse key select new source. Please note the inclusion of the new source in the project is merely for convenience and is not significant at this stage.

Select a user file and give the file a name with an extension of "xcf". In our demo the file is called "TOP.XCF" .

Add the "INCREMENTAL_SYNTHESIS" attributes for all of the modules. Note that this operates on the entity names and not the file names.

Save the XCF file. The next stage is tell XST that it has a synthesis constraints file. First select the top VHDL file. Then in the process window  of XST select the synthesis  process with a right mouse key and further select the properties menu
.

Under the "SYNTHESIS OPTIONS"  tab ensure that "KEEP HIERARCHY" is set to YES. Also set the "SYNTHESIS CONSTRAINTS FILE" is set to point at your XCF file.

Please note that the Xilinx documentation recommends that you delete the NCF files in your design if you have previous runs without increment synthesis active or if the decomposition of the design has changed.

You are now ready try a build. If you use our design files you can cause a re-synthesis by changing the "RELOAD_VALUE" constant in any of the files. If you run synthesis twice look at the  changes in the synthesis report "demo_top.syn" .Change one of the "RELOAD_VALUE" constants and re-run synthesis again. Now look at the new synthesis report to see the change in the flow. Once you are happy with the flow make a copy of your own design and try the approach on your tryout copy.

This is a very simple increment synthesis flow which can save you time but you must use it with a little care. In addition to the limitations listed above you need to be careful when changing timing constraints. If you need to change timing constraints you will may need to force a re-synthesis by adding "RESYNTHESIS" attributes to  the XCF file. The capture below shows resynthesis constraints being added to our XCF file.

Method 2 - Knitting Modules Together At The Backend

Advisory

The mapping option for trimming logic was changed in functionality between ISE 5.2 and ISE 6.1 follow this link here for more information. This will be of particular interest those who wish to create hard macros (RPMs).

Approach

This approach is a bottom up, or a restart from bottom approach. The nice bits of this approach are that you can effective freeze the synthesis of as many parts of design as you like. This approach is also useful where a module is used several designs where it can be used over and over again without re-synthesising the module. This lead to approve the module approach and can reduce overall design debug and design proving times in multi-design usage.

Essentially the aim of this approach is to break down a design into modules.  This can done naturally at a single file level but can also be done as a hierarchial level including all elements below a given file level. The technique can also be used successively to build up a working module starting from the bottom level. The amount that a designer will include in a module should be dictated by the difficulty and structure of their design. If, for instance, a particular hierarchy is used many times within a design then that level would be a sensible level to use as a working module. If your design is more splintered then your may have to do a try and see approach to the level of hierarchy used as a module.  Experience will make you better at judging where to start.

First we are going to describe how to set up XST to correctly generate a NGC file, the equivalent of importing an EDIF from another external synthesizer. Then we will go through the process of how to use a combination of  EDIF and NGC files to build the final design. We are not going to cover the subject of hard macros (RPMs) in this article you may wish to look up the Xilinx documentation of "S" (save) constraints. The zip available will contain 3 UCF files as a way to implement "S" constraints and an alternative way is also shown in file DEM03_WITH_S_CONSTRAINTS.VHD. You may also wish to look at application notes xapp416, xapp418, xapp422 on the Xilinx website.

XST Synthesis

Using the ISE GUI we can drag all of our VHDL sub-module sources into the project at one time. It has some convenience of the XST setting are at a project level and not file level. That is what we are about do apples to all synthesis runs on these modules. Having added all our sources from our reference design you should see the sources window look like this.

ISE has a feature where what is selected in the sources window then acts the top level for the tool flow as shown in the process window. This can real annoy you when do a long build with the wrong top level selected. However in our case in might be seen as useful. Select the file that is going to be the top level for first module generation. In our case we have selected "DEMO1" as our first module.

First we are going to check that our bus notation is going to follow our standard. This is important especially where we are using multiple synthesizers although there are some switches in ISE that can help in this respect too. We are not going to discuss these switches today but go for "standard" approach. Our usual standard is curvy brackets. We start my selecting the XST properties by a right mouse click on "synthesis" in the process window as shown below.

Selecting the "SYNTHESIS OPTIONS" tab and going down the list of the properties we come to the bus notation selection "BUS DELIMITER". We pull down the options and select what we want.

Next ensure that the "ADD I/O" BUFFERS" option located in the "XILINX SPECIFIC OPTIONS" tab, of  synthesis properties is  not ticked.  As this is a lower module without  direct outside connection we need to ensure that no I/O buffers are  inserted by the synthesizer.  As above you can enter the synthesis  properties by a right mouse click on the synthesis heading.

Also worth doing sometimes is to ensure that hierarchy is preserved. This is found in "SYNTHESIS OPTIONS" tab of  "SYNTHESIS OPTIONS".

You can now run XST by double clicking on synthesis in the process window.

Once the synthesis is complete you will have  a NGC file  DEMO1 that can be used  as a soft macro.  Select DEMO2.VHD, then left mouse double click on synthesis and XST will synthesize DEMO2. Repeat for DEMO3 if you want a source for it.

If you are running another synthesizer check the documentation for how not to insert I/O buffers and how to set up bus notation as you want. We are now ready to build the final design.

Final Build

For the purposes of this article we are going to use 3 source types for our build. The first of these is our top level VHDL file DEMO_TOP.VHD. XST will synthesize this file whilst the other modules will be pulled in at the TRANSLATE process. DEMO1 and DEMO2 will be supplied to the project as the NGC files we generated earlier. DEMO3 is supplied as an EDIF file. This EDIF was generated by Leonardo Spectrum. We start by creating a new project with only  DEMO_TOP.VHD shown as a source.

First ensure that the I/O buffer insertion is back on. As before a right mouse key on the "SYNTHESIS" process to select properties and then find  the  "ADD I/O" BUFFERS" option located in the "XILINX SPECIFIC OPTIONS" tab.

Next we manually create a directory called MACROS, using a windows file manager, and place the NGC and EDIF files into that directory. We now need to set up the macro path where the TRANSLATE tool looks for macros. Selecting TRANSLATE in the PROCESS window with a right mouse key and choosing properties we get a menu like this.

You can navigate to the macro directory or simply type it in. Once you have done that you are ready to go. Double click on "GENERATE BIT FILE" and ISE will run through the whole flow; synthesizing the top level, building in the soft macros, then place and route, and finally the generation of the bit file.

 In this demonstration we have not paid any attention to timing or the actual results but leave this for you to play with. We have not done interruption after interruption of module improvement that may occur in the real design cycles.

Disclaimer