Erik Widding wrote:
> Antti wrote:
> 
>>John,
>>did you try reversing the ddr2 address bus bit endianess?
>>eg
>>A12>A0
>>..
>>A0>A12
>>
>>if the sdram address bus endianswapped then same data appears
>>on multiply location, exactly as in your case
> 
> 
> I never understood why Xilinx did this.  The JEDEC standard specifies
> fixed bit locations based on little endian ordering.  Change to a
> different size SDRAM and the width of the bus changes, so in big-endian
> format, the location also changes.  Seems like an unnecessary
> complication to the coding of the controller.  As well as the confusion
> this has caused more than one of my engineers, and customers.  I
> confess having participated in missing this detail before.

Bah!   Yes, this fixed the problem (well, got me past that problem, and onto an
easier one :)

Perhaps it's there already in some form, but the memory controller data
sheets/userguides need a big warning box with a giant exclamation mark pointing
out this little trap.

Oh well, at least I'll never fall for that one again.

Thanks Antti, Erik.

John

Erik Widding schrieb:

> Antti wrote:
> > John,
> > did you try reversing the ddr2 address bus bit endianess?
> > eg
> > A12>A0
> > ..
> > A0>A12
> >
> > if the sdram address bus endianswapped then same data appears
> > on multiply location, exactly as in your case
>
> I never understood why Xilinx did this.  The JEDEC standard specifies
[snip]
Hi Eric,

the endian swap was(is) usually done in the UCF file. no one
understands why it has to be so (from those I have explained it to) but
that it is mostly, it however isnt always necessary, in MPMC2 docs it
says that take the non MPMC2 design, then replace the DDR2 core and
__undo__ the endianswap, well I did undo and it did not work, but well
I possible did partial fix, so maybe the UCF undo _and_ MHS toplevel
port swap would have worked also. so or so I think I got the endian
swap correct, but here is the report

first I have a board (actually more than one, several different boards)
with only one 16bit Micron DDR2 chip fitted. The board works well with
MIG and with OPB_MCH_DDR2

PLB_DDR2 is faster than OPB_MCH_DDR2, but I think it is not supporting
16bit memory, and it is not multichannel core, so essentially i need a
DDR2 that is both multichannel and high performance (the max
50MByte/sec in burst accesses with OPB_MCH_DDR2 is just a joke), so the
obvious solution is MPMC2

attempt 1: MPMC2, 1 port, OPB

does not work at all (read stall) because the datapath fifo doesnt
support 32 bit wide mode.

attempt 2: MPMC2, 1 port PLB

does not work at all because the datapath read fifo writes to the fifo
at wrong time, as shown in simulation it happens 2 clocks after the
data from DDR2 is valid at the fifo input

in the FPGA the same design does readback 1 32 bit word correctly, but
I also was seeing that reads are latched at wrong time, eg as if the
core would lath DDR2 data 1 clock too late, eg data written to
offset_base8+4 appears at offset_base8+0 (correct data), and one half
of the 32 bits appears duplicated in both halfs of the word read back
from offset_base8+4

I have a DSO on the DQS and DQ, and I can see that the DDR2 memory
returns valid data, sot the DDR2 core should be able to fethch it, but
it happens really at wrong time slots.

It really seems that ****ONLY**** those configurations that are present
in the MPMC2 ref design directory only work, and that ****EVERY****
other configuration will most likely fail.

as of the generic _wrong_endian_ and endian fix in UCF thing, I
personally have wasted (accumulated over many years) at least one
man-month of active development time. My estimate is that the time
wasted by all Xilinx customers over this issue is way more than 10
Man-Years of time wasted. Considering this it is really ridiculous that
Xilinx even charges money for this, in the matter of fact Xilinx should
pay to all EDK users in advance to compensate the time wasted by the
customers.

Antti

Antti wrote:
> John,
> did you try reversing the ddr2 address bus bit endianess?
> eg
> A12>A0
> ..
> A0>A12
>
> if the sdram address bus endianswapped then same data appears
> on multiply location, exactly as in your case

I never understood why Xilinx did this.  The JEDEC standard specifies
fixed bit locations based on little endian ordering.  Change to a
different size SDRAM and the width of the bus changes, so in big-endian
format, the location also changes.  Seems like an unnecessary
complication to the coding of the controller.  As well as the confusion
this has caused more than one of my engineers, and customers.  I
confess having participated in missing this detail before.

I understand the big endian preference in the EDK.  All the Coreconnect
and PowerPC stuff from IBM is big endian.  But I would suggest it
should really only be a preference, and not an absolute.  Having both
read and written a lot of code, mixed endian is much easier to follow
when the endianness of any given bus/endpoint follows the source
documentation (i.e. the JEDEC standard, or the component data sheet,
rather than the IP).  Not to mention the fact that we name our PCB nets
based on the physical design (i.e. DRAM pin names, rather than SDRAM IP
names).  Rant mode off.

