cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
8,851 Views
Registered: ‎06-20-2013

Debugging Virtex-6 MIG DDR3 following AR#35183

Jump to solution

I am trying to debug why 'phy_init_done' has not been asserted on my custom board, which contains a Virtex-6 130T and a single DDR3 chip, by using the MIG 'example design' and following AR#35183.

 

NOTE: the signals referred to in AR#35183 are not all connected to the Chipscope Pro ILA by default and had to be added manually.

 

csp_waveform.png

(image also attached, if above is not clear)

 

csp_listing.png

(image also attached, if above is not clear)

 

Following the ‘Debug Steps’ in AR#35183;

 

1)      ‘cal1_state_r’ appears to be always 0x0A whereas looking at the diagram in AR#35183 it looks as if it should be changing state.

2)      The initial pattern, sample 189 (in listing), looks similar to 0xff00ff00ff00ff00, but is byte swapped. However, subsequent values are unstable.

3)      IDELAY taps are not incrementing

 

I am not really sure what I am looking at but hopefully this all means something to you. Basically I need evidence as to why 'phy_init_done' is not being asserted with a view of understanding how I can successfully achieve calibration.

 

Many Thanks,

 

Simon

csp_waveform.png
csp_listing.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
14,258 Views
Registered: ‎06-20-2013

My colleague found the problem, the PCB contained a design fault where the RAS & CAS signals were swapped. A simple UCF change has fixed this problem.

 

Many thanks for your help vsrunga.

View solution in original post

0 Kudos
4 Replies
Highlighted
Xilinx Employee
Xilinx Employee
8,850 Views
Registered: ‎07-11-2011

Hi,

 

As dbg_rd_lvl_done= 1 i believe satge 1 calibration is successful but stage 2 has failure, so please go through below AR and observe the satted signals to findout the failure byte

 

http://www.xilinx.com/support/answers/35193.html

 

Please go through "what can go wrong" section for finding the root cause.

 

 

Regards,

Vanitha

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
0 Kudos
Highlighted
8,843 Views
Registered: ‎06-20-2013

This is the output from CSP having followed AR#35193.

 

csp_waveform_2.png

 

If I am reading this correctly it shows that bitslip did not complete sucessfully as fall1 appears to be one clock cycle too early. In addition there is a whole host of other anomolies in the data pattern.

 

Is there anything else that can be determined from the output above.

 

Any idea what this all means and where the problem lies and what can be done about it?

 

Thanks,

 

Simon

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,803 Views
Registered: ‎07-11-2011

Hi,

 

Is this  a X16 bit memory chip?

I do not see the pattern has properly started yet, also there were bits mismatched

I would suggest you to run a simulation and notice the read levelling stage 2 signals and the pattern.

You can comare and then find out the failing byte or bit.

Also have you checked if your board has met all the design guideliness given in UG406 with proper trace length matchings, terminations?

Have you done the IBIS simulations?

 

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
0 Kudos
Highlighted
14,259 Views
Registered: ‎06-20-2013

My colleague found the problem, the PCB contained a design fault where the RAS & CAS signals were swapped. A simple UCF change has fixed this problem.

 

Many thanks for your help vsrunga.

View solution in original post

0 Kudos