Test - 1: - The TestApp_Memory running out of SRAM accessing MPMC (DDR2) hangs or displays incorrect characters on HyperTerminal when SRAM clock is at 125 MHz. However, running the same test out of MPMC (DDR2) and accessing the XPS MCH EMC (SRAM) passed.
Test - 2: - In the TestApp_Peripheral interrupt vectors are stored in SRAM and other part of SW is in MPMC DDR2. The SW test consists of testing xps_intc and xps_temac. The test passes for xps_intc but hangs for xps_temac when it accesses the interrupt vectors stored in the SRAM.
Below are the delay captured from the timing report generated by ISE 9.2 (J.40):
Port Net Delay Tckq Net Tioop Total delay from DCM out to FPGA Pin
Mem_A 2.725 0.5840 0.0020 3.1980 6.509
Mem_CEN_0 2.888 0.584 0.002 3.219 6.693
Mem_WEN 2.716 0.584 0.002 3.21 6.512
fpga_0_SRAM_CLOCK 3.716 NA NA 2.151 5.867
Please refer to the 'readme' document in the attached reference design for timing diagram and additional clarification.
XPS MCH EMC design is sending command at CLK0 and expecting the data on CLK3. However, due to the delays as shown in table above, this command will be seen by SRAM in the CLK1 time period. Hence, SRAM will start sending data in the CLK2 time period. This data has to follow the tCO (3ns approximately) for SRAM and PADs to FFs (1.5ns) time to arrive at the ILOGIC (internal to FPGA). There is also a delay of 2.5 ns for the Clk_125 to arrive at ILOGIC (due to internal net delay).
With the above timing delays, it is giving much less setup time for the DQ to get registered as shown in the timing diagram in the 'readme' file in the reference design attached.
Adding a delay to SRAM clock going out off FPGA to SRAM by 270 degrees will fix this problem.
Original Delay Added Delay Total Effective
fpga_0_SRAM_CLOCK 5.867 ns 6 ns 11.867 ns 3.867 ns
This extra phase shift gives the required setup time for the DQ.
Please review the 'readme' file and the "system.mhs" from the link below to set up the correct phase shift in the clock_generator module.