We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 29221

10.1 EDK, MPMC v4.00a - Spartan-3 MIG PHY Usage Guidelines


I am generating a MIG-PHY MPMC v3/v4-based design in a Spartan-3 device.

Are there any additional usage suggestions?


Additional Information on MPMC v3.00.a Using Spartan-3 Generation MIG PHY 


MPMC designs using a DDR/DDR2 MIG PHY for Spartan-3 generation devices require that you run the MIG tool version 1.73 to generate a UCF file, and then run a Perl script named "convert_ucf.pl" to convert the MIG-generated UCF constraints to match the internal instance names in the MPMC Core. 

This process is outlined in the MPMC data sheet.

This Answer Record provides additional information to help you implement your Spartan-3 MPMC designs.

Carefully review the information in the data sheet, MIG documentation, and all current Answer Records before designing a new custom board or creating designs to run on a new custom board.  


In this Answer Record, the term "Spartan-3" applies to all Spartan-3/-3E/-3A/-3AN/-3A DSP devices. 


MIG - MPMC Compatibility 


Each major MPMC version requires a specific MIG pin-out to function correctly. 

- MPMC v4.03.a requires MIG 2.3. MIG v2.3 was released with 10.1 IP Update 3. 

- MPMC v4.00.a to v4.02.a requires MIG v2.1. MIG v2.1 was released with 10.1. 

- MPMC v3.00.a requires MIG v1.73. MIG v1.73 was released with 9.2i IP Update 1. 

MIG v1.73 pin-outs should still be compatible with MIG v2.1-based MPMC designs in the future. 


MPMC versions are not tested against earlier or later versions of MIG than the specific required MIG version.

For example, do not use MIG v2.0 or MIG v1.72 to generate constraints for MPMC v3.00.a. 


When running the MIG tool, ensure that the MIG memory settings match the parts you intend to use on your custom board, and also match your MPMC memory settings.

In particular, ensure that memory parameters that affect the memory interface, such as data width, number of rows, columns, bank bits, memory types, etc., are correct and consistent. 


Important Notes on MIG Board Compatibility 


Many existing evaluation boards were developed before the MIG tool was finalized, so it is often the case that Xilinx or third-party evaluation boards do not have exactly the same pin-out that would be generated by supported MIG versions.

However, these boards usually come with a predefined MPMC UCF file that is suitable for that board to function correctly. 


Some Xilinx boards, including the Spartan-3E Starter Kit (XC3S500E), Spartan-3E 1600E MicroBlaze Development Kit, and the Spartan-3A/-3AN Starter Kit boards, have a pin-out that significantly deviates from normal MIG pin-out assignment rules.

For these boards, a parameter to MPMC called C_SPECIAL_BOARD is used to modify the internal PHY logic to compensate for the memory pin-out on these boards.

A predefined MPMC UCF file is needed for these boards so that systems created using BSB have the necessary C_SPECIAL_BOARD and UCF settings. 

Having more severe MIG pin-out violations means the Xilinx Spartan-3E Starter Kit (XC3S500E) and Spartan-3E 1600 MicroBlaze Development Kit should not have their memory clocks run above 100 MHz with MPMC v3.00.a. 


You should also be aware that you should not copy the pin-out of evaluation boards that do not match a supported MIG-generated pin-out. 

All user boards must be designed exactly to the supported MIG version pin-out.

Non-MIG v1.73/2.1 pin-outs might not be supported and might not be robust. User boards must also follow layout recommendations specified in the MIG user guide, including special trace delays for the DQS_DIV_O to DQS_DIV_I loopback signal.

BSB boards in general may have different UCF constraints to convert MIG UCFs; user designs should follow the UCF conversion flow documented in the MPMC datasheet. 


Xilinx highly recommends that if you are developing a new custom board, run the MIG design with hardware testbench logic through the full ISE tool flow to verify that proposed pin-outs will implement properly through the ISE tools. 


MIG/MPMC Tool Flow 


This section outlines the MPMC/MIG tool flow: 


The following alignment solution must be followed when using the MPMC MIG PHY in Spartan-3 architectures: 

(Xilinx Answer 31107) 

Alternatively, setting the environment variable XIL_PAR_ALIGN_USER_RPMS to 1 can be performed. 


