GCL Overview

The General Constraint Language (GCL), is an open standard under development by SC-WG. GCL is intended to address the problem of initial constraint entry at the point in the design process where a register-transfer level (RTL) description of a portion of the design is available.

GCL is primarily focused on the types of constraints and boundary conditions which are required for RTL->gate level synthesis. Many of these constraints are also useful for other types of tools, such as estimators, cycle simulators, floorplanners, placers, and routers. A complete table of contents for the full GCL specification is available here . The current draft does not yet cover all of the sections listed in the table of contents.

GCL supports specifying constraints on both the design as a whole, and on various portions of the design. Not all parts of the design will necessarily be described using synthesizable RTL. For example, a hard macro implementing a memory usually is not synthesized. However, it may be useful to specify constraints for non-synthesized parts of the design, in order to control module generators or automatic selection from several different implementations of a complex macro.

GCL is a constraint entry language which is intended to match the RTL description of the design. It includes a number of macro operators and pattern-matching capabilities which make it easier for a designer to describe the intended the performance of the design. As a command language, the format is also relatively free-form: unrelated constraint commands may appear in any order and consecutive commands may refer to very different parts of the design. These features make it relatively complex for a tool to support GCL.

GCL versus GCF

The General Constraint Format (GCF) is a constraint interchange language which is intended to match the gate-level description of the design. It is a much more restricted format designed to make it relatively easy for a tool to support. The distinction between the RTL description and the gate-level description of a design is an important one. Often a designer will modify the hierarchy of the RTL description during the course of synthesis, which introduces changes in the names which must be used to refer to particular elements in the design. The synthesis tool, because it is responsible for modifying the hierarchy, will usually take care of preserving the constraints on design elements as those elements are moved from one portion of the hierarchy to another. However, it would be relatively difficult for other tools to relate the pre-synthesis constraints to the gate-level netlist.

We expect GCL to be read by synthesizers, estimators, high level floorplanners, module generators, and cycle simulators. It may also be used by other tools such as timing analyzers, in order to handle mixed-level designs where some portions are RTL which has not yet been synthesized, and other portions are at the gate-level. Synthesis tools are expected to bridge the gap between the RTL description and the gate-level description by writing the constraints in GCF form. We expect GCF to be read by gate-level timing analyzers, detailed floorplanners, placers, routers, delay calculators, and incremental logic optimization tools.

GCL versus Extension Languages

GCL is not intended to be used as an extension language. It is a simple command language, with a precisely defined syntax and semantics for a finite number of commands and their options. Extension languages are typically used in tools to provide users with a sophisticated programming environment, including variables, flow of control constructs (such as if-then-else, for, while), functions, operating system interfaces, and direct interfaces to various tool capabilities. This kind of programming environment, while very powerful, tends to be very tool-specific. There have been attempts in the past to develop a standard extension language (Scheme), which met with limited acceptance.

The relationship between GCL and the particular extension language used in a given tool is not defined by this standard. However, we expect that a common use will be for a designer to enter GCL commands into one or more standalone files. Then, in the extension language script used to control the flow of operations in the tool, the user would issue a tool-specific command to read the GCL file and apply the constraints described in that file to a particular part of the design.

This approach intentionally separates the commands used to describe constraints (design-specific information) from the extension language and commands used to control the tool (tool-specific information). The purpose of this separation is to provide portability for the constraints across multiple tools, and to facilitate adoption of GCL. Instead of requiring tool vendors to implement a whole new (and probably incompatible) programming environment, we just require that they be able to read a command file. By providing a reference parser for that command file, we can make it even easier for a vendor to implement support for GCL.