^

AR# 29313 MIG v2.0, v2.1, v2.2, v2.3 - When changing a MIG-generated Virtex-5 FPGA DDR2 SDRAM pin-out, both the UCF and top-level HDL parameters MUST be updated

Keywords: MIG, 2.0. 2.1, 2.2, 2.3, update, design, UCF, pin-out, DQS_IO_COL, DQ_IO_MS, ERROR:Place:292, DIRT, Directed Routing, RLOC_ORIGIN

NOTE: Starting with MIG v3.0, only the DQS gate constraints noted in this Answer Record are required. The 11.1 MAP/PAR tools use a "Predictable IP" algorithm to properly place the MIG design. Updating to MIG 3.0 is highly recommended. Please see the MIG User Guide for full details on the constraints/parameters required in MIG 3.0 rather than referring to this Answer Record.

Starting with MIG v2.0, the Virtex-5 FPGA DDR2 SDRAM design requires a large number of UCF constraints whose values are dependent on the specific pinout of the DQ and DQS bits. In addition, there are two top-level HDL parameters (DQS_IO_COL and DQ_IO_MS) whose values are also pinout dependent. These UCF constraints and HDL parameters are not included for designs generated with MIG v1.73 or earlier versions.

MIG generates a UCF file and HDL code with the correct constraints and top-level parameters based on the MIG-generated pinout. If the MIG output is being used without modification, you do not need to know the specific rules and procedures for generating these constraints.

When is it necessary to modify the MIG output UCF and top-level parameters?
1. If you generated a design using MIG v2.0, but need to make modifications to the pinout (for example, swapping DQ bit locations).
2. If you have a pinout based on a DDR2 design generated using an older version of MIG (for example, MIG v1.7) and want to rev-up the design to the MIG v2.x DDR2 interface.
- The older MIG-generated pinout is compatible with the MIG v2.0 design. However, you will have to generate the additional constraints that the MIG v2.x design requires.
- MIG v2.x has a slightly different algorithm for selecting the DQ and DM (data mask) sites; MIG v2.x selects different pins for the DM and some of the corresponding DQ pins. Consequently, running MIG v2.x with the same bank pinout selection setting used for the original pre-2.0 design does not result in a UCF and HDL top-level file with completely correct constraints/parameters. Some of the DQ and DM pins are allocated to different pins. However, you can use the MIG v2.x UCF as a baseline for your modifications.
3. You generated a pinout independent of MIG or need to modify a PPC440MC_DDR2 design.
- This is not recommended by Xilinx; MIG should be used to generate the pinout.
- Xilinx recommends generating a UCF file using MIG and using it as a baseline for constraint modifications.
- Be sure to consult the Memory Implementation Guidelines section of the MIG User Guide for details on MIG pinout rules.

These additional constraints are required because of changes to the read data capture architecture used in this design. Specifically, a combination of the IOB-based IDDR flip-flop and flip-flops located in the FPGA fabric is used to capture read data, rather than the ISERDES. A circuit to gate a glitch on the DQS strobe at the end of read bursts added with the MIG v2.x design also requires additional constraints. For full details, see (Xilinx XAPP858):
http://www.xilinx.com/support/documentation/application_notes/xapp858.pdf

This Answer Record provides steps for updating MIG v2.0, v2.1, v2.2, and v2.3 designs as the process has changed between releases. MIG 2.0 requires either manual modification or usage of a perl script. Starting with MIG 2.1, the MIG tool can be used. Full details of the constraints, parameters, and necessary placement is provided in the Updating UCF/HDL Parameters with MIG v2.0 section. If you would like to understand these details, please see this section or refer to the MIG User Guide.

Updating UCF/HDL Parameters with MIG v2.3
1. MIG generates mig.prj files in the output "mig_23/example_design" and "mig_23/user_design" directories. These files contain the project settings specific to a generated MIG project for both the example_design and user_design. A mig.prj file is required to perform the update. This mig.prj file can be from a previous version of MIG or from MIG v2.3.

