How it Works - Configurations and Constraint Files
All of the three classes of constraints described above are implemented as constraints within constraint files. Constraint filescan contain any number of different constraints, for any of the classes mentioned above. To ensure the most portable FPGA design, the most logical approach is to break the constraints into these three classes and store these in separate constraint files.
Sets of constraint files are targeted to a design by creating a configuration, which is simply a named list of constraint files. For example, consider an FPGA project that is targeted to:
- a Xilinx Spartan-XC2S300E QFP208 on a NanoBoard
- an Altera Cyclone QFP240 on a NanoBoard
- and a Xilinx Spartan-XC2S100E QFP144 on the user's own board design.
This would require three configurations – one for each target.
Assuming good design practice (from a portability perspective) this would theoretically require seven constraint files – separate constraint files to control the pin-outs for each of the three devices in their target boards, separate constraint files to control any internal place and route constraints for each of the three target devices, and one constraint file for logical design constraints. If there were no place and route constraints (which would usually be the case), then there would only be four constraint files.
Each configuration would then include three constraint files, two which are specific to the configuration and one which is common to all configurations.
If there were constraints that were common to the two different Xilinx devices (which are internally very similar) then it may be beneficial to create a constraint file for these. In this case, the extra constraint file would be added to two of the configurations.
Diagrams of these Configurations and their Constraint Files
Figure 1 shows the relationships between the constraint files and the configurations.
Figure 1. A single set of schematic and VHDL source documents, targeted to three different implementations by different sets of constraint files.
The actual setups for each of the three configurations are as follows:
For the Spartan 2E300 on the NanoBoard
Figure 2. Design targeting a Xilinx Spartan2E 300, on the NanoBoard.
For the Cyclone EP1C12 on the NanoBoard
Figure 3. Design targeting an Altera Cyclone EP1C12, on the NanoBoard.
For the Spartan 2E100 on a User Board
Figure 4. Design targeting a Xilinx Spartan2E 100, on a User Board.