Design implementation: synthesis

Once the design is made FPGA-ready, on the assumption that it fits into a single FPGA then we can move on to FPGA implementation, which as we saw in chapter 3, is comprised of synthesis and place and route (we shall deal in the next chapter about partitioning into multiple FPGAs, should that be necessary).

To recap, FPGA synthesis primarily compiles the RTL, checks for synthesis errors, accepts implementation constraints and generates FPGA netlists that are forwarded to the place & route tools along with further constraints.

To prepare our FPGA-ready design for synthesis, we must also enter the implementation constraints. These can be entered either in the design RTL itself or in the synthesis constraints files that can either be created directly by the user or by using a GUI provided by some tools.

The following are the most common implementation constraints:

• Device properties: these basic constraints direct the synthesis and subsequently the place & route tools to the FPGA family, specific device, speed grade and physical package.

• Pin locations and properties: this constraint maps each logical IO pin to a physical FPGA pin. The selection of pins is usually related to the prototyping platform architecture. If pin locations are not locked at this time then the pin assignment will change in subsequent synthesis runs and the design will not work in the FPGA. In addition to the physical pin location, we can specify IO properties such as signaling levels, slew rate, drive strengths etc.

• Timing constraints: this type of constraint is one of the most critical to the success of the prototyping effort. These constraints drive the synthesis and are passed on to the place & route tools to drive each towards the desired timing, balancing resource utilization and implementation effort. Timing constraints are usually entered in a synthesis constraints file, either manually or by using a GUI. Effective timing constraints will guide the implementation tools to put the effort where it is most needed. The most common timing constraints are: clock period, from/to delays, and multicycle paths.

• Other constraints: there are many other constraints and attributes that guide the synthesis and place & route tools, such as synthesis styles, state machine implementation styles etc. Good knowledge of the available attributes and how to apply them will help us to best leverage the tool and device capabilities to meet our prototyping goals.

Note: using existing constraints for the SoC design

In some cases the timing constraints for the original SoC design might be reusable to some degree in the FPGA-based prototyping flow. SoC synthesis tools, such as Design Compiler® (DC), will usually be configured in their project scripts to perform a bottom-up synthesis and so constraints are applied at each block level. However, there may often be top-level constraints which give at least the IO constraints for the device. There may even be a top-down flow employed in smaller designs, in which case the top-level timing constraints may be all that are available. In either case, the constraints will usually be written in a format called standard design constraint or SDC for short.

Advanced FPGA synthesis tools can make use of common timing constraints in the SDC format, thus allowing direct reuse of the same SoC constraints for the FPGAs in the prototype.

As an example, the following common design constrains are supported in Synopsys FPGA synthesis tools:

create_clock

create_generated_clock

set_clock_groups

set_input_delay

set_output_delay

set_false_path

set_multicycle_path

set_max_delay

These are the common set of timing constraints used in SoC designs and are fairly self explanatory from their names. Other unsupported constraints should either be manually translated (if a corresponding constraint is present in the FPGA synthesis tools) or ignored, depending upon importance. The tool documentation will give guidelines of the level of SDC support provided.

The SoC SDC will usually include much more than top-level timing constraints, for example “report” generation commands. Typically these are not directly supported or have a different syntax in the FPGA tools, so equivalent reports must be generated by using the timing analyzer capability within the FPGA synthesis and place & route tools manually.

To use the SDC timing constraints for FPGA synthesis in Synopsys FPGA synthesis tools, we need to take care of the naming rules employed. Names may change or be ambiguous between different tools, so some mismatch might occur between common naming conventions. All naming rules are configurable in Design Compiler and there are a wide variety of styles adopted by different SoC teams. For example, in the notation of hierarchy separators, naming of bus signals, multidimensional arrays, structures, records and generated signals and identifiers. If the naming conventions in the Design Compiler SDC do not match the default naming conventions followed in the FPGA synthesis tools, then we can explicitly add the appropriate command specifying the naming conventions in the beginning of the SDC file.

Tuning constraints

Tools will often have a constraint checker to allow a quick-pass analysis of coverage and legality of the constraints before running synthesis or place & route. The results are presented in a report which provides information on how the constraints will be interpreted by the tool, without having to wait for the tool to complete a full run. Based on the report, we can quickly edit the constraint file rather than wade through messages in a synthesis log file, which might run into many thousands of lines.

When synthesis is complete, the tools will provide reports giving details of utilization and estimated timing. These reports can give an early warning of design issues such as inter-FPGA critical paths, unexpected utilization levels and missing components. Although all timing is based only on estimates, synthesis reports should be carefully examined before proceeding to the place & route process as the design or constraints that may need to be modified. To ease this process, the reports can be examined automatically, either using the tool’s built-in report features or using scripts which search and manipulate the report files directly.

TABLE OF CONTENTS

Note: using existing constraints for the SoC design

Tuning constraints