Help implementing DDR2 using a fresh MIG3.9 core build, including question on Reset

Spartan-6 PCI Express Module
1

I’m having trouble with the memtest example. It seems that the calibration is not reliable. In one test, I ran the test continuously for an entire weekend with a fan running on it with 0 failures and without stopping, ran it another 24 hours without failures with the fan removed and the FPGA covered in insulation to get it as hot as possible (about 75C). So I know the mem test works fine if it starts on a good foot.

However, when I start the test, I have a large probability that I will get a lot of errors, sometimes 30%, sometimes 60%, sometimes 10% which continue indefinitely. If I restart it, which reconfigures the FPGA and thus redoes the calibration step, it may or may not work correctly, even if the fan is running. It does not appear to be heat related, as my example with the fan and no fan shows it can work fine.

So I am trying to rebuild the MIG using the latest MIG (3.9) for Spartan 6. I’m using the example_top project, with only the infrastructure module from the memtest project. However, it doesn’t seem to work at all - the calib_done signal does not go high when viewed through chipscope. Is there some sample code for MIG 3.9 ?

One thing I noticed that I don’t understand is that the memtest project does not correctly wire reset to any external pin, so I’m guessing that it is floating (and probably pulled weakly low). Is this a undocumented feature, or was this unintended?

Is there a system reset line on the 6110 board that I can route into my design at the top level, that is asserted and deasserted by the PCI logic when it is configured? If not, how should I deal with Reset without wiring my own button to one of the IOs?

2

Well, I figured out the reset why it was not coming out of calibration. The example_top project does not define the chip select as a top level port, and thus it isn’t driven.

You’ll need this in the ucf:
NET “mcb3_dram_cs_n” LOC = “C3” | IOSTANDARD=LVCMOS18 ;

and add to the port list and assign it to 1’b0.

Here is a useful debugging guide to MIG hardware issues:

[URL=“http://www.xilinx.com/support/answers/43520.htm”]http://www.xilinx.com/support/answers/43520.htm[/URL]

But something still isn’t working - the error flag is asserted… My question on reset still stands though - what the recommended way of dealing with system reset?

3

To your question about reset with FPGAs…

The Xilinx documentation has a few scattered examples of providing resets depending on what you mean to accomplish. For example, you can use the lock signal from a DCM or PLL to perform a system-wide reset.

Via FrontPanel, we often use a WireIn as a system reset and can additionally reset the DCM or PLLs on the system clocks if required.

As you note, you can also string an input pin from your external connections to the FPGA.

4

As a favor to me in 6 months when I forgot what I did today, I’m recording how I got the calibration to complete and the error flag to be 0.

I’m not sure if this was the reason, but I changed the clocks to be a 200 MHz DDR2 clock (400 Mhz MIG clock) from the 100 MHz board clock.

These are the changes to example_top.v

[INDENT] parameter C3_MEMCLK_PERIOD = 5000, // 200 Mhz
// parameter C3_MEMCLK_PERIOD = 3200, // 300 ish Mhz
[/INDENT]
[INDENT] parameter C3_HW_TESTING = “TRUE”,
// parameterC3_HW_TESTING = “FALSE”,
[/INDENT]

and to memc3_infrastructure.v (from the memtest example supplied by OK)

[INDENT] // .CLKOUT2_DIVIDE (4), // 156.256 MHz test bench clock
.CLKOUT2_DIVIDE (16), // based on example design, ie 25 MHz

// .DIVCLK_DIVIDE (4),
// .CLKFBOUT_MULT (25), // 25MHz x 25 = 625 MHz system clock
.DIVCLK_DIVIDE (1),
.CLKFBOUT_MULT (4), // 100/1*4 = 400 Mhz sysclk2
[/INDENT]

When it runs in chipscope and the traffic generator stops, I see
c3_p0_cmd_byte_addr = 0x2FFFE00
c3_p0_wr_count 0x40
c3_p0_wr_data = 0x018ACE00
which looks reasonable. I’ll have to figure out how to get the traffic generator/tb to run continuously, like it used to on another project…