In EDK 9.2i only, set the environment variable XIL_ROUTE_ENABLE_DATA_CAPTURE to 1 (this is no longer necessary in ISE/EDK 10.1 and later). 



MIG should be set to Verilog output mode (Project -> Project Options -> Generation Tab -> Design Entry -> Verilog). 


Run the MIG tool version from CORE Generator, and set up memory part information, data widths, I/O banking locations, etc. (if necessary, click the "User Guide" button and carefully review the board layout requirements for the memory interface).

Then, click the "Generate" button when ready to generate a MIG pin-out. 


Note: Clicking the "Generate" button also produces a MIG hardware testbench design at: <coregen_project>/mem_interface_top_withtb. 

This testbench design can be run as a standalone hardware design on the board to help test/debug the memory PHY interface. 


After running the MIG tool, take the UCF file created by MIG located at: 



Run the "convert_ucf.pl" script as outlined in the MPMC data sheet to convert the MIG UCF file to an MPMC UCF file, then copy the UCF information into the <EDK_Project>/data/system.ucf file. 


Next, update the UCF file to include the correct port names for your design.

For example, the convert_ucf script will produce port names like fpga_0_DDR_SDRAM_DDR_DQ and fpga_0_DDR_SDRAM_DDR_Addr_pin similar to how BSB names its ports. 

Those MPMC UCF port names should be updated to reflect the actual top-level port names in the "system.mhs" file. 


Ensure that the MPMC Core is configured for the desired memory part and memory configuration in XPS using the MPMC GUI. 

The MPMC Core memory parameters should match the settings in the MIG GUI so that the UCF constraints match the logic that is generated. 


The EDK project can then be run to build the hardware system. 

When running the place and route tools, Spartan-3 MPMC designs might generate timing errors on the MAXDELAY constraints in the MPMC UCF. 

If this occurs, check the <EDK_project>/implementation/system.twr file for the errors. 

If the worst case path is within the range of allowable delays mentioned in the comments of the MIG UCF, the constraint can be relaxed to allow timing to pass.

MAXDELAY constraints should not be relaxed beyond the range of values described in the UCF comments.

It might take several iterations of the tools to resolve the MAXDELAY timing constraints so the design meets timing.

Alternatively, you can proceed with the design and allow for false timing errors in the MPMC Spartan-3 PHY logic. 


After successfully running the design through to BitGen, Spartan-3 designs should be checked in FPGA Editor to be sure the template router correctly routed the key memory PHY nets. 

Open <EDK_project>/implementation/system.ncd in FPGA Editor. Follow the instructions provided in (Xilinx Answer 25245) to verify the template router. 


Using Static PHY (not MIG compliant) 


If a Spartan-3 board pin-out is not MIG compliant, a potential option for supporting the board is to use the Static PHY, which uses a DCM phase shift-based data capture mechanism.

The Static PHY should be used only as a work-around, and might be less robust than the MIG PHY, especially at higher frequencies.

The static PHY should be operated up to approximately 125 MHz.

Higher frequencies must always have static timing analysis performed to ensure sufficient external I/O timing margin.

The static PHY is described in greater detail in the MPMC data sheet. 


Board Bring-Up Tips and Hints 


1. During initial bring-up of MPMC on a new Spartan board, Xilinx recommends that you start with a single-port MPMC with PLB PIM. This design should be modeled off of a simple BSB-based MicroBlaze design with caches disabled. 

2. During initial bring-up, start running the memory controller at the minimum clock speed that the memory device supports to establish as a working baseline. Then, increase the memory clock speed up to the desired frequency. 

3. Use the MicroBlaze + Single-Port MPMC design and connect with XMD. Then, perform simple reads and writes to establish whether basic memory transactions work.  

4. Incrementally add complexity to the design by building it up to be closer to your desired MPMC system configurations. For example, after getting the single-port design to work, enable MicroBlaze caches and connect the MicroBlaze IXCL/DXCL ports to a 3 Port XXP MPMC design (2 XCL + 1 PLB). Establish that memory transactions continue to work with caches off, and try the test with caches on to test burst read transactions from memory. 


Debug Tips and Hints 


For Spartan-3 MIG designs that do not work, some debug ideas are presented below that might help in the debug process. 


1. Check the template router nets in the FPGA Editor and confirm that the correct routes are being used. 

