MPMC2: MPMC2 with DDR2 SDRAM

zyan schrieb:

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

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

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?

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

It works on ML403 and ML405 boards. Sorry I don't have any specific information on what to look at since I started from the reference designs. Have you simulated your design?

Cheers, Jim

zyan wrote:

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?

Siva Velusamy schrieb:

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?

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

I got it working on Virtex4FX12 MiniModule AKA GSRD2. Actually I had no 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

Antti wrote:

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?

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

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?

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

That is the memory that I am using. Besides MPMC2, I tried plb_ddr2 also. Didn't work :(

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

John Williams schrieb:

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?

not

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

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.

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

Cheers,

John

name

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

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

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 Williams schrieb:

[]

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

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

Erik Widding schrieb:

[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

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