We saw an instance some years ago with the Xilinx tools where an endian
reversal happened at a port.  Now it has been some time, so I don;t
remember the exact details.  It may have been a platform studio
problem, but I seem to recall it being farther down stream, XST or even
the mapper.  THe design used both Verilog and VHDL modules.  The only
workaround that we could find was to keep the endianness of the IP
through EDK to the UCF file, all the way out to the FPGA pins, and do
the swap (in effect) outside the FPGA.  Before dismissing this as
unsubstantiated urban legend (which I would do with anything so hazy as
the recollection I am offering), I would suggest using FPGA editor to
trace back one address signal back through the FPGA to prove that an
endian swap did not happen in the tools.  We were overworked and
overtired at the time, so it is possible I never filed a case with
Xilinx on this.

My suggestion is of course unneccessary if Antti's suggestion helped
you find the answer.  I second his notion, as this behavior is exactly
as we saw when we had a backwards address bus on a DDR SDRAM.

Would be nice to know how you resolve the problem, as we have our first
DDR2 board coming back in a week, and any additional information might
help me avoid the same problems.  We will be using a single 512Mb DDR2
in a x16 configuration.  We will have to do our own controller for this
eventually, but we plan to get "hello world" working with a stock
controller.  We have size and speed reasons to do our own controller:
our IP and the PowerPC processor only do single 64bit byte enabled, or
quad-doubleword read/writes;  and we have no need for all of the extra
fancy stuff that is included with the Xilinx cores.  I also seem to
recall that there is no Xilinx IP to direct attach a x16 DDR2 to a
64bit PLB bus at a bit rate 4x the PLB.

Regards,
Erik.

