[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [microblaze-uclinux] Jtag Debug
Siva,
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.
Greg
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