MPMC2: MPMC2 with DDR2 SDRAM
zyan
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?
Thanks.
Antti
> Hi,
>
> 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?
>
> Thanks.
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
I guess the only way to get going is to purchase a eval board that *IS*
supported by MPMC2 like ml410 and get it working there, and then
translate that working design to a custom board.
Antti
Siva Velusamy
Hi Antti,
MPMC2 works fine on ML410 DDR2. You might want to start with those
settings and then customize for your project.
BTW, MPMC2 does not support Virtex5 as yet, so it will not work on ML501.
/Siva
Jim Wu
information on what to look at since I started from the reference
designs. Have you simulated your design?
Cheers,
Jim
http://home.comcast.net/~jimwu88/tools/
Antti
Hi Siva,
I belive that MPMC2 DDR2 works on "Xilinx provided boards" but the
question is how to make it to work on an "non Xilinx board?"
I have several custom V4 boards with DDR2 and I have ML501, I assumed
that as MPMC2 generates UCF file that matches ML501 so first step would
be to get MPMC2 to work on ML501 and then derive a new design for the
custom board. I dont have ML410 or any other "xilinx supported board"
for testing.
can you tell me why MPMC2 1.7 does not support V5? is it because
1) it is not tested (but may work) ?
2) IP core just want work for V-5 architecture
3) IP core is ok for V-5 but want work on ML501 because of clock buffer
errata in ES silicon as described in EN049.PDF ?
Are there any plans to make MPMC2 to support Virtex-5? If yes when can
we expect this?
Getting MPMC2 to work on our custom V4 DDR2 boards is really urgent, so
any help is welcome.
For now I will drop any MPMC2 testing on ML501 and try to modify some
MPMC2 archived project for our purpose, so far I did regenerate new
project (and that failed to workI)
Antti
Guru
problems at all. But It has only 64MB DDR x16. I also tried running DDR
at 200MHz but it did not pass the memory test since it is only DDR333.
I also don't know where these MPMC2 guys got the datasheet for this RAM
to get the Fmax=200 at CL=3.
But I do have some problems writing to NPI in 64 word bursts and
premature ending.
BTW: There are so many parameters to adjust that there is a good chance
that the system does not work at all.
Cheers,
Guru
Siva Velusamy
> question is how to make it to work on an "non Xilinx board?"
>
> I have several custom V4 boards with DDR2 and I have ML501, I assumed
> that as MPMC2 generates UCF file that matches ML501 so first step would
> be to get MPMC2 to work on ML501 and then derive a new design for the
> custom board. I dont have ML410 or any other "xilinx supported board"
> for testing.
>
> can you tell me why MPMC2 1.7 does not support V5? is it because
> 1) it is not tested (but may work) ?
> 2) IP core just want work for V-5 architecture
> 3) IP core is ok for V-5 but want work on ML501 because of clock buffer
> errata in ES silicon as described in EN049.PDF ?
>
> Are there any plans to make MPMC2 to support Virtex-5? If yes when can
> we expect this?
>
> Getting MPMC2 to work on our custom V4 DDR2 boards is really urgent, so
> any help is welcome.
>
> For now I will drop any MPMC2 testing on ML501 and try to modify some
> MPMC2 archived project for our purpose, so far I did regenerate new
> project (and that failed to workI)
>
Hi Antti -
Unfortunately I do not have good answers for any of the above questions.
I do know that the next release of MPMC2 will support V5. I do not know
the schedules.
/Siva
John Williams
>>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
zyan
I queried through the webcase and Xilinx said they only support their own product. As the Micron DDR2 is "external" to them. They do not provide support for that. Sigh!
-zyan
Antti
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
John Williams
>>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
Chris Case
> 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 Lukats
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)
>
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
>> 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
Antti
> 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
Erik Widding
> 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
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
[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
John Williams
> 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