---
Erik Widding
President
Birger Engineering, Inc.

 (mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
  (fax) 617.695.9234
  (web) http://www.birger.com

John Williams schrieb:

> Hi Chris,
>
[]
> Thanks for the reply -however I am actually using the EDK's mch_opb_ddr2
> controller, not the MPMC2.  I haven't gone source diving in the controller's
> VHDL yet, will see how I go with a webcase first.
>
> Thanks again,
>
> John

John,
did you try reversing the ddr2 address bus bit endianess?
eg
A12>A0
..
A0>A12

if the sdram address bus endianswapped then same data appears
on multiply location, exactly as in your case

Antti

Hi Chris,

>> That's interesting - what memory configuration?  We have a single
>> MT47H32M16CC-37E and just cannot get any sense out of it.
>>
>> Addressing looks all wrong - it reads back the same data value at 4
>> consecutive
>> dword addresses (offset 0x00 -> 0x0c)
>>
>> Writing is unreliable, if you write 0xffffffff it just randomly
>> twiddles a few
>> of the top 16 bits, but not in any discernable pattern.
>>
>> I've tried more combinations that I care to admit - differential DQS
>> on vs off,
>> timing params exact according to Micron datasheet vs more
>> conservative, you name
>> it.  Triple-checked UCF pin assignments, blah blah blah.
> 
> It sounds like your read data isn't getting aligned properly.  You
> should try tweaking the parameters C_CTRL_Q10_DELAY and
> C_CTRL_DP_RDFIFO_WHICHPORT_DELAY.  If your running DDR2 at 200MHz, you
> probably want to decrement those by 1.  The parameters can be found in
> the mpmc2_ctrl_path_params.v file in the verilog directory. HTH.

Thanks for the reply -however I am actually using the EDK's mch_opb_ddr2
controller, not the MPMC2.  I haven't gone source diving in the controller's
VHDL yet, will see how I go with a webcase first.

Thanks again,

John

"John Williams" <jwilliams@itee.uq.edu.au> schrieb im Newsbeitrag 
news:newscache$auki9j$qze$1@lbox.itee.uq.edu.au...
> Antti wrote:
>
>>>Antti wrote:
>>>
>>>>all attempts to get MPMC2 DDR2 designs to work have failed so far
>>>>have tested on custom V4 board with single 16bit device and on ML501
>>>>all attempts failing
>>>
>>>And same here (mch_opb_ddr2 not MPMC) - we've spent a week trying to get 
>>>the
>>>mch_opb_ddr2 core talking to a Micron 512Mb 32Mx16 -37E part on a PCIe 
>>>board -
>>>no luck.  The board is OK - there's a MIG design that works fine.
>>>
>
>> OPB_MCH_DDR2 (EDK 8.2 SP2) worked for me like magic, just out of box,
>> all working, no issues
>
> That's interesting - what memory configuration?  We have a single
> MT47H32M16CC-37E and just cannot get any sense out of it.
>
> Addressing looks all wrong - it reads back the same data value at 4 
> consecutive
> dword addresses (offset 0x00 -> 0x0c)
>
hm, this sounds like the address bus bits need be bit-reversed

remember EDK is "wrong endian" it is impossible to guess if you need to 
reverse the bits in the busses even or odd times, just try reversing the bit 
order in all ext mem busses to the ddr2

Antti

John Williams wrote:
> That's interesting - what memory configuration?  We have a single
> MT47H32M16CC-37E and just cannot get any sense out of it.
> 
> Addressing looks all wrong - it reads back the same data value at 4 consecutive
> dword addresses (offset 0x00 -> 0x0c)
> 
> Writing is unreliable, if you write 0xffffffff it just randomly twiddles a few
> of the top 16 bits, but not in any discernable pattern.
> 
> I've tried more combinations that I care to admit - differential DQS on vs off,
> timing params exact according to Micron datasheet vs more conservative, you name
> it.  Triple-checked UCF pin assignments, blah blah blah.

Hi John,

It sounds like your read data isn't getting aligned properly.  You 
should try tweaking the parameters C_CTRL_Q10_DELAY and 
C_CTRL_DP_RDFIFO_WHICHPORT_DELAY.  If your running DDR2 at 200MHz, you 
probably want to decrement those by 1.  The parameters can be found in 
the mpmc2_ctrl_path_params.v file in the verilog directory. HTH.

-Chris

Antti wrote:

>>Antti wrote:
>>
>>>all attempts to get MPMC2 DDR2 designs to work have failed so far
>>>have tested on custom V4 board with single 16bit device and on ML501
>>>all attempts failing
>>
>>And same here (mch_opb_ddr2 not MPMC) - we've spent a week trying to get the
>>mch_opb_ddr2 core talking to a Micron 512Mb 32Mx16 -37E part on a PCIe board -
>>no luck.  The board is OK - there's a MIG design that works fine.
>>

> OPB_MCH_DDR2 (EDK 8.2 SP2) worked for me like magic, just out of box,
> all working, no issues

That's interesting - what memory configuration?  We have a single
MT47H32M16CC-37E and just cannot get any sense out of it.

Addressing looks all wrong - it reads back the same data value at 4 consecutive
dword addresses (offset 0x00 -> 0x0c)

Writing is unreliable, if you write 0xffffffff it just randomly twiddles a few
of the top 16 bits, but not in any discernable pattern.

I've tried more combinations that I care to admit - differential DQS on vs off,
timing params exact according to Micron datasheet vs more conservative, you name
it.  Triple-checked UCF pin assignments, blah blah blah.

> PLB_DDR2 works on ML501 (but uses patched EDK core), well Xilinx
> reports that out of box PLB_DDR2 also works on ML501 (I have failed
> with it)
> there is customer report who got PLB_DDR2 working on custom board (but
> after getting patch from Xilinx FAE)

Is this a patch to the plb interface, or the core ddr2_interface that is used by
all controllers?

Cheers,

John

John Williams schrieb:

> Antti wrote:
>
> >>Has anyone successfully used MPMC2 as the memory controller for DDR2 SDRAM? I used it to interface with the Micron's MT47H32M16CC-37EB DDR2 SDRAM and it doesn't work. Any important steps/settings required in order to get it working?
>
> >
> > same here :(
> > all attempts to get MPMC2 DDR2 designs to work have failed so far
> > have tested on custom V4 board with single 16bit device and on ML501
> > all attempts failing
> >
>
> And same here (mch_opb_ddr2 not MPMC) - we've spent a week trying to get the
> mch_opb_ddr2 core talking to a Micron 512Mb 32Mx16 -37E part on a PCIe board -
> no luck.  The board is OK - there's a MIG design that works fine.
>
> Webcase is in progress, we'll see what happens.
>
> In the process of trying to simulate the design, I discovered that the standard
> practice of chaining one DCM's "locked" pin to the next DCM's "reset" pin is not
> supported by the simulation libraries - you must have at least three clock
> cycles on CLKIN before releasing reset or the simulated DCM refuses to start.
> Sigh..
>
> John

John,

the DDR2 issue gets more confusing:

OPB_MCH_DDR2 (EDK 8.2 SP2) worked for me like magic, just out of box,
all working, no issues
PLB_DDR2 works on ML501 (but uses patched EDK core), well Xilinx
reports that out of box PLB_DDR2 also works on ML501 (I have failed
with it)
there is customer report who got PLB_DDR2 working on custom board (but
after getting patch from Xilinx FAE)

MPMC2 has SERIOUS bug with the OPB interface, the datapath FIFO used
just doesnt work at all, everything stalls on first read, tested both
FPGA design and simulation

I am now trying MPMC2 core with PLB selected as port interface, I hope
this will work (I have problems at the moment with the OPB2PLB bridge
but those are possible minor mis-config)

For what my impressions are, is that DDR2 isnt so much harder than DDR
at all, at least when you have single chip (and not SODIMM), if you
happen to have config setup that is supported by the IP core

the MIG test is something you should not trust 100% I have seen patches
to MIG where in commentary it says, "ah this must be delayed by 2
clocks, or the error out will not work.."

so make sure the MIG test really is reporting errors, that is inject
errors and monitor the status

Antti