The following sections provide information on adding constraints to HDL designs.
Foundation Express users have access to the Express Constraints Editor. The Express Constraints Editor includes a window with five different tabs. The following three tabs represent constraints that can be applied to the design prior to synthesis: Clock, Paths, and Ports.
The timing constraints specified in the Express Constraints Editor tabs are translated into FROM:TO timespecs and placed in the XNF file Express outputs. Following is an example:
SYM, TS0, TIMESPEC, TS0=from:pads:to:tgrp_0_D
FF=40ns, LIBVER=2.0.0
ENDCurrently, Express cannot apply all Xilinx constraints to a netlist.
Express can apply the following constraints:
Express cannot apply the constraints listed below:
Express can create its own timegroups by grouping logic with common clocks and clock enables. In addition, you can form user-created timing subgroups by right clicking on an existing timing path and choosing New Sub Path.
For constraints that cannot be applied using the Express Constraint Editor, a UCF file can be used to specify logical constraints. Constraints or attributes that can be applied within a schematic, netlist, or UCF file are known as logical constraints. Logical constraints ignore timing paths, prohibit pin locations, or constrain placement of elements in an FPGA or CPLD design. In order to use a logical constraint correctly, the “instance” name of the logic in a design must be used. Instance names are XNF SYM record names, XNF SIG record names, XNF net names, and EXT record names. For examples of reading these instance names out of a XNF file from Express, refer to the following figure.
Figure 6.5 XNF example |  |
In the preceding figure, the SYM record name can be referenced by a logical constraint by using the instance name, current_state_reg<4>. A net called N10 or current_state<4> can also be used in a logical constraint. EXT records correspond to pins used on a package. The EXT records named CLK, DATA, and SYNCFLG can be referenced in a pin locking constraint.
For more information on Xilinx constraints, refer to the “Attributes, Constraints, and Carry Logic” chapter in the Libraries Guide.
UCF constraints are applied by referencing instance names that are found in the XNF file. Instance names for logic in a design can be found by reading the XNF file. Refer to XNF syntax in the “XNF example” figure for the examples in this section. The following examples illustrate valid entries within a UCF file.
A final note on referencing instance names from a XNF file: match the case; names are case-sensitive. If the case of names in the XNF file is not followed exactly, the implementation software may not be able to find (or may incorrectly find) an instance name for a constraint.
In the Foundation Express methodology, whenever large blocks of RAM/ROM are needed, LogiBLOX RAM/ROM modules should be instantiated by the user in the HDL code. With LogiBLOX RAM/ROM modules instantiated in the HDL code, timing and/or placement constraints on these RAM/ROM modules and the RAM/ROM primitives that comprise these modules, are specified in a .ucf file.
To create timing and/or placement constraints for RAM/ROM LogiBLOX modules, you must know how many primitives are used and how the primitives inside the RAM/ROM LogiBLOX modules are named.
When a RAM/ROM is specified with LogiBLOX, the RAM/ROM depth and width are specified. If the RAM/ROM depth is divisible by 32, then 32x1 primitives are used. If the RAM/ROM depth is not divisible by 32, then 16x1 primitives are used instead. In the case of dual-port RAMs, 16x1 primitives are always used. Based on whether 32x1 or 16x1 primitives are used, the number of RAM/ROMs primitives can be calculated.
For example, if a RAM48x4 was required for a design, RAM16x1 primitives would be used. Based on the width, there would be four banks of RAM16x1's. Based on the depth, each bank would have three RAM16x1's.
Using the example of a RAM48x4, the RAM primitives inside the LogiBLOX would be named as follows:
MEM0_0 MEM1_0 MEM2_0 MEM3_0
MEM0_1 MEM1_1 MEM2_1 MEM3_1
MEM0_2 MEM1_2 MEM2_2 MEM3_2
Each primitive in a LogiBLOX RAM/ROM module has an instance name of MEMx_y, where y represents the primitive position in the bank of memory, and where x represents the bit position of the RAM/ROM output.
This section is written in terms of the Verilog example, using the files illustrated in Figures 6-6 through 6-9. This section also applies to the VHDL example in Figures 6-10 through 6-13. For information on compiling these examples, see the “Black Box Instantiation” chapter of the Foundation Express Application Note Supplement, January 1998, 0401721.
LogiBLOX RAM/ROM modules in an HDL Flow project are constrained using a UCF file.
LogiBLOX RAM/ROM modules instantiated in the HDL code can be referenced by the complete hierarchical instance name. If a LogiBLOX RAM/ROM module is at the top-level of the HDL code, then the instance name of the LogiBLOX RAM/ROM module is just the instantiated instance name. In the case of a LogiBLOX RAM/ROM that is instantiated within the hierarchy of the design, the instance name of the LogiBLOX RAM/ROM module is the full hierarchical path to the LogiBLOX RAM/ROM. The hierarchy level names are listed from the top level down and are separated by a "_".
In the Verilog example, the RAM32X1S is named "memory". The memory module is instantiated in the Verilog module "inside" with an instance name "U1". "inside" is instantiated in the top-level module "test" with an instance name "U0". Therefore, the RAM32X1S can be referenced in a UCF file as "U0_U1". For example, to attach a TNM to this block of RAM, the following line could be used in the UCF file:
INST “U0_U1” TNM=block1;
Since U0_U1 is composed of two RAM primitives, a timegroup called block1 is created; the block1 TNM can be used throughout the UCF file as a timespec end/start point, and/or U0_U1 could have a LOC area constraint applied to it. If the RAM32X1S has been instantiated in the top-level file and the instance name used in the instantiation is U1, then this block of RAM can just be referenced by U1.
Sometimes it is necessary to apply constraints to the primitives that compose the LogiBLOX RAM/ROM module. For example, if you choose a floorplanning strategy to implement your design, it may be necessary to apply LOC constraints to one or more primitives inside a LogiBLOX RAM/ROM module. Consider the RAM32X2S example. Suppose that each of the RAM primitives needs to be constrained to a particular CLB location.
Based on the rules for determining the MEMx_y instance names, using the example from above, each of the RAM primitives can be referenced by concatenating the full-hierarchical name to each of the MEMx_y names. The RAM32x2S created by LogiBLOX will have primitives named MEM0_0 and MEM1_0. So, CLB constraints in a .ucf file for each of these two items would be:
INST “U0_U1/MEM0_0” LOC=CLB_R10C10;
INST “U0_U1/MEM0_1” LOC=CLB_R11C11;
In the following figure, the LogiBLOX module is contained in the “inside UO” component.
Figure 6.6 Top-level Verilog File | |
The following figure illustrates the instantiated LogiBLOX module, “memory U1”.
Figure 6.7 Verilog File with Instantiated LogiBLOX Module | |
When the LogiBLOX module is created, a .vei file is created, which is used as an instantiation reference.
Figure 6.8 VEI File Created by LogiBLOX | |
Figure 6.9 UCF File for Verilog Example | |
Figure 6.10 Top-level VHDL Example File | |
Figure 6.11 VHDL File with Instantiated LogiBLOX Module | |
Figure 6.12 .VHI File Created By LogiBLOX | |
Figure 6.13 UCF File for VHDL Example | |
