MIG DDR2 controller virtex5

[hastidot]

Hi all
I have generated MIG core as a RAM controller for Xilinx FPGA, virtex5 (ISE 11).
I have generated the design without usuing PLL.
In order to generated right clocks, I instantiated a DCM in my top moudule. as I simulate my design, I see that all the proper clocks and resets have been generated for all modules. Bu t some modules do not work properly. E.G the phy_init_done signal in phy_init module never goes high.
Are there ay suggestions for me what to do in order to find the source of error?

Thanks in advance

 

[rhaynes]

I'm going to suggest something that may be obvious and it's been a while since I have used Xilinx DDR2 stuff but I believe the auto alignment method used in the phy does a write/readback test of the SDRAM and so it requires that SDRAM simulation model be correctly attached before the init done will go true.


Ray

 

[hastidot]

Hi
thank you for your reply. You mean that I have to use ddr2_model in my design in order to have phy_init_done signal high? I instansiated ddr2_model in my top module, but the problem still exists. Do you have any further recommendations?

 

[shyam4908]

Hi,

Try to follow this
1. check wheter clk period of the model is within the range u r operating
2. Check whethet, the ddr2 model attached supports all the fetaures enabled in MIG
3. Check the initiationlation, in ddr2 model you should see init done indication
4. All the timing paramemter
-shyam

 

[rhaynes]

On init you should see some data get written to the SDRAM model and see that data get read back.

Look in the simulation where you think the init is starting and see if you can see the write cycles at the RAM. If you can't then the MIG code is not being told to init or is being held in reset.

If you do see the write cycles at the SDRAM but you don't see the correct data getting read back then the problem is a bit trickier as it could be a lot of different things. Does the SDRAM model spit out any errors/warnings?

Ray

 

[hastidot]

I'v checked the ddr2 model features. All the timing and clocking are correct.
I do not see any write cycle cause the the write process needs some signals to go high which are generated in phy layer modules (e.g phy_init_done). But as they do not get activated through simulation, there are no written data in ram model ( the ddr_dq bus is always "z"). :--(
I think I should activate a signals which leads to phy_init module to assert output signals, but I don't know what it is! :-( :-( :-(

 

[rhaynes]

XAPP858 appnote says that the PHY layer start it's initialization as soon as system reset is deasserted. I did a quit check of the appnote and I didn't see an indication of the correct polarity of that reset.

Make sure the clocks out of the Infrastructure block are working (or are you supplying the 3 clocks?). I think if the system reset is wrong the clocks won't work either.

If the reset and clocks are all correct then there is something that XAPP858 mentions called the Physical Layer Debug Port that might give you insight into why the init process won't start.

Ray

EDIT - My earlier post about the PHY doing a calibrating was a little wrong. The Virtex 5 does it differently from the Virtex 4's I've used in the past. See Fig 15 in XAPP858 for the correct proceedure.

 

[hastidot]

Dear rhyans
Thank you for your reply. It was really helpful. I implemented the design on board. I used one of my push buttons as the reset in the UCF file. after pushing the button many times ( deassert the reset), now the phy_init_done signal goes high periodically and all the other buses are initializing correctly. I really appreciate your help.
Thank you all for helping me.

 

[permute]

the last time I used this, the phy controller provided debug info. for example, the state machine will always pass stage one and two, but will fail at the first IC to have issues in phase three. This might be due to a soldering defect if this is a custom PCB. It may also be due to a timing issue if you don't provide the correct timing contstraints. It can also be due to settings issues. In anycase, determining the exact point of failure, or at least the first point of failure, might be useful.