FWIW, this answer record [ftp://ftp.xilinx.com/pub/applications/misc/ar19385.pdf]
details a generic method of calculating the DCM phase shift value based on
board delays.
Matt
From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
[mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx] On Behalf Of Siva Velusamy
Sent: Monday, October 31, 2005
11:13 PM
To:
microblaze-uclinux@xxxxxxxxxxxxxx
Subject: Re: [microblaze-uclinux]
Jtag Debug
Greg - Thanks for the
explanation. I also just came across this appnote:
Determining the optimal DCM phase shift for DDR feedback clock.
http://direct.xilinx.com/bvdocs/appnotes/xapp806.pdf
Pretty much does the same thing that you say.
-Siva
On 10/31/05, Greg A
Martin <gregmartin@xxxxxxxxxx>
wrote:
I figured the phase delay out by trial and
error moving the clock 1/8 the total phase shift until the memory test started
to pass. then I could fine tune it until I was in the middle of a passing
range. For my design the the window is about 0x80 large (128 of a useable rage
of -255 - 255). I was lucky and had my first lightly filled
designs work out of the box, and then as the deign got fuller the memory
started acting erratic from route to route. This sent me down the path of
timing problems since I had evidence of proper operation. If my first routes
had failed, I would probably still be scratching my head.
-----Original Message-----
From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
[mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx]On Behalf Of Siva Velusamy
Sent: Friday, October 28, 2005
11:51 AM
To: microblaze-uclinux@xxxxxxxxxxxxxx
Subject: Re: [microblaze-uclinux]
Jtag Debug
Greg - Just curious: How
did you figure out the correct phase alignment. In general how do you go about
debugging any DDR issues?
Excellent debugging btw!
-Siva
On 10/28/05, Greg A
Martin <gregmartin@xxxxxxxxxx>
wrote:
Just a note on the
mch_opb_ddr controller, I am running 66Mhz/133Mhz with
16-bit DDR and was seeing problems similar to what John reported below. At
66 MHz the DQS window is pretty slim and if the feedback clock is out of
phase enough, the controller misses the DQS for read data causing
reads to
not be acknowledged. This presents itself as a stalled pipeline message in
the XDM debugger and a hung system. The behavior varies from route to route
unless you lock down the DCM's and global clock buffer positions. Once I
locked down the positions and determined the correct DCM phase alignment, I
have been getting much more consistent behavior. Additional info, I am
running on a Spartan3e 500 device that is virtually full. The behavior
manifested itself as the design got closer and closer to 100% utilization.
Also, since I am cheap, I chose not to use the external feedback for the
DDR, instead using DCM phase adjustment to delay the feedback clock
appropriately. (pins are just to valuable to waste on phase delay
when the
DCM's can do it anyhow).
Greg
--
In the end, everything is a gag.
Charlie Chaplin
|