UPGRADE YOUR BROWSER

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!

Reply

MIG 3.61 DDR2 in Virtex 5

Accepted Solution Solved
Highlighted
Visitor
Posts: 5
Registered: ‎11-09-2016
Accepted Solution

MIG 3.61 DDR2 in Virtex 5

I have tried to generate a DDR2 SDRAM Controller from MIG 3.61 for Virtex 5 XC5VLX50. The behavioral simulation works fine, I can see the DDR2 SDRAM is initialized correctly, and I can read all the data previously written on the DDR2 SDRAM.

 

I have tried to generate the bitstream, and when I have executed the program, the DDR2 never finished the initialization phase. I have checked the clock input signals to make sure all the frequencies that the project needs are correctly generated. When I tried to check the frequency of the signals clk0, clk90, clkdiv0 and clk200 from a logic analyzer, I have observed that the frequency of the signals changes through the time. 

 

At simulation, these frequencies work fine, but when I've checked these signals from hardware, their behavior it does not the same. 

 

For the generation of the clock signals that DDR2 SDRAM module needs, I use a DCM module generated from IPCore Generator. My card has a source clock of 100MHz and I have generated 2 independent 200MHz clocks from the DCM (one from CLKFX and the other from CLK2X outputs). This 2 clocks of 200 MHz are used by the DDR2 SDRAM module generate by MIG (one by internal PLL module to generate clk0, clk90 and clkdiv0, and the other to use just like this with a frequency of 200 MHz).

 

There is a way to know if the clk signals that I have generated are correct. I don't know why when I see from the logic analyzer, the frequencies of these signals changes. There is another possibility for which the DDR2 SDRAM design could not finish the initialisation phase

 

Thanks in advance

 

Manu

 

 


Accepted Solutions
Instructor
Posts: 9,042
Registered: ‎08-14-2007

Re: MIG 3.61 DDR2 in Virtex 5

[ Edited ]

It's good to know the limitations of your tools.  In the attached image, a 60% duty cycle clock is sampled with at an asynchronous rate as in your logic analyzer's 1 GHz timebase.  Notice that the duty cycle of the sampled signal changes even though the input signal runs at a constant duty cycle and frequency.

 

If you have a ChipScope license, you might consider adding the debug signals to the MIG core to help in finding out the issue.  One common problem is an incorrect Vref level.  Vref needs to be very close to 1/2 of Vcco, 0.9V nominal for DDR2.  If you use a resistor divider to create Vref from Vcco and there is excessive current draw on the Vref net, the actual voltage can change.  I've had problems in the past where I hooked Vref to all banks in the memory system including one bank that only supplied address and control signals.  Since that bank had only outputs and no inputs, its Vref were not configured as Vref but rather as "unused IO."  The default configuration for unused IO is a weak pullup.  That pullup was enough to raise the Vref voltage out of usable range.

-- Gabor

View solution in original post

asyncSampling.PNG

All Replies
Instructor
Posts: 9,042
Registered: ‎08-14-2007

Re: MIG 3.61 DDR2 in Virtex 5

If the frequencies are changing, it's likely that the DCM or PLL has lost lock.  If you're not monitoring the LOCKED output of the DCM, it would be a good idea to add that to the design and implement a way to reset the DCM if it remains unlocked for some time period (check the data sheet for max time to lock and set the reset timeout larger than that).  The DCM also has some status outputs that might help to debug this.  The MIG core "infrastructure" module usually uses the LOCKED output of the DCM or PLL as an additional reset source, so losing lock would also explain the absence of a calibration complete indication.

 

A common reason to lose lock is excessive jitter on the clock input.  That could be caused by the clock source itself, for example some PLL-based oscillators can have relatively high peak to peak jitter.  It can also happen, especially on single-ended clocks, from noise on the I/O power supply, both supplying the oscillator and supplying the Vcco to the bank receiving the clock signal.  Also ground bounce from simultaneously switching outputs (SSO) can cause clock jitter.

-- Gabor
Visitor
Posts: 5
Registered: ‎11-09-2016

Re: MIG 3.61 DDR2 in Virtex 5

Hi Gabor,

 

Thanks for your reply. I have already monitored the locked signal, and I have seen that after I disable the reset signal, locked signal is activated, and it remains like that all the time. I have also checked the all of the DO status signal (DO (0 to 4)) stay deactivated all the time.

 

I don't know if there is a problem in the way I monitored the clock signal from the logic analyzer. There is something that I need to take into account when I monitored this signal from a logic analyzer ?

 

Do you have any clue, why locked and DO status signal says that the DCM output signals are OK, but when I monitored them from the logic analyzer, they don't behave in a correct way ?

 

Thanks in advance

 

Manuel

Waveform DCM Output.png
Instructor
Posts: 9,042
Registered: ‎08-14-2007

Re: MIG 3.61 DDR2 in Virtex 5

I don't see a change in frequency in the snip you posted from the analyzer.  However I can see that your sampling rate (500 MHz?) is low enough that you can see apparent changes in duty cycle on one signal, when it's probably just an artifact of asynchronous sampling.  It's possible that this is just a red herring, and your real problem lies somewhere else.

-- Gabor
Visitor
Posts: 5
Registered: ‎11-09-2016

Re: MIG 3.61 DDR2 in Virtex 5

Hello Gabor,

 

Thanks for your quick reply.

 

I have checked the sampling rate of the logic analyzer, and you are right, it works at 500MHz. I have changed the option in the sampling setup from "Full Channel 500MHz" to "Half Channel 1GHz". At the same time, just to make sure the frequencies generated by DCM are OK, I have generated a 10 MHz independent clock frequency from each clock output frequency of DCM (CLKFX and CLK2X). 

 

I have attached one figure just to show you the results, I think you are right and maybe, it is possible that this is just a red herring as you said.

 

I have just a couple of question more, why when I changed the sampling rate from 500MHz to 1GHz, I'm still watching duty cycle changes in the DCM outputs signals. Besides, do you think it is a good test to check the DCM output signal with the technique I explained above?

 

From the other hand, I will try to check the status signals from the MIG module to check at what stage of initialization phase, my DDR2 SDRAM module stops, and maybe I can have more information about what it is happening with my module.

 

Thanks in advance,

 

Manuel

Waveform DCM Output 2.0.png
Instructor
Posts: 9,042
Registered: ‎08-14-2007

Re: MIG 3.61 DDR2 in Virtex 5

[ Edited ]

It's good to know the limitations of your tools.  In the attached image, a 60% duty cycle clock is sampled with at an asynchronous rate as in your logic analyzer's 1 GHz timebase.  Notice that the duty cycle of the sampled signal changes even though the input signal runs at a constant duty cycle and frequency.

 

If you have a ChipScope license, you might consider adding the debug signals to the MIG core to help in finding out the issue.  One common problem is an incorrect Vref level.  Vref needs to be very close to 1/2 of Vcco, 0.9V nominal for DDR2.  If you use a resistor divider to create Vref from Vcco and there is excessive current draw on the Vref net, the actual voltage can change.  I've had problems in the past where I hooked Vref to all banks in the memory system including one bank that only supplied address and control signals.  Since that bank had only outputs and no inputs, its Vref were not configured as Vref but rather as "unused IO."  The default configuration for unused IO is a weak pullup.  That pullup was enough to raise the Vref voltage out of usable range.

-- Gabor
asyncSampling.PNG