If you have not generated a MIG design, the first step is to use MIG v2.3 to generate your design. Be sure to select the appropriate banks of your desired pinout on the Bank Selection GUI page to ensure the update completes successfully.

If you are modifying a PPC440 pinout for PPC440MC_DDR2, the first step is to use MIG v2.3 to generate your design. Be sure to select the PPC440 checkbox. After generating the project, use the example_design\mig.prj for the rest of the process.

If you have already generated a MIG design, locate the mig.prj file in your generated MIG project. Ensure that the banks selected for this project match the banks of your desired pinout. This is required for the update to complete successfully.

2. Open MIG either by invoking a new MIG project or by re-opening your previously generated MIG project (only available if MIG v2.3 was used to generate the design). Verify the options displayed on screen one and click Next. On screen two, provide a Component Name and select Update Design. NOTE: Update Design will verify that your pinout adheres to the required pinout rules outlined in the Memory Implementation Guidelines section of the MIG User Guide. Your pinout must meet these guidelines in order for the tool to complete Update Design.

3. Browse to your mig.prj. If your pinout is an example_design pinout (contains the additional example_design pins such as "ERROR"), select the mig.prj file located in the example_design directory. If your pinout does not include the additional example_design pins, select the mig.prj file located in the user_design directory.

4. If you are updating a MIG provided UCF from a pre-MIG 2.0 release, browse to the MIG-generated UCF. If you are updating a UCF to a user-defined pinout, browse to this UCF. The UCF only needs to include the desired pin LOCs; however, the pin names MUST match the MIG syntax.

5. Click through the MIG screens to "Generate" the updated design. The Update Design output will include a complete MIG v2.3 design with the appropriate UCF and top-level HDL parameters based on the input UCF pinout and mig.prj settings.

PPC440MC_DDR2 designs can find the required update C_DQS_IO_COL and C_DQ_IO_MS MHS parameters in the generated example_design\rtl\ddr2_sdram.v file.

If you run into any problems, please see the MIG v2.3 Release Notes (Xilinx Answer 31402) for any known issues.

Updating UCF/HDL Parameters with MIG v2.2
1. Install the patch for MIG v2.2 Update Design located in (Xilinx Answer 31081).

2. MIG generates mig.prj files in the output "mig_22/example_design" and "mig_22/user_design" directories. These files contain the project settings specific to a generated MIG project for both the example_design and user_design. A mig.prj file is required to perform the update. This mig.prj file can be from a previous version of MIG or from MIG v2.2.

If you have not generated a MIG design, the first step is to use MIG v2.2 to generate your design. Be sure to select the appropriate banks of your desired pinout on the Bank Selection GUI page to ensure the update completes successfully.

If you have already generated a MIG design, locate the mig.prj file in your generated MIG project. Ensure that the banks selected for this project match the banks of your desired pinout. This is required for the update to complete successfully.

3. Open MIG either by invoking a new MIG project or by re-opening your previously generated MIG project (only available if MIG v2.2 was used to generate the design). Verify the options displayed on screen one and click Next. On screen two, provide a Component Name and select Verify UCF/Update Design. NOTE: Your pinout must meet the guidelines provided in the Memory Implementation section of the MIG User Guide in order for the tool to update the design.

4. Browse to your mig.prj. If your pinout is an example_design pinout (contains the additional example_design pins such as "ERROR"), select the mig.prj file located in the example_design directory. If your pinout does not include the additional example_design pins, select the mig.prj file located in the user_design directory.

5. If you are updating a MIG provided UCF from a pre-MIG 2.0 release, browse to the MIG generated UCF. If you are updating a UCF to a user-defined pinout, browse to this UCF. The UCF only needs to include the desired pin LOCs; however, the pin names MUST match the MIG syntax.

6. Select the Update Design check box and click Next.

7. Select Verify. This step will verify that the pinout provided meets all MIG implementation guidelines and the settings in the mig.prj file.

8. Step through the screens and select Generate.

