Programmable integrated circuits (ICs) are often used to implement digital logic operations according to user configurable input.  Example programmable ICs include complex programmable logic devices (CPLDs) and field programmable gate arrays (FPGAs).  CPLDs often include several function blocks that are based on a programmable logic array (PLA) architecture with sum-of-products logic.  A configurable interconnect matrix transmits signals between the function blocks. 
An example FPGA includes an array of configurable logic blocks (CLBs) and a ring or columns of programmable input/output blocks (IOBs).  The CLBs and IOBs are interconnected by a programmable interconnect structure (routing resources).  The CLBs, IOBs, and interconnect structure are typically programmed by loading configuration data (“configuration bitstream”) into internal configuration memory cells.  The state of the configuration memory cells determines the function of the CLBs, IOBs, and interconnect structure.  The configuration bitstream may be read from an external memory, such as an EEPROM, EPROM, PROM and the like, though other types of memory may be used. 
A typical design process begins with the creation of a circuit design.  The circuit design specifies the function of a circuit at a schematic or logic level and may be represented using various hardware description languages (e.g., VHDL, ABEL, or Verilog) or schematic capture programs.  The design is synthesized to produce a logical network list (“netlist”), and the synthesized design is mapped onto primitive components within the target device (e.g., programmable logic blocks of an FPGA). 
Following mapping, placement of the components of the synthesized and mapped design is performed for the target device.  During placement, each mapped component of the design is assigned to a physical position on the device.  The placer attempts to place connected design objects in close physical proximity to one another in order to conserve space and increase the probability that the required interconnections between components will be successfully completed by the router.  Placing connected components close to one another also generally improves the performance of the circuit since long interconnect paths are associated with excess capacitance and resistance, resulting in longer delays and greater power consumption.  The timing and resource requirements of a circuit are specified as design constraints in a design constraints language.  The circuits are placed and routed using the design constraints to ensure that requirements specified by the design constraints are satisfied in the placed and routed design.  Design constraints may be applied to various objects of a circuit design (e.g., cell instances, nets, etc) to indicate various parameters to be applied during placement and routing of the objects.  For ease of reference, the value of a parameter indicated by a constraint may be referred to as a constraint value.  When a design constraint is applied to one or more objects of a circuit design, the design constraint is stored and associated with each of the one or more objects.  When the circuit design is placed and routed, the stored design constraint is retrieved and used to direct placement and routing of the one or more objects to satisfy the design constraint. 
Design constraints may be input as command line input, entries in source files, or through a graphical user interface.  Design constraints may have different formats depending on the design tool that is used for placement and routing.  In some implementations, design constraints may be formatted as entries that indicate placement and routing parameters and sets of objects to which each parameter is to be applied.  In some other implementations, design constraints may be formatted as executable instructions that cause the design tool to set parameters of objects indicated by the executable command.  Moreover, an input design constraint may include a pattern that identifies several objects to which a constraint is to be applied.  For instance, a pattern may be used with a get_cells command to retrieve all cells of a circuit design that match the pattern.  For example, the wildcard character “*” matches any sequence of characters, and the character “?”  matches any single character.  A syntax known as regular expressions can also be used to match the names of many objects.  Another example of a pattern is the option -filter {direction==input}, which may be used with a get_cells command to exclude certain cells matching a pattern from a retrieved set.  In fact, a pattern may be a combination of -filter options and wildcard expressions or regular expressions.  For example,                add_cells_to_pblock pblock—1 [get_cells ABC*]        
creates a constraint for pblock—1 for each of the cells of a circuit design that match the pattern “ABC*”.  For instance, if the design contains 1000 cells with the names ABC1, ABC2, ABC3, . . .  ABC1000, then this single command creates 1000 constraints. 
In many development situations, it may be desirable to export design constraints that have been applied to objects of a circuit design.  For example, during development it may be desirable to save a list of design constraints applied to a circuit design for use as a restore point.  As another example, a circuit developed by one development team may be incorporated as a sub-circuit cell in a larger circuit design.  However, such development must be properly coordinated between the teams so that all of the sub-circuit cells are placed and routed to meet various requirements of the respective sub-circuits such as timing requirements, resource requirements, etc.  In incorporating the circuit into the larger design, design constraints applied to the circuit to be incorporated should also be applied in the larger design to ensure that the circuit operates under its expected parameters. 
In one approach, software is used to expand all the patterns to create individual constraints for each cell of the circuit design that matches a pattern.  The individual constraints may be directly exported and saved to a constraints file.  However, this approach can increase the size of the constraints file by many times.  Such a large file may be inconvenient for the user to examine and edit.  Further, the file may take a long time for the software to read and interpret.  Moreover, users generally prefer to see constraints specified in a similar syntax to the original pattern.