TestH1

The AMD Vivado Tool Suite is used for the hardware development of AMD FPGAs, as well as AMD Adaptive SoC technologies.
The project-based design flow is recommended for development, as it is based on centralized project and database management, making it more convenient and, therefore, highly productive for development.
The traditional FPGA design flow defines:

• Source file management
  HDL source files
  Constraining files

• Compiler
  Synthesis compiler
  Simulation compiler
  Place & route compiler
  (called Implementation in Vivado)

• Other tools:
  BIT file generator
  Flash programmer
  IP manager and packager
  Analysis tools
  Debug tools
  Report tools

*)
HDL: Hardware Description Language
AMD Vivado: VHDL and Verilogy
Note: The current standard includes System Verilog in Verilog.

And for the source file management, these three groups are distinguished in the Vivado tool suite (RTL project type):

• HDL files for synthesis
• HDL files for simulation
• Constraints files for synthesis and/or for implementation

The place-and-route executables are defined in Vivado running in one database context called >Implementation<. Even if there are different software tools available for design entry, both integral with Vivado and third-party tools, such as from Synopsys, Cadence, Mentor, Aldec, Mathworks and others, they always generate HDL source files types for these three groups.

The HDL language support for simulation source are VHDL and Verilog, including System Verilog. The language support for synthesis source files are HDL files with VHDL, Verilog, and System Verilog, and additional constraint files. The synthesis compiler, in turn, can control the optimization task in great detail with global and local settings. The global settings are defined from project settings and local optimizations are assigned in constraint files. And that is what this blog is about!

Why are constraints relevant for the synthesis compiler but not for the simulation compiler?

The execution of the simulation corresponds to the need for an objective validation methodology. In this respect, local compiler settings do not play a role here. The HDL code is also executed equentially by the compiler. Not so with the synthesis compiler. Its task is to OPTIMALLY map an HDL description to the target technology, specifically to map it to primitive cells. But this ability is also proprietary to the tool and technology! And that means that there are many HDL behavior descriptions that are not supported by the compiler when ›inferring‹, since there are no standardizations within the HDL language standards, such as the definition and capabilities of clocks. There is no objective optimum of the compilation: The challenge lies with the developer, who, with knowledge of the possible methods, implements an iterative process of optimization including user constraints. The greater the effort and knowledge, the better the chance of improvement for performances, utilization or power consumption (QoR management).

In this context, IP libraries play an important role: Here, the technology partner such as AMD provides an already optimized IP catalog. And many case distinctions have already been made methodically and can be activated via dialog parameters or automatically assigned project settings. Constraints are divided methodically how these can be applied for the synthesis compiler run. The Vivado synthesis constraints can be used in four different ways:

• HDL attributes
Synthesis attributes in VHDL and Verilog

• Constraints files [.xdc .sdc]
  Classic methodology

• Setting constraints via TCL files
Particularly preferably used for AMD IP generations.

• Constraints embedded in netlists
Very common in Vivado .dcp netlist files

 
These rules can differ significantly with the synthesis tools; changes to these rules can also appear in release versions. And even if the target technology changes (technology migration), the constraint rules might differ and must be manually reviewed and adjusted. HDL attributes of the Vivado synthesis compiler are listed in the ›HDL Attributes‹ section of the AMD User Guide UG901: ›Vivado Design Suite User Guide: Synthesis‹. And constraints syntax in applications via constraints files (.xdc) are documented in AMD User Guide UG903: ›Vivado Design Suite User Guide: Using Constraints‹.
 
The next important distinction of synthesis constraints are:
 

• physical constraints
• timing constraints

Physical Constraints

Why are physical constraints necessary? HDL languages such as VHDL and Verilog are hardware description languages and not hardware synthesis languages! This is why additional constraints are required and many such rules were largely defined more than 40 years ago by Synopsys for ASIC synthesis and later also for FPGA synthesis. Physical constraints are optimization and mapping constraints that influence and control the quality of netlist generation. The expectation of better default compilation, without the user having to apply such user constraints ultimately, would lead to unaccepted prolonged compilation times. However, since this is critical, the vendor partner still defines the best optimization capability of the compiler with the assistence of the developer himself, namely by applying such constraints.
 

In this way, the trade-off between area optimization and performance optimization can ultimately be better controlled by the developer, since he knows the design even better. In particular, he knows the dynamic use case, while the compiler only compiles according to static rules. For example, a throughput rate in the HDL code cannot be determined by the static compiler. If a 1-bit buffer is described in the HDL code, there are many options for which type of buffer can be selected. The type of RAM can also be controlled, such as a distributed RAM, BlockRAM or UltraRAM cell type. The definition of I/O pins, the selection of a PLL in a quadrant, the placement of cells in the FPGA topology, all of these are examples of physical constraints.
 

In Vivado, setting the constraints in so-called file sets is defined in the project mode. And a predefined file set here is called ›constr_1‹. Within, multiple constraint files can be included and the project flow uses this specification across all synthesis and implementation processes which makes it much more easy compared to the Vivado non-project mode. This heavily simplifies the constraint management for the user. But further differentiation in constraining is possible, if needed. It is recommended to define several constraints files for different purposes (i.e. io_constraints.xdc, debug_constraints.xdc, further_improvements.xdc).

Timing Constraints

The need for timing constraints is explained here again by the HDL languages, which as hardware description languages do not guarantee that the compiled design would be real-time capable and therefore reliable. For FPGA technologies, support for timing constraints was only introduced later; i.e. timing constraints were in those yeary only a requirement for the place-and-route compiler run. Today, the synthesis compiler is also expected to drive the QoR based on timing constraints namely the real-time specification. If this is met, as this is true for the AMD Vivado synthesis compiler, it is referred to as a timing-driven compiler.
 

The syntactical basis of the Vivado constraints were introduced by Synopsys, so that Synopsys constraints files (.sdc) are still supported using Vivado. But Xilinx entended the API of constraining while the constraint file type (.xdc) is the default type in Vivado. And since the quality of a compilation is influenced most by the first sequential compilation, the influence of such constraints can have a serious impact. However, it is still possible today to compile the synthesis without timing constraints and only include such constraints in the place-&-route run (implementation). If the compiler offers timing-driven synthesis, as is the case for Vivado synthesis, it is generally very sensible to incorporate the management of timing constraints at an early stage of development. There are different strategies here, which also have to be weighed up in the trade-off between compilation time and quality. For example, synthesis can compile the HDL synthesis project in one process, so that the linking of the file modules is also done, or each individual file can be synthesized separately or in groups of files. These methods are referred to as Out-Of-Context (OOC) in Vivado. The question that arises is whether constraint management should also be related netlist individual (OOC). This additional effort is usually avoided, but this means that the timing-driven quality might really differ relevant. This lack is often ignored, especially in the Vivado project-based flow, because the same user constraints in the implementation after synthesis now have an objective global effect, since the OOC compilations only take place in the synthesis.
 

And in this respect, after implementation, timing constraint training is globally effective, while OOC intermediate results do not necessarily have to meet this requirement. This is the trade-off between run-time and Quality of Result (QoR). It is important to note that the developer himself must master the timing constraints management as well as the analysis in the sense that he must provide proof of the real-time capability of his design with the compilation and not the tool vendor.