DDR2 Troubles on Cyclone III

[Altera_Forum]

I'm having some trouble with DDR2 interface on a Cyclone III system. I'm using v. 9.1 of the tools, SOPC builder with the Legacy High Performance Full Speed Controller, 133MHz memory clock. The memory modules are 2ea 16bit wide MT47H16M16-3 chips, each with a dedicated clock. 

 If I write a pattern such as this: Address Base+0 - 0x11111111 Address Base+4 - 0x22222222 Address Base+8 - 0x33333333 Address Base+C - 0x44444444  The read back will be this: Address Base+0 - 0x33113311 Address Base+4 - 0x44224422 Address Base+8 - 0xXX33XX33 Address Base+C - 0xXX44XX44  This looks to me as if the lower bytes access correctly while the upper bytes are off a clock. I don't know if the issue is on a read or write or both - any ideas on how to check if the issue is read or write would be helpful.  My design meets timing.  I'm not a DDR2 expert, but I've verified the the DDR2 core presets against the datasheet, and have used identical preset file successfully on Aria designs.   Does anyone have experience with similar issues or ideas on solutions?

[Altera_Forum]

the X in the read back are because there is a randomization on the read result in hardware or because this is the result of a simulation? 

I had once a problem with the data stored in DDR2 memory that time I changed the name of the controller instance in SOPC Builder but forgot to reapply assignments and re-check timing constraints; the name of the ports in the SOPC Builder instance changed losing relation with the pins of the top level design.

[Altera_Forum]

Hi, 

there is an appnote describing how to test your design using signal tap. Cumbersome, but quite helpful. AN 380.  If you have troubles with your timing then you will have to read up on manually adjusting the timing, which is quite time consuming..

[Altera_Forum]

It migth help to use a bridge unless the whole system is running of one of the aux clocks from the ddr controller.

[Altera_Forum]

gabrigob - This is real world, not simulation. I've run the identical design on the Cyclone III 125 dev kit, and have no problems. I've not notices any issues with the instantiation. 

 agdepus - Thanks. This appnote looks helpful, and not a;; that cumbersome. I'm currently using Nios memtest project to read/write to memory. I don't quite understand what you mean by bridge - can you elaborate?

[Altera_Forum]

Hi, 

I am in the middle of Win7-64 / Nios Eclipse 10.0 and find everything regarding altera cumbersome these days...about to install linux. Ungodly slow in windows.  The bridges are essential in order to separate clock domains, ease timing req and so on. If you do run a bunch of low speed PIOs you may separate those from the high speed CPU/memory/cache clock domain.  All of our Nios/DDR designs have: CPU Cache On chip ram JTAG  In the DDR_AUX half rate or full rate clock and the rest is run at 10MHz using a clock separation bridge.  BUT, anything that your CPU is constantly accessing should be put in the high speed domain. That is for you to decide.  The embedded design handbook is actually quite good, you should have a look. We have designed multi core systems that has been running flawless for 4 years now based on that information.  I don't do much low level work these days, but it happens. Maybe some of the gurus can take you further.  apus

[Altera_Forum]

agdepus - Thanks again for your help. I am running my tools on Linux, Centos 5.5. My experience with the NIOS and SOPC builder tools on Windows 7 has not been good. Right now most of our designs are all V9.1 of the tool set and so I don't know if V10 is any better. If you go to Linux, I suggest CentOS. That worked for me without issue, is free, and has a wider range of software available than Suse and RHEL. 

 Yes, I'm using a bridge, and have a very similar setup to what you described. However, my NIOS is running at 125MHz.   I'm trying to bring this design up on a new custom board. I've got the identical design working correctly on the Altera Cyclone III dev kit, and the design meets FPGA timing in both the DevKit and the custom PCB.  However, the four variables that are different between our PCB and the Dev Kit:  1. We are using two 256Mb DDR2 ICs MT47H16M16, the Dev Kit uses two MT47H32M16 (512 MB) - and so our PCB design is using a different memory Preset file. 2. Our PCB uses separate clocks for each of the DDR2 ICs, the Dev Kit uses one clock that Tees - once again we have two clocks set up in the preset file. 3. I'm using a EP3C55F780C7N rather than the EP3C120F780C7N on the dev kit - so the pinout on the FPGA is a slight different. 4. Of course, the layout is different.   My suspicion is that that something in the layout or the Dual clock architecture is causing the problems I'm seeing. The fact that the lower bytes are solid, but the upper bytes are corrupt or have slipped a clock seems curious as well. It seems there is enough adjustably in the DDR core that there may be a fix here, but I'm not sure what to tweak.

[Altera_Forum]

Hi, 

we are using two 64M16, set up as two total independent memories. I tried to merge two DDRs back in 2007, and dropped it. But do you need to run those chip on the same controller?

[Altera_Forum]

Yes, the same controller.  

 The devices share an address bus. but have a separate clock.  Normally, we use two memory devices with a shared address bus and clock in our designs - similar to the dev kit. I'm not sure if the separate clock causes a problem or not.

[Altera_Forum]

So that means that all data and ctrl signals are related to one of the clocks? 

That will never work unless the IP actually supports that. My guess is that the lower bytes is the chip with the controller clock.  You need to use a clock from the same pll, maybe with a few degrees tune...  I mean, you have two totally different clock domains here....?

[Altera_Forum]

No, the same clock domains. 

 In the memory presets, we can specify the number of clocks. In this case, there are two. The clocks should be on the same domain.  The clocks each go to one of the ICs. For what it is worth, the lower byte of the each of the ICs is being read correctly and consistently. I would expect a clock domain issue to result in in a error in the upper and lower bytes in one or both of the ICs.

[Altera_Forum]

Sorry, didn't read everything. 

Back to the An 380. You will probably have to ajdust the write clock. It has been a while since I did that, but you open the PLL from the megawiz instead of sopc. Then you don't have to recompile the sopc.  There is an appnote for that to, AN328. Its for stratix but the concept is the same.  It is a BIG appnote..... Please tell me if it works.  We still have several operative designs with DDR2 / C3. Launching a new product next month based on a proven design.  As for OS, I think we use OpenSuse.