2. Check that the MicroBlaze can connect to XMD and that simple XMD reads/writes to LMB BRAM are working. This establishes that the basic processor subsystem is working. 

3. Check the PAR report and ensure that all I/O signals are located. 

4. If reads from memory space return the same data value across all memory locations, this is a symptom of a hang in the PHY. This might be caused by incorrect connections on the DQS_DIV_I/DQS_DIV_O loopback trace, problems with the DQS nets, incorrect template router nets (see #1), or problems with the generation/conversion of the MIG UCF. 

5. For data corruption errors or hangs, additional debug might be required by using ChipScope to probe the signals inside the Spartan-3 PHY block. Signals that can be checked are: 

a. PHY read FIFO data out signals (two FIFOs per byte lane: one for posedge data and one for negedge data). Monitor these signals to check the read data strobed in by the DQS signal. 


i. Read FIFO Data Out = *mpmc_phy_if_0/data_path/data_read/fifo_0_data_out_r<*> *mpmc_phy_if_0/data_path/data_read/fifo_1_data_out_r<*> 


b. PHY read FIFO control signals. The signal "read_valid_data" is used to qualify read data being returned to the MPMC data path logic. The "wr_addr" and "rd_addr_out" signals are gray code counters that implement the FIFO read and write pointers driving a dual-port LUT-based RAM for each data bit. A different set of FIFO pointers is implemented on each byte lane of data for posedge and negedge data. 


i. *mpmc_phy_if_0/data_path/data_read/read_valid_data 

ii. *mpmc_phy_if_0/data_path/data_read/fifo_0_wr_addr_out<*><*> 

iii. *mpmc_phy_if_0/data_path/data_read/fifo_1_wr_addr_out<*><*> 

iv. *mpmc_phy_if_0/data_path/data_read/fifo_0_rd_addr_out<*><*> 

v. *mpmc_phy_if_0/data_path/data_read/fifo_1_rd_addr_out<*><*> 


c. PHY calibration tap values. These calibration values determine what delay is being applied to the DQS signals to align the edges of the DQS strobe signal to the data.  


i. *mpmc_phy_if_0/infrastructure/cal_top/cal_ctl/tapForDqs_rl<*> 


d. ChipScope usage notes: attaching ChipScope probes onto signals that are used by the template router could disrupt critical timing/routing nets. 

ChipScope probes should be attached only to signals operating in the MPMC_Clk0 and MPMC_Clk90 clock domain.

The use of ChipScope on a Spartan-3 device could cause a conflict with the BSCAN element used for XMD access.

This might require the use of XMD stub-based debug, or might require that a test program be initialized into LMB block RAM to generate the memory transactions. 


6. Isolate which byte lanes are causing hangs or data errors, and investigate those byte lanes further in greater detail. 

7. Implement the MPMC design using the Static PHY, get the static PHY to work, then compare results between static PHY and MIG PHY. For example, write with one PHY and read with the other PHY to help isolate the problem to reads or writes. 

8. Run the standalone MIG hardware testbench design. This design consists of MIG PHY, controller, and hardware testbench that loops write/read data to memory. The MIG hardware testbench design includes preconfigured ChipScope probes and an error status LED output. If the standalone MIG testbench is not working, resolve it first. The standalone MIG testbench is a smaller and simpler design that might be easier to debug. 

9. Verify that clock, control, data, power, and ground signals and board traces have the proper signal integrity and implementation on the board. 


Note: If you are not familiar with creating hardware and software designs as outlined in the steps above, or you are unfamiliar with the debug tool flows, practice building these designs using BSB and a supported Spartan-3 evaluation board, such as the Spartan-3A Starter Kit or the Spartan-3A DSP 1800 Starter Kit. 


Relevant Answer Records: 


(Xilinx Answer 25406): MIG v1.73 - Release Notes and Known Issues for 9.2i IP Update 1 (9.2i_IP1) 

(Xilinx Answer 25245): MIG v1.72 - How do I Determine if the PAR Template Routes are Properly Used for Spartan-3 DDR/DDR2 SDRAM Designs?  

(Xilinx Answer 30295): 10.1 EDK, MPMC v4.00.a - BitGen dangling pins and gated clocks warnings with MIG Spartan-3 PHY 


AR# 29221
Date 03/30/2015
Status Active
Type General Article
  • EDK
  • Memory Interface
Page Bookmarked