9. The generated output will contain the standard MIG directory structure with the addition of an "updated_ucf" directory. The "example_design" and "user_design" directories include the MIG v2.2 design as specified in the uploaded mig.prj file. The "updated_ucf" directory includes the updated UCF and a mig_22_hdl_params.txt text file with the updated DQS_IO_COL, DQ_IO_MS and IDELAYCTRL_NUM top-level HDL parameters. The parameters (DQS_IO_COL and DQ_IO_MS) must be manually changed in the ddr2_sdram.v/.vhd top level file, the IDELAYCTRL_NUM parameter must be manually changed in the ddr2_idelay_ctrl.v/.vhd file, and the UCF must be manually copied to the project.

If you run into any problems, please see the MIG v2.2 Release Notes (Xilinx Answer 30411) for any known issues.

Updating UCF/HDL Parameters with MIG v2.1
1. Create a MIG v2.1 project with your desired memory interface settings.

2. Reopen the MIG v2.1 project. Verify the options displayed on screen one and click Next. On screen two, provide a Component Name and select Verify UCF. NOTE: Your pinout must meet the guidelines provided in the Memory Implementation section of the MIG User Guide in order for the tool to update the design.

3. Upload a UCF with your desired pinout.
NOTE: The UCF MUST include:
- Comments noting the target Virtex-5 device (ie - ## FPGA: xc5vlx20t-ff323)
- Only the DDR2 pinout LOC constraints (additional constraints cannot exist in the UCF)
- The MIG signal syntax (ie - ddr2_dq[0]).
Once the UCF is uploaded, select "Verify".

4. Select the "Add RLOC and DQS Squelch Constraints to UCF file" check box and generate.

5. MIG will output the updated UCF file along with a "mig_21_hdl_params.txt" text file. This file includes the updated DQS_IO_COL and DQ_IO_MS top-level HDL parameters. The parameters must be manually changed in the ddr2_sdram.v/.vhd top-level file and the UCF must be manually copied to the project.

If you run into any problems, please see the MIG v2.1 Release Notes (Xilinx Answer 29911) for any known issues.

Updating UCF/HDL Parameters with MIG v2.0

MIG 2.0 Read Data Capture Block Diagram

The read capture path used for the MIG 2.0 Virtex-5 FPGA DDR2 interface consists of the following sub-blocks:
- DQ is initially captured using DQS in the IOB using the IDELAY and IDDR elements.
- Data is transferred to the FPGA (CLK0) clock domain using a series of flip-flops located in the fabric. The location of these flip-flops and the routes between the IDDR and fabric flip-flops must be carefully defined.
- For each DQS, a circuit is added to disable the clock enable (CE) pin to each of the corresponding DQ capture IDDRs at the end of a read burst ("DQS Gate").

The following figure shows the read capture path architecture for the MIG 2.0 Virtex-5 FPGA DDR2 design, as well as the various portions of the capture path that are affected by the additional UCF constraints and top-level HDL parameters:
MIG Virtex-5 DDR2 Design Read Capture Path
MIG Virtex-5 DDR2 Design Read Capture Path


Additional UCF Constraints Required for MIG 2.0 Design

Because of the improved MIG 2.0 Virtex-5 FPGA DDR2 read data capture algorithm, additional constraints beyond the typical constraints in a previous MIG UCF file (for example, PERIOD timing constraint, pinout LOC and IOSTANDARD constraints for I/O) are required.

You can either manually generate these additional constraints or run a Perl script that automates the process. A Perl script has been created to automatically update a UCF to include the required 2.0 constraints. To download the Perl script and readme.txt, go to:
http://www.xilinx.com/txpatches/pub/applications/misc/ar29313.zip

The additional constraints that the Virtex-5 FPGA DDR2 interface requires be added to the UCF file are:

1. Location (LOC) constraints for the IDELAY and IDDR blocks used for every DQS Gate circuit. There is one DQS Gate circuit per DQS I/O.
2. RPM origin (RLOC_ORIGIN) constraints for each DQ I/O. These constraints exactly locate each RPM and directed routing set by the corresponding DQ IOB.
3. MAXDELAY constraints to limit the delay timing-critical paths related to IOB timing. This is not required to meet any specific cycle-to-cycle timing requirement, but rather to limit any post-calibration voltage/temperature-related changes to the net delay. Voltage/temperature variations on a particular net will increase as the total net delay increases. It is critical to reduce the delay on the DQS gate control input. This signal is generated in the CLK0 clock domain and synchronized via an IDELAY to the DQS domain. The synchronization between the CLK0 and DQS domains on this control net is established once during initial calibration. Calibration will account for the "static" delay component of these nets. However, post-calibration changes in net delay are not accounted for, and must be minimized.
4. FROM-TO constraints:
a. One FROM-TO constraint constrains the DQS Gate path from the IDDR to the DQ CE pins to be approximately a half clock cycle. This ensures that the DQ clock enables are deasserted before any possible DQS glitch at the end of the read post amble can arrive at the input to the IDDR. This value is clock-frequency dependent:

INST "*/gen_dqs*.u_iob_dqs/u_iddr_dq_ce" TNM = "TNM_DQ_CE_IDDR";
INST "*/gen_dq*.u_iob_dq/gen_stg2_*.u_iddr_dq" TNM = "TNM_DQS_FLOPS";
TIMESPEC "TS_DQ_CE" = FROM "TNM_DQ_CE_IDDR" TO "TNM_DQS_FLOPS" 1.6 ns;

b. Additional FROM-TO constraints define multi-cycle paths in the design. These were added to help meet internal (fabric) timing at the higher supported frequencies. At lower frequencies of operation, these multi-cycle path constraints might not be required, and can be removed.

Constraint classes (1) and (2) mentioned in this section are discussed in detail in the UCF/HDL Constraint Generation Procedure section of this Answer Record. Classes (3) and (4) are not discussed because the values do not need to change if the pin-out is modified.

UCF/HDL Constraint Generation Procedure

The following is a step-by-step procedure required to generate the additional UCF constraints and HDL parameters required for the Virtex-5 FPGA MIG 2.0 design. If the above Perl script was used to generate the updated UCF, the following can be used as reference material.

Use MIG 2.0 to Generate a UCF File

Be sure to use the same parameters used in generating the original pre-MIG 2.0 DDR2 design; in particular, the clock frequency and data width must be the same. Substitute the location (LOC) constraints for the existing user pinout into this UCF file. This file will be used as a baseline for further modifications. It is also possible to start with a pre-MIG 2.0 design and add the constraints.

Use the Xilinx ISE Utility PARTGen to Generate a Package File for the Specific Target Device

This file is used to determine the correct (pinout-specific) values for many of the UCF constraints.

partgen -v <part number> (for example, partgen -v xc5vlx330tff1738)

UCF Constraints Must be Modified to Match the User-specific Pinout

1. Verify (no modification required for this step) in the UCF the presence of FROM-TO constraints that define multi-cycle paths. These are generated by MIG 2.0, and their values are not pinout dependent. These constraints help meet internal (fabric) timing at the higher frequencies that MIG supports. At lower frequencies of operation, these multi-cycle path constraints may not be required to meet internal timing and can be removed. One of these multi-cycle path constraints is shown below:

NET "clk0" TNM = FFS "TNM_CLK0";
NET "clk90" TNM = FFS "TNM_CLK90";
# MUX Select for either rising/falling CLK0 for 2nd stage read capture
INST "*/u_phy_calib_0/gen_rd_data_sel*.u_ff_rd_data_sel" TNM = "TNM_RD_DATA_SEL";
TIMESPEC "TS_MC_RD_DATA_SEL" = FROM "TNM_RD_DATA_SEL" TO "TNM_CLK0" "TS_SYS_CLK" * 4;


2. Modify UCF to set site locations for DQS Gate IDDR and IODELAY LOC constraints based on your pinout.

Theory: Each DQS Gate circuit requires the use of an IDELAY and IDDR flip-flop in addition to fabric-based slice resources. The IDELAY and IDDR for each DQS Gate circuit, as well as the fabric flop driving the IDELAY, must be manually located in the UCF file. There will be three constraints for every DQS in the design. See step three for information on the fabric-based slice resources.

The IDELAY and IDDR must be taken from an IOB site where these resources are available, specifically an IOB site that is used only as an output, or that is totally unused. This can be one of the following:

- The DQS_N negative-side I/O site of the DQS differential I/O pair of the corresponding DQS group. A differential I/O pair does not use the input-side resources on the N-side leg of the pair.
- The DM output site for the corresponding DQS group. The DM is an output-only site, and its input-side resources are available for use by the DQS Gate circuit.
- Any IOB site that is either output-only, or unused.

The best site to use is the site that is closest in proximity on the FPGA die to the 4 or 8 DQ I/O sites in that DQS group -- this reduces the routing delay on the clock enable control from the DQS Gate circuit to its corresponding DQ sites -- at higher frequencies, this can often be the critical timing path as there is only roughly half a clock cycle for this path. MIG will always choose to place the IDELAY and IDDR on the DQS_N site for the corresponding DQS group. However, depending on the particular user pinout, there might be a better site available. You might have to relocate the DQS Gate location(s) to other sites to meet timing.

The IDELAY and IDDR for a given DQS Gate circuit must be placed at the same site. They cannot be placed on different sites.

Process:This process must be repeated for each DQS group.

In the PARTGen package file, locate the line in which the "pin name" column value corresponds to the pin location of the DDR2_DQS_N[x] pin (i.e., the "N"-side of the differential strobe).
b. Use the XY-coordinate in the "pad name" column on that line, and substitute this for the "LOC = ILOGIC_xxxx" and "LOC = IODELAY_xxxx" constraints for that DQS group.

For example, for a design using a 5VLX50T-FF1136, if DDR2_DQS_N[0] is on pin "N30," the corresponding pin name (IOB) XY-location is X0Y176. The correct values for the DQS Gate circuit IDDR and IODELAY LOC constraints are as follows:

INST "*/gen_dqs[0].u_iob_dqs/u_iddr_dq_ce" LOC = "ILOGIC_X0Y176";
INST "*/gen_dqs[0].u_iob_dqs/u_iodelay_dq_ce" LOC = "IODELAY_X0Y176";


3. Modify UCF to set the correct site location for the fabric flip-flop driving the DQS gate signal. This flip-flop must be placed close to the corresponding DQS gate IODELAY.

Theory:The fabric flop driving the IDELAY with the DQS Gate control pulse must also be location-constrained to be near the corresponding IDELAY/IDDR. The rules for determining this are:

- Locate the IOB where the corresponding IDELAY and IDDR are location-constrained to.
- Use the appropriate package file to find the "Nearest CLB." Location-constrain this flop to this location.
The reason for this requirement is to minimize the net delay out the output of this flop to the synchronizing IDELAY. It is possible to not constrain this flop to a specific location (or constrain it to a different location) as long as the corresponding MAXDELAY for this net can be met (for example, allow MAP to place this flop).

Process:The process described below must be repeated for each DQS group.

a. As in the previous step to determine the IDDR and IODELAY locations, locate (in the PARTGen package file) the line in which the "pin name" column value corresponds to the pin location of the DDR2_DQS_N[x] pin (i.e., the "N"-side of the differential strobe).
b. Use the XY-coordinate in the "nearest CLB" column on that line and substitute this for the "LOC = SLICE_xxxx" constraint for that DQS group.

For example, for a design using a 5VLX50T-FF1136, if DDR2_DQS_N[0] is on pin "N30," the corresponding "nearest CLB" is X0Y88. The correct value for the DQS Gate circuit fabric flop LOC constraint is as follows:

INST "*/u_phy_calib_0/gen_gate[0].u_en_dqs_ff"
LOC = SLICE_X0Y88;


4. Verify (no modification required for this step) MAXDELAY constraints to limit the length of nets associated with the DQS Gate control signal. This constrains the path for all DQS groups:

NET "*/u_phy_io_0/en_dqs*" MAXDELAY = 600 ps;
NET "*/u_phy_io_0/gen_dqs*.u_iob_dqs/en_dqs_sync" MAXDELAY = 850 ps;


5. Verify (no modification required for this step) the FROM-TO constraint to define the path between the DQS Gate driving IDDR and the clock enable inputs to each of the data (DQ) capture IDDRs in that DQS Group. Note that this value is frequency dependent and is automatically calculated by MIG, based on the memory bus clock frequency.

An example for 333 MHz is shown below:

INST "*/gen_dqs[*].u_iob_dqs/u_iddr_dq_ce" TNM = "TNM_DQ_CE_IDDR";
INST "*/gen_dq[*].u_iob_dq/gen_stg2_*.u_iddr_dq" TNM = "TNM_DQS_FLOPS";
TIMESPEC "TS_DQ_CE" = FROM "TNM_DQ_CE_IDDR" TO "TNM_DQS_FLOPS" 1.60 ns;


6. Modify RPM origin (RLOC_ORIGIN) constraints for each DQ I/O. Part of the read data capture occurs in the fabric and the relative placement of the flip-flops is fixed using an RPM (Relationally Placed Macro) defined in the HDL. Each DQ has a read capture RPM associated with it, and each one must be placed correctly relative to the DQ I/O pin. This process must be repeated for each DQ data bit.

a. Locate the correct line in the package file for the DQ of interest, based on its pin number.
b. Note the value in the "pad name" column. The X-coordinate of this entry is used to determine which I/O column (left = 0, center = 1, or right = 2) the DQ pin is located on.
c. Note the value in the "diff pair" column. This determines whether the DQ pin is located on the slave or master site of a differential I/O pair. If the value ends in an "S," that is a slave site.
d. If that site is a slave site, refer to the corresponding master site. This is the adjacent line whose "diff pair" entry has the same numeric value, but ends in "M" for the next step in this process (determining nearest CLB value). For example, for a design using a 5VLX50T-FF1136, if DDR2_DQ[0] is on pin "T6," the "diff pair" entry for this location is "67S," which indicates it is a slave location. For the purposes of determining the nearest CLB location in the next step, refer to the line above it; corresponding to location "R6" (diff pair = "67M").
e. Refer to the nearest CLB value (again, if this is a slave site, refer to the nearest CLB value for the corresponding master site). The relationship between the "nearest CLB" as indicated by the package file, and the actual RPM is shown below for left, center, and right columns. The figures also show the spatial relationship between the IOBs and the location of the slices that contain the flip-flops used for read data capture:

Calculation of RLOC_ORIGIN (Left)
Calculation of RLOC_ORIGIN (Left)

Calculation of RLOC_ORIGIN (Center)
Calculation of RLOC_ORIGIN (Center)

Calculation of RLOC_ORIGIN (Right)
Calculation of RLOC_ORIGIN (Right)


NOTE: Column directionality is determined by the view as seen by FPGA Editor. This is the opposite of the view shown in the bank selection pane of the MIG Wizard.

f. If the DQ site is on the left column, use this value directly in the RLOC_ORIGIN constraint.

For example, on an 5VLX50T-FF1136, for a DQ pin at "U25," the "nearest CLB" is "X0Y80." The RLOC_ORIGIN is:

INST "*/gen_dq[0].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise" RLOC_ORIGIN = X0Y80;

7. If the DQ site is on the center or right column, subtract 4 from the X-coordinate indicated by the nearest CLB value, and use this as the RLOC_ORIGIN. For example, on an 5VLX50T-FF1136, for a DQ located at F13, the "nearest CLB" is "X52Y100." Subtracting 4 from the X-coordinate yields "X48Y100."

INST "*/gen_dq[0].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise" RLOC_ORIGIN = X48Y100;

Modify the Top-level Parameter/Generics DQS_IO_COL and DQ_IO_MS

The values of two top-level HDL parameters/generics, DQS_IO_COL and DQ_IO_MS, must be modified to reflect your specific pinout. These must be properly set for the HDL to correctly choose which RPMs and directed routing constraints to instantiate for each DQ read capture circuit:

1. Modify the value for DQS_IO_COL. This parameter is an array indicating the I/O column location of each of the DQS I/O's:

a. The length of this parameter is = 2 * # of DQS I/O = 2 * DQS_WIDTH
b. Determine which column each DQS I/O is on. As in previous steps, this can be determined from the PARTGen package file. Locate the correct line in the package file for the DQS of interest, based on its pin number. The X-coordinate of this entry is used to determine which I/O column (left = 0, center = 1, or right = 2).
c. Each element of the parameter consists of two bits which indicate the I/O column location of each DQS. Set the entry to "00" for the left column, "01" for the center column, "10" for the right column. "11" is a reserved value and must not be used. The least significant two elements of the array correspond to DQS[0].

As an example, for a 32-bit, 4-strobe design, with DQS[0,1] located in the left I/O column, DQS[2] located in the center I/O column, and DQS[3] located in the right I/O column (a configuration that is not recommended, but is shown for illustrative purposes!), DQS_IO_COL is 8 bits long and must be set to "10010000."

2. Modify value for DQ_IO_MS. This parameter is an array indicating whether each DQ pin occupies a master or slave I/O location:

a. The length of this parameter = # of DQ I/O = DQ_WIDTH
b. Determine whether each DQ is located on a master or slave site. As in a previous step, this can be determined from the "diff pair" column in the PARTGen package file.
c. Each element of the parameter is one bit and indicates whether the corresponding DQ occupies a master or slave I/O location. Set to "0" for slave, and "1" for master. The least significant element of the array corresponds to DQ[0].
For example, for an 8-bit, 2-strobe design, with DQ[0,2,4,6,7] on master I/O locations, and the other DQ's on slave I/O locations, DQ_IO_MS is 8 bits long, and must be set to "11010101."

3. Modify the values assigned to DQ_IO_MS and DQS_IO_COL parameters/generics in the top-level MIG (VHDL or Verilog) module based on the results of the steps described above.

Setting HDL Code Top-Level Placement Parameters

The read capture path consists of both dedicated circuit elements embedded in the IOB (that is, the IDDR flop and IDELAY), as well as several flip-flops in the FPGA fabric. The placement of these fabric flip-flops is critical in order to provide maximum timing margin for read data capture. These flip-flops must be placed in close proximity, both to each other and to the IOB. In addition, the route delays from the IOB to these fabric flip-flops must be kept as short as possible to reduce the absolute delay of each route, as well as the skew between routes from the IOB to different fabric flip-flops.

Within the Virtex-5 FPGA DDR2 interface HDL code, Relationally Placed Macros (RPMs) are defined. RPMs allow fixed relative placement of basic logic elements (for example, flip-flops) with respect to each other. In addition, directed routing constraints (also known as "DIRT strings") are embedded in the code to specify the exact routing resources used for the routes from the IOB to the fabric flip-flops. RPMs and directed routing constraints are portable between different device and package combinations in the same FPGA family (for example, LX50T-FF1136 or LX330-FG1760). However, the path from the IOB to the closest fabric flip-flops is not uniform across a device. The factors that determine these differences, and how this is accounted for in the design, are discussed below.

There are different sets of RPM and directed routing constraints embedded in the HDL code because one set cannot account for all possible routing conditions across all pins of a device. Which RPM set is enabled is done on a DQ-by-DQ basis, and is determined by each DQ and DQS pin location.

In particular, the following conditions determine which set of RPM and directed routing constraints are selected for each DQ:

1. The I/O column location for the entire DQS group strobe: Each Virtex-5 device has its IOBs arranged into three (left, center, right) columns. Each DQS group, consisting of DQ, DQS, and DM pins, must be located on the same I/O bank, which also means they must be located on the same I/O column. The location of fabric slice sites near the IOBs is different between the 3 I/O columns. Consequently, the need to support different RPM sets depends on the I/O column used. Note that different DQS groups can be located on I/O banks in different I/O columns; although this is strictly allowed from an I/O-placement rule standpoint, placing DQS groups in different I/O columns might make it harder for the tools to meet internal PERIOD timing (for example, internal nets will have to be routed farther to access DQ/DQS pins spread out across different columns).
2. Whether the DQ pin is located on a Master or Slave I/O: Virtex-5 FPGA I/Os are arranged in pairs to allow their possible use as differential pairs. The pin descriptions as indicated in the Virtex-5 device pinout tables in the document "Virtex-5 Packaging and Pinout Specification" indicate whether an I/O is the slave or master I/O for that pair. For example, on an LX50T-FF1136, pins V28 and V27 form an I/O pair. V28 ("IO_L5P_17") is the master I/O, and V27 ("IO_L5N_17") is the slave I/O. Whether an IOB is a master or slave site determines which fabric slices it uses for the read capture logic.

The following top-level parameters must be properly set in order for the code to correctly choose which RPMs and directed routing constraints to use for each DQ:

1. DQS_IO_COL: This parameter is an array indicating the I/O column location of each of the DQS I/O's:

- Length of parameter = 2 * # of DQS I/O = 2 * DQS_WIDTH
- Each element of the parameter consists of two bits that indicate the I/O column location of each DQS. Set the entry to "00" for the left column, "01" for the center column, "10" for the right column. "11" is a reserved value and must not be used. Column directionality is determined by the view as seen by FPGA Editor. Note that this is the opposite of the view shown in the bank selection pane of the MIG 2.0 Wizard!
- The least significant element of the array corresponds to DQS[0].
- As an example, for a 32-bit, 4-strobe design, with DQS[0, 1] located in the left I/O column, DQS[2] located in the center I/O column, and DQS[3] located in the right I/O column (a configuration that is not recommended, but is shown for illustrative purposes), DQS_IO_COL is eight bits long, and must be set to "10010000."

2. DQ_IO_MS: This parameter is an array indicating whether each DQ pin occupies a master or slave I/O location.

- Length of parameter = # of DQ I/O = DQ_WIDTH.
- Each element of the parameter is one bit, and indicates whether the corresponding DQ occupies a master or slave I/O location. Set to "0" for slave, and "1" for master.
- The least significant element of the array corresponds to DQ[0].
- As an example, for an 8-bit, 2-strobe design, with DQ[0, 2, 4, 6, 7] on master I/O locations, and the other DQ's on slave I/O locations, DQ_IO_MS is eight bits long, and must be set to "11010101."

Verifying UCF/HDL Modifications

You can verify that your modifications to the UCF and HDL top-level files are correct as follows:

1. All timing constraints (PERIOD, MAXDELAY, FROM-TO) must be met.
2. The Place and Route (PAR) report must be checked to ensure that all directed routing constraints ("DIRT") have been successfully routed.
- These directed routing constraints fix the internal net routing between the IDDR and fabric-based flip-flops. These paths are not covered by timing constraints. You must instead verify that these directed routing constraints have been successfully routed.
- There are two directed routing constraints for every data bit. For example, for a 72-bit design, 144 directed routing constraints must be routed. The relevant PAR report section listing this looks as follows:

INFO:ParHelpers:199 - All "EXACT" mode Directed Routing constrained nets successfully routed. The number of constraints
found: 144, number successful: 144


- Failure by PAR to route certain directed routing constraints can indicate incorrect values for the HDL top-level parameters DQ_IO_COL and/or DQ_IO_MS.

If timing issues are encountered, see (Xilinx Answer 29900) for further information.
AR# 29313
Date Created 10/28/2007
Last Updated 04/07/2009
Status Active
Type
Feed Back